Here's a pure code comparison of Nim vs Rust: http://rosetta.alhur.es/compare/nimrod/rust/
A Quick Comparison of Nim vs. Rust
51–60 of 94 posts
Re: A Quick Comparison of Nim vs. Rust
#52Earlier quoted context omitted.
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
I do not get it - what kind of "win" is it? For example, I know that PHP functions are case-insensitive, but we got to the point where we run linters to check if we used the same case as in declaration. Why not simply bake it in the compiler, especially when you HAVE a compiler?
Perhaps it's a reaction to the state of affairs in C++.
In Java and C# there are pretty widely adhered to coding standards. It's quite hard to find libraries that don't have consistent public APIs with these standards, and those that differ are usually subject to rumblings on their mailing lists and issue trackers.
In C++ there is no agreed upon standard. The standard library uses lower_train_case for all (public) types/members, and much 3rd party library code uses PascalCase and camelCase. The C++ standard library has fewer features than the Java/C#/Python standard libraries, and so you end up bringing more 3rd party code into non-trivial projects (in my experience).
If this feature existed in C++, a codebase could be much more internally consistent. However I'm still not sure I'd like this feature to be available. Certainly it's not possible to add it after-the-fact due to potential conflicts between members that differed by case.
Re: A Quick Comparison of Nim vs. Rust
#53Here's a pure code comparison of Nim vs Rust: http://rosetta.alhur.es/compare/nimrod/rust/
That's partially outdated for Rust, but I guess Rust is too much of a moving target.
For example `from_str::` should be `.parse()` today.
Re: A Quick Comparison of Nim vs. Rust
#54Here's a pure code comparison of Nim vs Rust: http://rosetta.alhur.es/compare/nimrod/rust/
That's partially outdated for Rust, but I guess Rust is too much of a moving target. For example `from_str:: ` should be `.parse()` today.
The code samples are from the RosettaCode[1]. They are probably lacking a frequent contributor for making and fixing Rust code examples.
Re: A Quick Comparison of Nim vs. Rust
#55It'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…
It allows you to use your own style everywhere, instead of relying on the specific styles of the library you used (so you don't end up in your code with camelCase AND snake_case). It's definitely unusual, but I think it works quite well.
This is largely a matter of taste, but I think go has it exactly right. Ruthlessly enforce only one way, and make that as mandatory as possible.
Having code which is formatted as uniformly as possible is a huge boon. Rules are better than norms, especially if there is zero cost of enforcing them.
Re: A Quick Comparison of Nim vs. Rust
#56you mean nimrod, right?
Re: A Quick Comparison of Nim vs. Rust
#57I like Nim. I used it for a few side-projects as well. The only thing it definitely needs before feeling really solid is trait (interface, contracts or whatever you call it) support IMHO. Current alternative is "compiler does copy-paste for you", aka templates. See: https://github.com/Araq/Nim/blob/master/lib/pure/collections...
Re: A Quick Comparison of Nim vs. Rust
#58Earlier quoted context omitted.
I do not get it - what kind of "win" is it? For example, I know that PHP functions are case-insensitive, but we got to the point where we run linters to check if we used the same case as in declaration. Why not simply bake it in the compiler, especially when you HAVE a compiler?
Perhaps it's a reaction to the state of affairs in C++. In Java and C# there are pretty widely adhered to coding standards. It's quite hard to find libraries that don't have consistent public APIs with these standards, and those that differ are usually subject to rumblings on their mailing lists and issue trackers. In C++ there is no agreed upon standard. The standard library uses lower_train_case for all (public) ty…
I have a vague theory that the design of most programming languages can be understood as a reaction to the pain their designers experienced in their previous language. So, Java is largely C++ without the things that were painful in C++ (manual memory management, multiple inheritance, operator overloading). Nim's unusual handling of compound names is a reaction to something else that was painful in C++.
Hopefully they'll add a Smalltalk/Objective C style format one day.
Re: A Quick Comparison of Nim vs. Rust
#59Are you just using --opt:speed to compile the Nim examples? For maximum performance you should be using -d:release.
Oh, my bad. The numbers differ a lot (2~2.5x faster). I’ve updated the article.
Now it's more in line with my experience of Nim usually being quite a bit faster than Rust, not to mention much easier to write and less verbose (text munging code in Rust seemed to be about 15% calls to as_slice() and to_string ()).
Re: A Quick Comparison of Nim vs. Rust
#60It'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…
> "there should be one and preferably only one way to do it"
In my very humble opinion this idiom is amazing at the start of a language and then it handcuffs it and that is why we have Python 2 or Python 3 issues.
I use to use Python for statistical work and about 2 years ago I switched to R. R is VERY flexible and seen a huge change over the last 5 or so years. It has changed for me especially in the last 6 months with changes in what libraries I use. Using dplyr and other libraries my code is night and day different. We now have piping with %>% that changes me code completely and makes it MUCH more readable and quick to write code. I don't see anything like this happening quickly in Python.