First, sorry if my colorful language in the subject is irritating. For me I feel like it is the most accurate word.
http://www.quora.com/Can-anyone-compare-and-contrast-Rust-and-Nim
I posted tables from def's article in an answer on Quora about the difference between Rust and Nim.
Two very funny things about that post on HN. First, someone mentioned excitedly about how much faster their --release was or whatever, expecting that would make Rust the fastest. Nope, still slow. LOL.
Then a core Rust guy tried to update the Rust Make a Lisp code, which according to them was out of date because of so many Rust changes, and he had to give up, because it was too hard. For HIM -- a core contributor and evangelist. LOL.
Edit: Note that these are just rough measurements to see that the Nim implementation is doing fine. Don't judge the other languages for their numbers, which may not have ideal implementations performance-wise.
It's great to see Nim doing well, and you are, of course, free to talk as you please. However, this "na na, our language is better than yours!!" attitude is surely not helpful to Nim.
Rust is still new, as is Nim. Both language's have noble designs with a focus on runtime performance. Things are bound to improve with both in many areas as time goes on. It may very well be we see Rust beat Nim in some future benchmarks to one degree or another (in fact, that's already the case.. just not as often so far). It's not only premature to howl superiority, it also makes us look petty. Nim and Rust's designs are actually somewhat complementary.. and I wouldn't doubt seeing these two languages play nice with each other in future projects (one having more focus on security, the other on practicality.. both with high performance and similar type systems).
That said, it is difficult not to praise Nim a bit here. The fact that it's consistently seen at the top of these charts with such a small development team is definitely worth commemorating.
filwit: However, this "na na, our language is better than yours!!" attitude is surely not helpful to Nim.
Yes, exactly. Nim can stand on its own merits; if one wants to cite benchmarks (keeping in mind that these are often not very meaningful, at least when considered in isolation), it's best to take the high road and do that as neutrally as possible. Good performance speaks for itself, aggressive language advocacy is off-putting.
..an objective measurement of 'safety' will prove that aspect to be mainly a red herring.
You can't objectively measure 'safety' when it's used in that context, because it doesn't actually mean anything. I'm interested in rational discussion and empirical evidence. When I see post by a Rust supporter/evangelist that boils down to "Nim is unsafe because (hand waving bla bla bla)", it's time for me to move along. Plenty of better things to do. :)
To me though that's where the discussion is, and there is one.. and Nim doesn't need to get better, but I have a feeling that it can actually provide some of the features Rust advertises in at least some circumstances without a huge amount of effort.
There has got to be some real way to measure safety or it has to be a real thing, otherwise there wouldn't be such a huge engineering effort behind it. Perhaps some set of inputs or a test harness that feeds input into benchmark programs to crash them or provide other type of 'safety' failures.
And if language 'safety' really overblown as we suspect it is in these comparisons, then that shouldn't be a secret.
runvnc, I wish you hadn't chosen that title. I agree with filwit and Jehan, Nim advocates should take the high road and stay respectful.
Please don't shut up, just make compelling arguments. I agree with you about the attempts to push Rust into ordinary applications programming, or game programming, or scientific computing. IMO, Nim is a better choice than Rust for these, but IF Rust is successful then it will grab a chunk of the high integrity programming outside of Servo and that's fine. Nim is a wide spectrum language, Rust is not.I'd like to see Nim competing with C++, Python, Java, Fortran, MATLAB, and Julia. It can!
To be blunt, Rust is butt ugly. For me, Rust's memory safety and Crate.io make it appealing vs a language like C++, but then again, if I was reaching for C++, I'm not sure I would want perfect memory safety. At the end of the day, rustvnc is right - it's astounding how much buzz Rust gets on HN. You know, I get it. Rust is an interesting language, and it's surely got potential, but not in the same way Nim does, because Nim's syntax is beautiful, and accessible to beginners. You can almost immediately begin reading and writing it, no questions asked.
It would be awesome to get Nim featured on FLOSS Weekly. This is an incredibly exciting new programming language deserving of much more attention.
M: it's astounding how much buzz Rust gets on HN.
This has little to do with Rust vs. Nim or any other languages, though, but mostly with people looking for a memory-safe language that does not have garbage collection. The issue here is not a language issue, but popular misconceptions about GC. There are very, very few niches where garbage collection is not the best answer to memory safety concerns. The hard part is combating GC FUD, such as this disconcertingly uninformed screed [1]. But this has little to do with Rust vs. other languages, and the Rust implementors themselves are actually very knowledgeable about modern GCs.
I note that this is not to say that garbage collection is a silver bullet; but the tradeoffs involved in using a modern GC suitable for your domain are for the vast majority of applications better than the tradeoffs you have to make without one.
That said, Rust does (a) solve an important problem for those niches where GC is the wrong approach and (b) has significantly advanced the state of the art for practical implementations of lifetime and ownership concerns, and that alone makes it a very, very valuable project.
[1] For example, in pulling a random chart about GC performance out of a paper, he (a) doesn't really understand what it's saying and (b) generalizes data about non-generational mark and sweep/semispace GCs to all types of GCs, even though the data in the very same chart about generational GCs contradicts his claim.
Just for the records, I agree completely with what Jehan and filwit said.
Rust vs Nim is not only the question of manual memory management vs GC (as default), but also about thread-local allocation vs shared heap allocation (as default). Passing ownership around without overhead is only really possible when the allocations start off a single shared heap. Which is a route I really don't want to take and the GC question is somewhat orthogonal to this very important design decision.