5 ms·

Nim produces smaller binaries, has zero-pause, realtime gc (and you can even define gc behavior) and compiles to optimized C. It's a win over Rust in every way

Nim produces smaller binaries, has zero-pause, realtime gc (and you can even define gc behavior) and compiles to optimized C. It's a win over Rust in every way including ease of use. Big issue with Nim is tribalism, pure and simple. It's author failed to get any major corporations behind it so it doesn't get hyped up in constant Medium articles and conference talks and therefore does not get a lot of attention, which keeps it a niche language, sadly.

the_duke 8y ago
Nim is a lovely language but I disagree with most of your points. * The Rust borrow checker prevents a lot of issues in C(++) code. Including thread safety. Nim does not provide anything new in this regard. * The lack of a GC is a feature, not a detriment. One of the reasons why Rust applications are often very fast is because the language naturally guides you to avoid allocations when possible and allows low level control where necessary. Combined with the safety guarantees of the borrow checker, this is a powerful combination. This is possible in Nim but using GC is easier and will be the preferred solution when in doubt. * While Mozilla support does help a lot for sure, a lot of the hype around Rust (imo) comes from people trying it out, just falling in love with and then promoting it
- discoball 8y ago
  << While Mozilla support does help a lot for sure, a lot of the hype around Rust (imo) comes from people trying it out, just falling in love with and then promoting it >> If there was no rampant tribalism, my comment would not be buried with negative votes. It would receive a response like the one you gave, which is subjective, and that would be the end of it. Some may even up-vote it because diversity is always good. But feels like Rust users are zealous and it's a bad sign, tbh. Wouldn't want to be part of a community that acted with hostility towards others for presenting alternative view points.
  - the_duke 8y ago
    You were downvoted because your claims were not substantiated by factual analysis. Rather, your comment seemed rather "tribal" while criticizing Rust fans of the same.
    - discoball 8y ago
      True.
      - the_duke 8y ago
        Cheers for owning up to it. BTW, I would see Nim more as a competitor to D, Swift and Java than to Rust.
        kungtotte 8y ago
        I think Nim absolutely has a place competing with Rust too. It has several tunable GCs allowing for great flexibility there, and also supports running with no GC at all. It compiles to C that will compile nearly anywhere C does. It produces smaller binaries, and it can easily link against musl instead of libc for an even lighter footprint. It's also safe like Rust is, and the compiler will help you catch a ton of errors. That's not to say that it's competitive at this point in time. It's much more unstable as a language due to not reaching 1.0 yet. They only just (August) received any real kind of funding, allowing them to hire on a new developer but it's still just a handful of core devs and some dedicated contributors. The standard library and the community repo (Nimble) can't compare with Rust's and Cargo in terms of package availability and support.
        bluejekyll 8y ago
        > it can easily link against musl instead of libc for an even lighter footprint I'm not sure if you were implying that it doesn't, but Rust also supports musl: $> rustup target list | rg musl aarch64-unknown-linux-musl arm-unknown-linux-musleabi arm-unknown-linux-musleabihf armv5te-unknown-linux-musleabi armv7-unknown-linux-musleabihf i586-unknown-linux-musl i686-unknown-linux-musl mips-unknown-linux-musl mipsel-unknown-linux-musl powerpc64le-unknown-linux-musl x86_64-unknown-linux-musl
  - Majestic121 8y ago
    I think you're getting downvote because you're being very tribal about Nim, and apparently not open for discussion : "It's a win over Rust in every way including ease of use." You can paint others opinion as being subjective, which they are, but you would be wise to realize yours are as well. That's what's bringing hostility, not the diversity of viewpoint (there's a lot of talks about Go in the thread for example)
    - discoball 8y ago
      Yes, true.
  - OpenBSD-reich 8y ago
    It's the systemd of languages, in that it solves problems already solved and is heavily evangelized as the best thing since sliced bread.
- dom96 8y ago
  > The Rust borrow checker prevents a lot of issues in C(++) code. Including thread safety. Nim does not provide anything new in this regard. Actually Nim does offer something new in this regard. See https://nim-lang.org/docs/manual.html#guards-and-locks https://nim-lang.org/docs/manual.html#guards-and-locks. > While Mozilla support does help a lot for sure, a lot of the hype around Rust (imo) comes from people trying it out, just falling in love with and then promoting it AFAIK Rust was a much different language before Mozilla officially adopted it (wasn't the borrow checker implemented after Mozilla sponsorship?). So not only was it not the same language, it wasn't known at all. Don't underestimate the power of full-time developers working on a programming language and having the support of a well known organisation behind them. Sadly a lot of the hype is simply "omg, Mozilla uses this langauge" or "omg, Google uses this language".
  - tathougies 8y ago
    Nim is garbage collected, which means it doesn't need borrow checking. Garbage collection in threaded languages is a well studied problem. Safe threading in a statically collected language is new.
  - imtringued 8y ago
    This is clearly a better solution compared to the average language but what if you forget to mark a field or object as guarded? Just take a look at the basic problem of multi-threading: two threads write to the same memory location. This situation is unpredictable and there never allowed to happen. There are three general strategies to deal with this: immutability, mutexes and linear types to ensure there is only one reference with write capability. The latter makes writing code that is not thread-safe impossible at compile time without sacrificing efficiency and is used by at least two programming languages that I know of: Ponylang and Rust. For me impossible vs "oops forgot to guard it" are worlds apart. The compiler will inform you that it is not thread-safe and then you can decide to use a different solution like a mutex if necessary.
palotasb 8y ago
In every way? One could argue that having a GC is a disadvantage compared to Rust regardless of how good a GC it is. Main reason for that is because it might still introduce unnecessary runtime overhead.
- nimmer 8y ago
  It does not.
  - monocasa 8y ago
    GCs absolutely increase memory pressure overhead, or are so conservative that they practically lead to slow leaks. You have to keep that metadata of "what is and isn't a pointer" somewhere and that comes with a cost.
    - nimmer 8y ago
      Memory pressure is a different thing. And, once again, GC is optional.
      - monocasa 8y ago
        > Memory pressure is a different thing. No it isn't. The GC has to touch that data, which means it's cache pressure, which means it's perf pressure. > And, once again, GC is optional. Sure, but it's an exclusive choice between memory safety and speed. Other languages let you have your cake and eat it too in that respect (Cyclone, Rust, etc.).
- tcoff91 8y ago
  Also what about the data race detection stuff that rust does? A GC does not stop data races.
grogers 8y ago
https://nim-lang.org/docs/gc.html https://nim-lang.org/docs/gc.html > Tests show that a 2ms max pause time will be met in almost all cases on modern CPUs (with the cycle collector disabled). So in a reduced mode, pause times are only bounded by 2ms. Not sure how you could say that is zero pause
- discoball 8y ago
  Sorry, within 2ms not absolute 0, but to me it might as well be zero I've yet to notice it in practice.
  - mkl 8y ago
    For a network driver, 2ms seems enormous. At 1Gbps that's 250 kilobytes, which is an awful lot of packets.
    - discoball 8y ago
      But GC doesn’t run continuously! Sure, device drivers and kernel modules should be built in C. Everything else is an approximation.
- jononor 8y ago
  Certainly not zero, but probably enough for hitting the frame deadline for 60fps graphics (16ms). Could even enough for real-time audio processing (at 4ms or 8ms). That will cover the vast majority of latency requirements that application developers using an OS deals with. Some embedded realtime cases might have more strict deadline requirements, or be complicated by the potential jitter that a GC might intoduce. Eg most discrete math used in motor control systems assumes a fixed sample period.
  - chc 8y ago
    I haven't done game dev beyond hobbyist level, but 12.5% of your total budget for a frame seems pretty significant. Is that kind of percentage hit generally considered negligible?
dom96 8y ago
I appreciate your enthusiasm for Nim, but even I (as a Nim core dev) wouldn't say that Nim is better than Rust in every way. Trying to promote Nim like you are doing might in fact have the opposite effect :/
- discoball 8y ago
  Appreciate your work on Nim. My statement is based on my opinion. There are certainly imperfections in Nim even bugs and things that annoy me but the mental load is far less than working in Rust, for me that is, and so to me it is better in every way since in the end I find it to be congruent with my mental model whereas I can’t say the same about Rust. It is a purely opinionated statement like everything else where meaning is involved. We are the meaning makers. It doesn’t exist in detached form. Your opinion is valid.

the_duke 8y ago

Nim is a lovely language but I disagree with most of your points. * The Rust borrow checker prevents a lot of issues in C(++) code. Including thread safety. Nim does not provide anything new in this regard. * The lack of a GC is a feature, not a detriment. One of the reasons why Rust applications are often very fast is because the language naturally guides you to avoid allocations when possible and allows low level control where necessary. Combined with the safety guarantees of the borrow checker, this is a powerful combination. This is possible in Nim but using GC is easier and will be the preferred solution when in doubt. * While Mozilla support does help a lot for sure, a lot of the hype around Rust (imo) comes from people trying it out, just falling in love with and then promoting it

discoball 8y ago
<< While Mozilla support does help a lot for sure, a lot of the hype around Rust (imo) comes from people trying it out, just falling in love with and then promoting it >> If there was no rampant tribalism, my comment would not be buried with negative votes. It would receive a response like the one you gave, which is subjective, and that would be the end of it. Some may even up-vote it because diversity is always good. But feels like Rust users are zealous and it's a bad sign, tbh. Wouldn't want to be part of a community that acted with hostility towards others for presenting alternative view points.
- the_duke 8y ago
  You were downvoted because your claims were not substantiated by factual analysis. Rather, your comment seemed rather "tribal" while criticizing Rust fans of the same.
  - discoball 8y ago
    True.
    - the_duke 8y ago
      Cheers for owning up to it. BTW, I would see Nim more as a competitor to D, Swift and Java than to Rust.
      - kungtotte 8y ago
        I think Nim absolutely has a place competing with Rust too. It has several tunable GCs allowing for great flexibility there, and also supports running with no GC at all. It compiles to C that will compile nearly anywhere C does. It produces smaller binaries, and it can easily link against musl instead of libc for an even lighter footprint. It's also safe like Rust is, and the compiler will help you catch a ton of errors. That's not to say that it's competitive at this point in time. It's much more unstable as a language due to not reaching 1.0 yet. They only just (August) received any real kind of funding, allowing them to hire on a new developer but it's still just a handful of core devs and some dedicated contributors. The standard library and the community repo (Nimble) can't compare with Rust's and Cargo in terms of package availability and support.
        bluejekyll 8y ago
        > it can easily link against musl instead of libc for an even lighter footprint I'm not sure if you were implying that it doesn't, but Rust also supports musl: $> rustup target list | rg musl aarch64-unknown-linux-musl arm-unknown-linux-musleabi arm-unknown-linux-musleabihf armv5te-unknown-linux-musleabi armv7-unknown-linux-musleabihf i586-unknown-linux-musl i686-unknown-linux-musl mips-unknown-linux-musl mipsel-unknown-linux-musl powerpc64le-unknown-linux-musl x86_64-unknown-linux-musl
- Majestic121 8y ago
  I think you're getting downvote because you're being very tribal about Nim, and apparently not open for discussion : "It's a win over Rust in every way including ease of use." You can paint others opinion as being subjective, which they are, but you would be wise to realize yours are as well. That's what's bringing hostility, not the diversity of viewpoint (there's a lot of talks about Go in the thread for example)
  - discoball 8y ago
    Yes, true.
- OpenBSD-reich 8y ago
  It's the systemd of languages, in that it solves problems already solved and is heavily evangelized as the best thing since sliced bread.
dom96 8y ago
> The Rust borrow checker prevents a lot of issues in C(++) code. Including thread safety. Nim does not provide anything new in this regard. Actually Nim does offer something new in this regard. See https://nim-lang.org/docs/manual.html#guards-and-locks https://nim-lang.org/docs/manual.html#guards-and-locks. > While Mozilla support does help a lot for sure, a lot of the hype around Rust (imo) comes from people trying it out, just falling in love with and then promoting it AFAIK Rust was a much different language before Mozilla officially adopted it (wasn't the borrow checker implemented after Mozilla sponsorship?). So not only was it not the same language, it wasn't known at all. Don't underestimate the power of full-time developers working on a programming language and having the support of a well known organisation behind them. Sadly a lot of the hype is simply "omg, Mozilla uses this langauge" or "omg, Google uses this language".
- tathougies 8y ago
  Nim is garbage collected, which means it doesn't need borrow checking. Garbage collection in threaded languages is a well studied problem. Safe threading in a statically collected language is new.
- imtringued 8y ago
  This is clearly a better solution compared to the average language but what if you forget to mark a field or object as guarded? Just take a look at the basic problem of multi-threading: two threads write to the same memory location. This situation is unpredictable and there never allowed to happen. There are three general strategies to deal with this: immutability, mutexes and linear types to ensure there is only one reference with write capability. The latter makes writing code that is not thread-safe impossible at compile time without sacrificing efficiency and is used by at least two programming languages that I know of: Ponylang and Rust. For me impossible vs "oops forgot to guard it" are worlds apart. The compiler will inform you that it is not thread-safe and then you can decide to use a different solution like a mutex if necessary.

palotasb 8y ago

In every way? One could argue that having a GC is a disadvantage compared to Rust regardless of how good a GC it is. Main reason for that is because it might still introduce unnecessary runtime overhead.

nimmer 8y ago
It does not.
- monocasa 8y ago
  GCs absolutely increase memory pressure overhead, or are so conservative that they practically lead to slow leaks. You have to keep that metadata of "what is and isn't a pointer" somewhere and that comes with a cost.
  - nimmer 8y ago
    Memory pressure is a different thing. And, once again, GC is optional.
    - monocasa 8y ago
      > Memory pressure is a different thing. No it isn't. The GC has to touch that data, which means it's cache pressure, which means it's perf pressure. > And, once again, GC is optional. Sure, but it's an exclusive choice between memory safety and speed. Other languages let you have your cake and eat it too in that respect (Cyclone, Rust, etc.).
tcoff91 8y ago
Also what about the data race detection stuff that rust does? A GC does not stop data races.

grogers 8y ago

https://nim-lang.org/docs/gc.html https://nim-lang.org/docs/gc.html > Tests show that a 2ms max pause time will be met in almost all cases on modern CPUs (with the cycle collector disabled). So in a reduced mode, pause times are only bounded by 2ms. Not sure how you could say that is zero pause

discoball 8y ago
Sorry, within 2ms not absolute 0, but to me it might as well be zero I've yet to notice it in practice.
- mkl 8y ago
  For a network driver, 2ms seems enormous. At 1Gbps that's 250 kilobytes, which is an awful lot of packets.
  - discoball 8y ago
    But GC doesn’t run continuously! Sure, device drivers and kernel modules should be built in C. Everything else is an approximation.
jononor 8y ago
Certainly not zero, but probably enough for hitting the frame deadline for 60fps graphics (16ms). Could even enough for real-time audio processing (at 4ms or 8ms). That will cover the vast majority of latency requirements that application developers using an OS deals with. Some embedded realtime cases might have more strict deadline requirements, or be complicated by the potential jitter that a GC might intoduce. Eg most discrete math used in motor control systems assumes a fixed sample period.
- chc 8y ago
  I haven't done game dev beyond hobbyist level, but 12.5% of your total budget for a frame seems pretty significant. Is that kind of percentage hit generally considered negligible?

dom96 8y ago

I appreciate your enthusiasm for Nim, but even I (as a Nim core dev) wouldn't say that Nim is better than Rust in every way. Trying to promote Nim like you are doing might in fact have the opposite effect :/

discoball 8y ago
Appreciate your work on Nim. My statement is based on my opinion. There are certainly imperfections in Nim even bugs and things that annoy me but the mental load is far less than working in Rust, for me that is, and so to me it is better in every way since in the end I find it to be congruent with my mental model whereas I can’t say the same about Rust. It is a purely opinionated statement like everything else where meaning is involved. We are the meaning makers. It doesn’t exist in detached form. Your opinion is valid.