* 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
Actually Nim does offer something new in this regard. See 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".
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.
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.
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)
Rather, your comment seemed rather "tribal" while criticizing Rust fans of the same.
BTW, I would see Nim more as a competitor to D, Swift and Java than to Rust.
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.
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-muslThere's a fair bit of overlap for obvious reasons: they're two languages suited for the same tasks, after all :)
> 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
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.
Rust is possibly an ideal language for game development. Standard Rust has no runtime component, which is perfect. It's also a high-performance language.
The ecosystem for Rust game development is immature, but there's progress being made.
https://www.reddit.com/r/rust/comments/9twam5/jemalloc_was_j...
Trying to promote Nim like you are doing might in fact have the opposite effect :/
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.
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.).