# What makes Nim practical?

DevFeed: [What makes Nim practical?](<https://devfeed.tech/articles/what-makes-nim-practical-30844.md>)

Original publisher: [Read original article](<https://hookrace.net/blog/what-makes-nim-practical/>)

Published: 2015-01-22T23:00:00Z

Content type: tutorial

Language: en

Sources: [Dennis Felsing](<https://devfeed.tech/sources/dennis-felsing.md>)

Topics: [Nim](<https://devfeed.tech/topics/nim.md>), [Programming language](<https://devfeed.tech/topics/programming-language.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [Library](<https://devfeed.tech/topics/library.md>), [Package manager](<https://devfeed.tech/topics/package-manager.md>), [C](<https://devfeed.tech/topics/c.md>)

Tags: [c](<https://devfeed.tech/tags/c.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [gcc](<https://devfeed.tech/tags/gcc.md>), [install](<https://devfeed.tech/tags/install.md>), [libraries](<https://devfeed.tech/tags/libraries.md>), [nim](<https://devfeed.tech/tags/nim.md>), [programming-language](<https://devfeed.tech/tags/programming-language.md>)

## AI overview

This article explains why Nim is practical for distributing programs. It covers statically linking the Nim runtime and libraries into binaries, using nimble for dependencies, compiling with Clang or GCC, creating source distributions for different operating systems and CPU architectures, and distinguishing debug and release builds.

## Source excerpt

In my last post I showed what makes the Nim programming language special. Today, let's consider Nim from another angle: What makes Nim a practical programming language? Binary Distribution Programs written in interpreted languages like Python are difficult to distribute. Either you require Python (in a specific version even) to be installed already, or you ship it with your program. This even causes some to reconsider Python as a teaching language. How does Nim work around this problem? For starters your program gets statically linked against the Nim runtime. That means you end up with a single binary that depends solely on the standard C library, which we can take for granted on any operating system we're interested in. Let's write a small program and give this a try: echo "Hello World" If you want to follow along, get the Nim compiler. Save this code as hello.nim. Let's compile it now so that we can distribute the hello binary: $ nim -d:release c hello CC: hello CC: stdlib_system [Linking] $ ./hello Hello World $ ls -lha hello -rwxr-xr-x 1 def def 57K Jan 22 09:37 hello* $ ldd hello linux-vdso.so.1 (0x00007fffd5973000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f0f92c6b000) libc.so.6 => /lib64/libc.so.6 (0x00007f0f928c3000) /lib64/ld-linux-x86-64.so.2 (0x00007f0f92e6f000) Now our little program starts growing and we get interested in using a few Nim libraries. Do we have to add compiled versions of these libraries to our distributions now? Do not fret! Nim libraries are statically compiled into our binary as well. Let's get a library using Nim's package manager, nimble: $ nimble install strfmt Installing strfmt-0.5.4 strfmt installed successfully. And use the library in our, admittedly not very useful, program: import strfmt echo "Hello {} number {:04.1f}".fmt("World", 6.0) If we want to compile with Clang instead of GCC as the backend, that's easy as well and Clang is usually much faster to compile and yields a smaller binary: $ nim --cc:clang -d:release c hello $ .