One thing they both lack that hinders wider adoption : good IDE support. For me YouCompleteMe support is the only thing preventing me from switching for my side projects.
How can you base the choice of a language solely on that?
A Quick Comparison of Nim vs. Rust
21–30 of 94 posts
Re: A Quick Comparison of Nim vs. Rust
#22From what I have read, Nim has a much better cross-compilation story (i.e. it delegates to the available C cross-compilation toolchain instead of requiring the Nim compiler and toolchain to be compiled for the cross target).
Rust, as I understand, requires the Rust compiler to be compiled for the cross-target; is this correct?
Re: A Quick Comparison of Nim vs. Rust
#23Earlier quoted context omitted.
I believe you can turn off the GC for Nim. Then you're just limited to libraries that don't rely on the GC, and fully manual memory management.
This is more of an option than you might think. Nim plugs in to C libraries much easier than you would expect from an FFI. That means even if the stdlib depends on the GC heavily, you can eschew it for the C stdlib. For example: proc printf(formatstr: cstring) {.header: " ", importc: "printf", varargs.} I'd be interested in seeing a comparison of higher level language features rather than performance (which is genera…
Wow, that's a pretty cool insight. Basically that means you could use "Nim without GC" as "a better C". I can see very few downsides. You could probably start using it in existing C projects much like you could start adding .scala files to an existing Java project.
Re: A Quick Comparison of Nim vs. Rust
#24I like how articles like this help elevate Nim's status. To me, deep inside, Rust always felt like this grand high-stakes project, by wise people at this big experienced company Mozilla, and Nim felt like a hobby project that got out of hand. That's an entirely unfair judgment of course, but I bet more people feel that way. I like that Nim is starting to get the attention it deserves.
Re: A Quick Comparison of Nim vs. Rust
#25I'm starting to really wish there was a GC-free (or at least) GC optional version of Nim. Nim with Rust's memory semantics would just be the best of everything.
Optional gc is tricky, as you would need all libraries written this way
This is one of the reasons why the Objective-C GC failed.
It just didn't work out mixing Frameworks compiled in different modes, many times leading to crashes.
Re: A Quick Comparison of Nim vs. Rust
#26Earlier quoted context omitted.
You're still comparing two different data structures. Is there a good hash table in Rust? If you use that instead of the B-tree, I would expect it to be at least as fast as Nim. B-trees are especially bad for string keys, because comparisons are expensive. EDIT: From Rust docs: "Currently, our implementation simply performs naive linear search. This provides excellent performance on small nodes of elements which are…
It turns out `collections::HashMap` runs about 6~7% faster than BTreeMap. I will update the article to include results of both data structures.
Also seems like you could benefit from the entry() api (available on both BTreeMap and HashMap):
http://doc.rust-lang.org/std/collections/struct.BTreeMap.htm...
I think the example used in the docs is your exact use case.
This bit:
let found = match map.get_mut(..) {
..
}
if !found {
..
}
match map.entry(word) {
Occupied(mut view) => { *view.get_mut() += 1; }
Vacant(view) => { view.insert(1); }
}Re: A Quick Comparison of Nim vs. Rust
#27It's feels like a shame to me that the one Python maxim that Nim has chosen to reject is "there should be one and preferably only one way to do it" - from this flows so much of the other goodness of the Python ecosystem. I worry that some of the metaprogramming magic that Nim allows will result in the loss of that feeling that I can view source on almost any 3rd party Python code and immediately feel like I can follow what's going on. Maybe community standards can help restrain this somewhat.
Also:
> mapWidth, mapwidth and map_width all map to the same name
Why or why? Editors and IDEs now need Nim-aware search code!?
Re: A Quick Comparison of Nim vs. Rust
#28Earlier quoted context omitted.
This seems an odd choice to me (default to B-Tree instead of hash map). I'd expect a sorted map to be a special case, not a general one. Do you happen to know the rationale? Not criticizing, just curious.
It's a poor choice on the author's part http://doc.rust-lang.org/std/collections/ Use a HashMap when: - You want to associate arbitrary keys with an arbitrary value. - You want a cache. - You want a map, with no extra functionality. Use a BTreeMap when: - You're interested in what the smallest or largest key-value pair is. - You want to find the largest or smallest key that is smaller or larger than something - You w…
I chose it because I wanted to learn Rust by implementing my own BTreeMap struct. I admit it’s not a good choice performance-wise, and made the comparison with Nim less meaningful.
I’ve updated the code and article with HashMap. It runs about 6~7% faster than BTreeMap.
Re: A Quick Comparison of Nim vs. Rust
#29I'm starting to really wish there was a GC-free (or at least) GC optional version of Nim. Nim with Rust's memory semantics would just be the best of everything.
Well, that's kinda the point. If there was a better way to have to achieve GC-free semantics, Rust would have taken it. As for optional GC, didn't D haven't something along those lines?
Like Nim you can disable the GC in D.
AFAIK, most libraries won't handle that situation gracefully as they don't expect it.
Re: A Quick Comparison of Nim vs. Rust
#30From what I have read, Nim has a much better cross-compilation story (i.e. it delegates to the available C cross-compilation toolchain instead of requiring the Nim compiler and toolchain to be compiled for the cross target). Rust, as I understand, requires the Rust compiler to be compiled for the cross-target; is this correct?
llvm has pretty good cross compiler support, So I don't know.