61–70 of 94 posts
Earlier 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
That means that all three forms will wind up in any Nim project that gets large enough, though. Hardly a good thing.
Earlier quoted context omitted.
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. [1]: http://rosettacode.org/wiki/Rosetta_Code
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.
Earlier quoted context omitted.
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 ()).
As for speed, please file a performance bug! We love to know where we're missing out on optimizations.
It'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 w…
But when it comes to short-term, one-off, or unimportant tasks, I agree that an emphasis on flexibility is welcome. There's a reason that TIMTOWTDI works so well for Perl in its original role as a shell scripting language.
Earlier quoted context omitted.
That means that all three forms will wind up in any Nim project that gets large enough, though. Hardly a good thing.
If they all work, does it even make a difference? Besides it would be trivial to write a refactoring tool that can autoreplace all instances with the preferred form.
It'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.
I'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.
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.
Using rust-pcre would probably mitigate this problem.