I really wouldn't consider it reasonable comparison, when one language has a sufficient compiler that is written in itself for most part, and the other still only compiles to C.
A Quick Comparison of Nim vs. Rust
31–40 of 94 posts
Re: A Quick Comparison of Nim vs. Rust
#32Earlier quoted context omitted.
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 { .. } can be replaced with match map.entry(word) { Occupied(mut view) => { *view.get_mut() += 1; } Vacant(view) => { view.insert(1); } }
Good point! I’ve updated the article accordingly. I learned the Entry thing a few months ago, but Rust’s BTreeMap did not support the entry API at that time, so my code did not use it. Then I totally forgot about it when writing this blog...
Re: A Quick Comparison of Nim vs. Rust
#33I 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.
Yes, I think Nim deserves more attention, and that’s part of the reason I wrote this article.
Re: A Quick Comparison of Nim vs. Rust
#34I really wouldn't consider it reasonable comparison, when one language has a sufficient compiler that is written in itself for most part, and the other still only compiles to C.
Why should such comparison be unreasonable? The fact that a compiler internally produces C/Assembly/Brainfuck/whatever code to produce the final binary should be relevant only for computer science theorists, not for the majority of the users out there (like me).
Also, I find one of your statements quite contradictory: by saying that Rust's compiler "is written in itself", you seem to imply that Nim is not. But this is not true: Nim's compiler is almost 100% pure Nim.
(Last but not least: to me it seems not true that Nim "only compiles to C", as it provides multiple backends. See here: http://nim-lang.org/backends.html .)
Re: A Quick Comparison of Nim vs. Rust
#35It'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 follo…
On the other hand, it's quite convenient if you can't remember the exact name and it saves you a look-up e.g. quick_sort vs quicksort vs quickSort - either work
Re: A Quick Comparison of Nim vs. Rust
#36It'd be good to see how these new languages compare to established ones that offer similar features - maybe OCaml and Haskell.
Re: A Quick Comparison of Nim vs. Rust
#37I really wouldn't consider it reasonable comparison, when one language has a sufficient compiler that is written in itself for most part, and the other still only compiles to C.
Why should such comparison be unreasonable? The fact that a compiler internally produces C/Assembly/Brainfuck/whatever code to produce the final binary should be relevant only for computer science theorists, not for the majority of the users out there (like me). Also, I find one of your statements quite contradictory: by saying that Rust's compiler "is written in itself", you seem to imply that Nim is not. But this i…
Perhaps I have had a wrong impression since I read on Nim quite a while ago last time and should checkout this article now. Thatnks for pointing this out!
Re: A Quick Comparison of Nim vs. Rust
#38Nim needs to move it's discussions to a mailing list if the authors want to gain more serious developers onboard.
Polling a poorly implemented web forum speaks leaps and bounds about the kind of attitude you need to have to discuss, develop or debug issues around the Nim toolchain.
This is something that Nim developers can instantly do to boost the attractiveness of the language.
Please, do this.
Re: A Quick Comparison of Nim vs. Rust
#39Earlier 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…
Slightly confusingly, the authors BTreeMap just appears to be a binary tree, while the standard library BTreeMap is a B-tree: http://en.wikipedia.org/wiki/B-tree
Re: A Quick Comparison of Nim vs. Rust
#40From 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?
The compiler does not need to be compiled for the cross-target to just run binaries, just the standard library like C; but, once they exist, running the compiler directly with `rustc --target=...` and using the dependency/build manager cargo `cargo build --target=...` both work fine.
Of course, it is harder to obtain cross-compiled versions of the Rust standard library at the moment, so what you say is likely true.