5 ms·

I played around with Nim a little and was amazed at how small the executables were: 10s of KB for something simple. Even Rust spits out 100s of KB, or even >1MB

by untog 6y ago

I played around with Nim a little and was amazed at how small the executables were: 10s of KB for something simple. Even Rust spits out 100s of KB, or even >1MB by default. In the end I still went with Rust, simply because it's more popular, but my initial impression was that Nim is a really fun language to work in, and much much easier to pick up than Rust.

anta40 6y ago
"and much much easier to pick up than Rust." That's my impression so far, too. Previously, I already had some experiences with C, Pascal, and Python. Then learning Nim just feels natural. Not so much with Rust. Well of course it's not surprising, with memory safety as one of its goals.
- untog 6y ago
  Yes, I think for me Nim could be a great answer for when I want to throw together a quick script. Right now I'll often use JS/Node for that and I'm not going to switch to Rust because it'll take a lot longer to get a rough and ready script going.
  - cb321 6y ago
    Nim is indeed a great answer for this. Should you want to give that script a nice, traditional CLI then you can do so with very low effort using https://github.com/c-blake/cligen https://github.com/c-blake/cligen Should you want "script like" edit-test development cycle ergonomics you can use the TinyCC/tcc backend for compiles in ~200..300 milliseconds. Once it's how you like it you can compile with gcc & -d:danger for max performance in deployment.
  - treeform 6y ago
    I have so many little nim scripts all over the place.
    - cb321 6y ago
      Unmentioned so far is the NimScript mode `nim e`..For a portable sort of alternative to Bash scripting ("sort of" from the presently much longer start-up time...).
- nn3 6y ago
  >Well of course it's not surprising, with memory safety as one of its goals. Where is this idea coming from that memory safety has to be complicated? Nearly all languages (basically everything except C/C++/Assembler) people are using are memory safe. And usually it's not complicated at all.
  - untog 6y ago
    Well Rust's complication is memory safety and the lack of garbage collector. You see similar issues in a language like Swift, but Swift lets you create a memory leak very easily if you're not aware of the issues. Which can be fine when you're just starting out, you can always learn about it later. But Rust isn't so charitable: you must learn about memory safety upfront. The plus side is that it's significantly more difficult to accidentally create a memory leak.
    - dilap 6y ago
      I've only played with Rust a little bit, but I think something that often goes under-remarked is that its ownership system doesn't just give you "static GC" -- it also guarantees no data races for multithreading. This is pretty awesome.
      - mratsim 6y ago
        > no data races for multithreading This is simply not true. Rust borrow checker has no notion of memory models: i.e. sequential consistency, acquire, release or relaxed semantics. The Tokio team needs an additional model checker to ensure no data race in Tokio: - https://github.com/tokio-rs/loom https://github.com/tokio-rs/loom If you want to ensure no data races you need formal verification not a borrow checker, I've compiled my research and a RFC for Nim formal verification here: - https://github.com/mratsim/weave/issues/18 https://github.com/mratsim/weave/issues/18 - https://github.com/nim-lang/RFCs/issues/222 https://github.com/nim-lang/RFCs/issues/222
- cb321 6y ago
  I have never seen anyone say that Rust was easier to pick up than Nim...(Famous last words, I know!)

by untog 6y ago

anta40 6y ago

"and much much easier to pick up than Rust." That's my impression so far, too. Previously, I already had some experiences with C, Pascal, and Python. Then learning Nim just feels natural. Not so much with Rust. Well of course it's not surprising, with memory safety as one of its goals.

untog 6y ago
Yes, I think for me Nim could be a great answer for when I want to throw together a quick script. Right now I'll often use JS/Node for that and I'm not going to switch to Rust because it'll take a lot longer to get a rough and ready script going.
- cb321 6y ago
  Nim is indeed a great answer for this. Should you want to give that script a nice, traditional CLI then you can do so with very low effort using https://github.com/c-blake/cligen https://github.com/c-blake/cligen Should you want "script like" edit-test development cycle ergonomics you can use the TinyCC/tcc backend for compiles in ~200..300 milliseconds. Once it's how you like it you can compile with gcc & -d:danger for max performance in deployment.
- treeform 6y ago
  I have so many little nim scripts all over the place.
  - cb321 6y ago
    Unmentioned so far is the NimScript mode `nim e`..For a portable sort of alternative to Bash scripting ("sort of" from the presently much longer start-up time...).
nn3 6y ago
>Well of course it's not surprising, with memory safety as one of its goals. Where is this idea coming from that memory safety has to be complicated? Nearly all languages (basically everything except C/C++/Assembler) people are using are memory safe. And usually it's not complicated at all.
- untog 6y ago
  Well Rust's complication is memory safety and the lack of garbage collector. You see similar issues in a language like Swift, but Swift lets you create a memory leak very easily if you're not aware of the issues. Which can be fine when you're just starting out, you can always learn about it later. But Rust isn't so charitable: you must learn about memory safety upfront. The plus side is that it's significantly more difficult to accidentally create a memory leak.
  - dilap 6y ago
    I've only played with Rust a little bit, but I think something that often goes under-remarked is that its ownership system doesn't just give you "static GC" -- it also guarantees no data races for multithreading. This is pretty awesome.
    - mratsim 6y ago
      > no data races for multithreading This is simply not true. Rust borrow checker has no notion of memory models: i.e. sequential consistency, acquire, release or relaxed semantics. The Tokio team needs an additional model checker to ensure no data race in Tokio: - https://github.com/tokio-rs/loom https://github.com/tokio-rs/loom If you want to ensure no data races you need formal verification not a borrow checker, I've compiled my research and a RFC for Nim formal verification here: - https://github.com/mratsim/weave/issues/18 https://github.com/mratsim/weave/issues/18 - https://github.com/nim-lang/RFCs/issues/222 https://github.com/nim-lang/RFCs/issues/222
cb321 6y ago
I have never seen anyone say that Rust was easier to pick up than Nim...(Famous last words, I know!)