4 ms·

My experience after a couple of weeks: Pros: Extremely good C and C++ interop Significant indentation Very good performance Quick compilation Terse, but readab

by 127 4y ago

My experience after a couple of weeks: Pros: Extremely good C and C++ interop Significant indentation Very good performance Quick compilation Terse, but readable Easy cross platform Powerful macros and close to trivial DSL construction Very little code to do a lot of stuff Incoming future features look very promising Cons: Hard to predict and control program performance, LTO does a lot of heavy lifting Immature ecosystem, because only few users. Many libraries have bugs, missing features or just a very clunky API. Or maybe they are deprecated or abandoned all together. Many different ways to do the same thing everyThingIsCamelCase, ambiguous variable names (subjective) Documentation and tutorials is mostly reading through the code and googling forum posts outside the core language You compile either for C or C++, some libraries simply won't work without C++ compilation

jasfi 4y ago
Nim has several GCs available. For predictable performance you may want to use ARC. See: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc... For my contribution to the ecosystem see Nexus mentioned in another comment. If you see bugs please report them. Sometimes libraries are deprecated/abandoned because of new ideas, this happens in every ecosystem. I personally use camelCase/PascalCase, but Nim is style insensitive, meaning you can call procs written in camelCase using snake case. However this is controversial and under discussion, my personal opinion is to make style sensitivity optional, with insensitivity the default. Ambiguous variable names I hate, you won't see that in Nexus, if anyone does they should file an issue. That's really developer dependent. For my part Nexus has some docs and a basic tutorial. But if people want more they need to ask for it. Why write docs nobody wants or will read? Anyway, this book (Mastering Nim) is one more definite step forward for learning Nim. I think compiling to C is what mostly happens, C++ is probably an outlier. Even then, a C++ compiler isn't difficult to install if needed.
greybox 4y ago
I love nim, but I disagree with the "quick compilation" point here. The compilation is horrendously slow. (by default it compiles down to C, then to exe from there).
- boongeheYOE 4y ago
  In comparison to languages like Rust and C++ it compiles pretty fast. Or maybe you built the compiler in debug mode.
- nimmer 4y ago
  It's much faster than C++, Rust, Go and many others.
  - hahaitsfunny 4y ago
    No, it is not - Nim's compiler backend is extremely complex and full of cruft. I've been around Nim for 7+ years now and there's a reason the compiler was hard forked. Nim's compiler is definitely not speedy, and this is why so much effort has been spent on incremental compilation, which tmk, still isn't working - https://github.com/nim-lang/Nim/issues/19757 https://github.com/nim-lang/Nim/issues/19757.
  - zimpenfish 4y ago
    I'm assuming this must be for huge projects? I just compiled my toy project (detecting anomalous parity in integers) in nim 1.6.6 (4.23s), go 1.17.7 (2.43s to create both aarch64 and x86_64 binaries), zig 0.8.0-dev.1140 (2.04s to create aarch64 and x86_64 binaries) and C via clang 13.1.6 (0.14s). nim's compilation is 175% of Go, 207% of zig, and 3021% of clang.
    - Rochus 4y ago
      Thanks for the data; that's what I call an elegant rebuttal.
    - nimmer 4y ago
      No, even small files. You must have issues with your setup. Are you sure your compiler is not built in debug mode?
      - zimpenfish 4y ago
planetis 4y ago
> Many libraries have bugs, missing features or just a very clunky API. Or maybe they are deprecated or abandoned all together. For me missing libraries never stopped me, I could always port/wrap whatever I needed. However with the advent of AI assisted coding, working on libraries is even faster and at some point I hope I wouldn't spend much time rolling decent libraries that are ports of existing github projects.

by 127 4y ago

jasfi 4y ago

Nim has several GCs available. For predictable performance you may want to use ARC. See: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc... For my contribution to the ecosystem see Nexus mentioned in another comment. If you see bugs please report them. Sometimes libraries are deprecated/abandoned because of new ideas, this happens in every ecosystem. I personally use camelCase/PascalCase, but Nim is style insensitive, meaning you can call procs written in camelCase using snake case. However this is controversial and under discussion, my personal opinion is to make style sensitivity optional, with insensitivity the default. Ambiguous variable names I hate, you won't see that in Nexus, if anyone does they should file an issue. That's really developer dependent. For my part Nexus has some docs and a basic tutorial. But if people want more they need to ask for it. Why write docs nobody wants or will read? Anyway, this book (Mastering Nim) is one more definite step forward for learning Nim. I think compiling to C is what mostly happens, C++ is probably an outlier. Even then, a C++ compiler isn't difficult to install if needed.

greybox 4y ago

I love nim, but I disagree with the "quick compilation" point here. The compilation is horrendously slow. (by default it compiles down to C, then to exe from there).

boongeheYOE 4y ago
In comparison to languages like Rust and C++ it compiles pretty fast. Or maybe you built the compiler in debug mode.
nimmer 4y ago
It's much faster than C++, Rust, Go and many others.
- hahaitsfunny 4y ago
  No, it is not - Nim's compiler backend is extremely complex and full of cruft. I've been around Nim for 7+ years now and there's a reason the compiler was hard forked. Nim's compiler is definitely not speedy, and this is why so much effort has been spent on incremental compilation, which tmk, still isn't working - https://github.com/nim-lang/Nim/issues/19757 https://github.com/nim-lang/Nim/issues/19757.
- zimpenfish 4y ago
  I'm assuming this must be for huge projects? I just compiled my toy project (detecting anomalous parity in integers) in nim 1.6.6 (4.23s), go 1.17.7 (2.43s to create both aarch64 and x86_64 binaries), zig 0.8.0-dev.1140 (2.04s to create aarch64 and x86_64 binaries) and C via clang 13.1.6 (0.14s). nim's compilation is 175% of Go, 207% of zig, and 3021% of clang.
  - Rochus 4y ago
    Thanks for the data; that's what I call an elegant rebuttal.
  - nimmer 4y ago
    No, even small files. You must have issues with your setup. Are you sure your compiler is not built in debug mode?
    - zimpenfish 4y ago

planetis 4y ago

> Many libraries have bugs, missing features or just a very clunky API. Or maybe they are deprecated or abandoned all together. For me missing libraries never stopped me, I could always port/wrap whatever I needed. However with the advent of AI assisted coding, working on libraries is even faster and at some point I hope I wouldn't spend much time rolling decent libraries that are ports of existing github projects.