16 ms·

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 qu

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 9y ago
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
- mlevental 9y ago
  how does it compile to wasm if it has a GC?
  - jitl 9y ago
    Probably it builds the GC into the WebAssembly output.
- szemet 9y ago
  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 9y ago
    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_controls#Library:_Gtk2 http://rosettacode.org/wiki/GUI_enabling/disabling_of_contro... - 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...)
citycide 9y ago
I think it's hugely underrated. I agree that it really is a fun language to use and as someone who came to it from a web dev perspective with no prior system level experience I had no trouble at all being productive in it (I built four internal Windows GUI apps with it). But there's also some things that make people nervous -- like case & style insensitive names (ie. `read_file` is equivalent to `readFile`) -- that are almost never an actual issue. Having that be more widely understood would do a lot of favors for Nim, and once the language hits a stable 1.0 I could see it getting a lot more attention.
- dilap 9y ago
  > But there's also some things that make people nervous -- like case & style insensitive names (ie. `read_file` is equivalent to `readFile`) -- that are almost never an actual issue. Gahhh, why would you do this? It just seems like it'd be a nightmare to use grep to understand your codebase.
  - nimmer 9y ago
    I use Nim a lot and I've never seen libraries that mix different styles. I use grep without issues. Style insensitivity is useful when wrapping C libraries.
  - citycide 9y ago
    This is exactly my point when I say it needs to be better understood: you wouldn't do it within a single project, but if you've got a third party library that exposes a `read_file` method you can use it as `readFile` meaning your own code base is more consistent. In other words, you're not limited by the design decisions of another developer (or language, as nimmer pointed out).
    - dilap 9y ago
      Thanks, that's interesting. I see the justification for it, at least. I don't know if the whole world is magically living with much more orderly developers than I have had the pleasure to work with, but I guarantee you that if I were using such a project at work, we'd end up with the same variable being referenced different ways. I really wouldn't be able to grep for variables with confidence. (Cf. Carmack: Everything that compiles will ultimately end up in your code. In the context of exploring static analysis tools, which were finding lots of errors.) I do like the idea for uniformity though, but it seems like maybe better to restrict it -- define project-based 'style-rules', and automatically translate when moving between domains. So foo_bar inside package A must be accessed as FooBar inside package B.

carterza 9y ago

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

mlevental 9y ago
how does it compile to wasm if it has a GC?
- jitl 9y ago
  Probably it builds the GC into the WebAssembly output.
szemet 9y ago
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 9y ago
  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_controls#Library:_Gtk2 http://rosettacode.org/wiki/GUI_enabling/disabling_of_contro... - 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...)

citycide 9y ago

I think it's hugely underrated. I agree that it really is a fun language to use and as someone who came to it from a web dev perspective with no prior system level experience I had no trouble at all being productive in it (I built four internal Windows GUI apps with it). But there's also some things that make people nervous -- like case & style insensitive names (ie. `read_file` is equivalent to `readFile`) -- that are almost never an actual issue. Having that be more widely understood would do a lot of favors for Nim, and once the language hits a stable 1.0 I could see it getting a lot more attention.

dilap 9y ago
> But there's also some things that make people nervous -- like case & style insensitive names (ie. `read_file` is equivalent to `readFile`) -- that are almost never an actual issue. Gahhh, why would you do this? It just seems like it'd be a nightmare to use grep to understand your codebase.
- nimmer 9y ago
  I use Nim a lot and I've never seen libraries that mix different styles. I use grep without issues. Style insensitivity is useful when wrapping C libraries.
- citycide 9y ago
  This is exactly my point when I say it needs to be better understood: you wouldn't do it within a single project, but if you've got a third party library that exposes a `read_file` method you can use it as `readFile` meaning your own code base is more consistent. In other words, you're not limited by the design decisions of another developer (or language, as nimmer pointed out).
  - dilap 9y ago
    Thanks, that's interesting. I see the justification for it, at least. I don't know if the whole world is magically living with much more orderly developers than I have had the pleasure to work with, but I guarantee you that if I were using such a project at work, we'd end up with the same variable being referenced different ways. I really wouldn't be able to grep for variables with confidence. (Cf. Carmack: Everything that compiles will ultimately end up in your code. In the context of exploring static analysis tools, which were finding lots of errors.) I do like the idea for uniformity though, but it seems like maybe better to restrict it -- define project-based 'style-rules', and automatically translate when moving between domains. So foo_bar inside package A must be accessed as FooBar inside package B.