
Nim language v0.18.0 released - mratsim
https://nim-lang.org/blog/2018/03/01/version-0180-released.html
======
the_duke
Seems like nim is still doing well and progressing.

I last looked into it about 2 years ago, when the library ecosystem was very
bare-bones and the language quite buggy, but promising non the less.

Clean, Python-like syntax and generally a joy to code in.

Anyone here actively using Nim and can share some insight into it's current
state?

~~~
carterza
I've written quite a few personal projects in Nim, and I love programming in
it. Nim is garbage-collected and the GC is not a stop the world GC, so the
language is well-suited for game-development.

Its standard library is improving with each release, and is already equivalent
to what you expect from most modern programming languages. It contains flaws
and inconsistencies, but it is being worked on and stabilized for a 1.0
release of the language. The ecosystem is small - but growing.

Some of the great things about Nim -

1) Ability to interface with C/C++/Obj-C/JS

2) Can compile to any of ^

3) Meta-programming

4) Python like syntax

5) Small binaries

6) Can compile to WASM via emscripten

I've built AWS lambda jobs with Nim by interfacing with Python, as prototypes
for work, but I've never been able to leverage the language in production. I
really only use it professionally to replace personal shell scripts or other
tasks I've previously automated.

That said - Nim has a bright future - it needs to mature and hit 1.0 and it
could really use some more interest as well as sponsorship.

Github - [https://github.com/zacharycarter](https://github.com/zacharycarter)

~~~
szemet
_5) Small binaries_

That part is amazing. I personally do not have a real use case to exploit it
[1], just find it neat from an engineering viewpoint...

I guess, it has an aggressive dead code removal process, compared to other -
nowadays hot - compiled languages (Go, Haskell, Rust, D, Crystal). In those
languages if you use a small part of their standard library, you usually get
large chunks of it linked in statically (+ runtime if there is such)...

(Once I've tried LTO with one of my Rust project: it increased the build time
tremendously but in the end it managed to shave off only 30KB from my several
MB binary...)

[1] If I would try micro controller programming ever, I probably would give
Nim a shot because of this...

~~~
szemet
I've just tried now some Rosetta code examples. Most of it had to be modified
a bit to get compiled with this Nim version although. (adding types, change
case of type names)

Used -d:release --opt:size, then strip, Ubuntu 16.04 64 bit. The binary sizes:

GTK2 example code:
[http://rosettacode.org/wiki/GUI_enabling/disabling_of_contro...](http://rosettacode.org/wiki/GUI_enabling/disabling_of_controls#Library:_Gtk2)
\- _35k_

http client:
[http://rosettacode.org/wiki/Ordered_words#Nim](http://rosettacode.org/wiki/Ordered_words#Nim)
\- _72k_

http server:
[http://rosettacode.org/wiki/Hello_world/Web_server#Nim](http://rosettacode.org/wiki/Hello_world/Web_server#Nim)
\- _121k_

The binaries are dynamically linked only to the common standard C prog.
dependencies on Linux: linux-vdso.so.1, libc.so.6, ld-linux-x86-64.so.2
(Except for the gtk2 example of course, which uses libdl to to pull in a large
bunch of additional gtk dependencies too...)

------
airstrike
Every time I see news about Nim I just wish Cobra[0] would get the same
love...

[0] [http://cobra-language.com/](http://cobra-language.com/)

~~~
pavlov
Why?

~~~
scardine
Not the parent but my personal pet-peeve is case-insensitive variable names -
a deal breaker for me.

~~~
_sdegutis
> "That means only the first letters are compared in a case sensitive manner.
> Other letters are compared case insensitively within the ASCII range and
> underscores are ignored." [1]

Wow, this is strange. I understand the reasoning but strongly disagree with
it. Not sure if it's a deal-breaker for me though, just... strange.

[1]: [https://nim-lang.org/docs/manual.html#lexical-analysis-
ident...](https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-
equality)

~~~
dom96
It definitely doesn't exist in any other language, so from that perspective it
is strange. But please give Nim a try before closing the web page because of
this feature.

~~~
_sdegutis
Yeah like I said before, it's not necessarily a show-stopper, it just threw me
off.

------
komerdoor
I will just repost my old post, but a lot has happened since then:

Nim comes very close to be the perfect language for me (game development,
machine learning etc.). Some things I experimented with including some links
to show what I tried as follows:

\- Fully controllable and plugable GC: I can decide for myself when the GC
runs and for how long. Very important for games. If I do not like the GC I can
even write my own or choose one of the many existing ones. See:
[http://forum.nim-lang.org/t/2646](http://forum.nim-lang.org/t/2646)

\- Meta-programming, templates, concepts etc.: To be able to write a machine
learning library I needed something that can replace simple code (DSL) with
more complex code using scalar math, SIMD, SPIR-V, OpenCL or Cuda. I also
wanted to be able to automatically generate bindings for scripting. See:
[http://forum.nim-lang.org/t/2654](http://forum.nim-lang.org/t/2654) and
[http://forum.nim-lang.org/t/2635](http://forum.nim-lang.org/t/2635) . As I
understood by reading the forums they will soon merge in many concept
improvements. See: [http://forum.nim-lang.org/t/2396](http://forum.nim-
lang.org/t/2396)

\- Nim itself can be used as an embedded scripting language: Nim as a
scripting language is used by the compiler to run Nim while compiling to
generate new code. Nim as a scripting language can also be used as a more
advanced configuration language (like Lua in the beginning). It can be used as
an embedded or standalone scripting language as well. See: [http://forum.nim-
lang.org/t/2647](http://forum.nim-lang.org/t/2647) and
[https://github.com/komerdoor/nim-embedded-
nimscript](https://github.com/komerdoor/nim-embedded-nimscript)

\- Compiling to C89 code (useful for creating libraries and cross-platform
support etc.): I want my games to compile on platforms not supported by GCC or
Clang/LLVM (actually I am sure they can support them all after some patching)
but with their own C89 compiler. After compiling to C it is easier for me to
see what the code will actually do. Still if I really want to I can choose to
compile to Javascript, C++, Objective-C and LLVM (not officially included yet)
as well. See:
[https://github.com/arnetheduck/nlvm](https://github.com/arnetheduck/nlvm)

\- Pretty good functional programming support (as far as compiled code allows
for): For this I created a library that use the zero-overhead iterators. There
are many alternatives as well and I like to be able to choose between multiple
implementations of higher level functionality. See:
[https://gist.github.com/komerdoor/70d9c25820952624cf797890a1...](https://gist.github.com/komerdoor/70d9c25820952624cf797890a1..).
. Of course a better implementation is possible by combining this with
concepts, generic dynamic method binding and all other of Nim's features. See
the following again: [http://forum.nim-lang.org/t/2654](http://forum.nim-
lang.org/t/2654)

\- Easy integration of existing C code: I wrote part of my code in C (low-
level) and another part in Nim (mid-level).

Some things which may get new Nim users in shock but I learned to love:

\- Use of indentation using spaces for grouping like Python: I never really
liked this but I cannot ignore that this made my code easier to read and
discourages my preference for one-liners (yes I know bad habit and does not
work well inside editors and with source-control).

\- Multiple ways to write the same identifier (case/underscore insensitive):
Liked this from the beginning. I am really consistent to choose a single style
but all my C code is written using underscore (ex.: typens_do_something(x))
while in Nim in prefer to use camel case (ex.: typensDoSomething(x)) or fully
drop the namespace entirely (ex.: doSomething(x) or x.doSomething()).

\- Multiple ways to call methods: Both "abc".toUpper() and toUpper("abc") are
the same. There are no namespace conflicts because Nim uses the best match for
toUpper like: func toUpper(c: char): char or toUpper(s: string): string. It
also makes it easier to add new methods for existing types while still being
able to call the methods like if OOP is being used.

\- Minimal support for OOP but encouraging composition over inheritance

~~~
somlor
Your gist link under functional programming support is a 404 for me.

~~~
komerdoor
A part of the URL was missing. Here you go:
[https://gist.github.com/komerdoor/70d9c25820952624cf797890a1...](https://gist.github.com/komerdoor/70d9c25820952624cf797890a18f9cd5)

