Can you benchmark this C++ code on your system for comparison?
https://github.com/rjammala/C/blob/master/perf.cpp
I did not add the case sensitiveness option to it.
A Quick Comparison of Nim vs. Rust
71–80 of 94 posts
Re: A Quick Comparison of Nim vs. Rust
#72I 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.
Rust compiles to LLVM, which is a big chunk of C++ code.
Re: A Quick Comparison of Nim vs. Rust
#73It'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
Well thank god a minor inconvenience has been addressed!
Re: A Quick Comparison of Nim vs. Rust
#74I 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.
rust uses LLVM (a C++ library) as a backend; nim uses clang (a compiled C++ executable) as a backend. While there are differences, neither is clearly superior.
Generally, the LLVM route will be faster/more compact when compared to Clang. However, nim can just as easily use gcc, or MSVC, or tcc, which rust cannot. Especially with respect to tcc, this means a stand-alone all-inclusive nim compiler executable can quite easily be constructed and will probably be ~1MB, whereas the comparable standalone rust compiler rustc executable is likely to clock in at 20MB. And you know what? That makes no difference in today's world.
Edit: made it explicit that I am talking about the compiler itself (which was the subject of the parent post I was replying to).
I estimated that the rustc will be 20MB based on my experience with linking LLVM statically in the past - I have not tried it recently, nor have I built rustc. I might be way off. Kibwen says his rust compiler clocks at 8MB - so it appears I am way off (or maybe comparing an unstripped executable to a stripped one)
To be clear to child comment: I did NOT intend to claim that writing something in C will provide a 95% reduction of code size.
Re: A Quick Comparison of Nim vs. Rust
#75Earlier 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 has little benefit and requires new tooling to do simple refactoring like "rename".
> Besides it would be trivial to write a refactoring tool that can autoreplace all instances with the preferred form.
This should be part of the language if it's being so lax with identifier uniqueness. And if it's so trivial, you should write it so people can't complain anymore.
Re: A Quick Comparison of Nim vs. Rust
#76I 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.
rust uses LLVM (a C++ library) as a backend; nim uses clang (a compiled C++ executable) as a backend. While there are differences, neither is clearly superior. Generally, the LLVM route will be faster/more compact when compared to Clang. However, nim can just as easily use gcc, or MSVC, or tcc, which rust cannot. Especially with respect to tcc, this means a stand-alone all-inclusive nim compiler executable can quite…
What would make a standalone Rust executable 20 MB in size? Last time I checked, Rust did not expect to carry libc with it, and can run entirely without a runtime.
Re: A Quick Comparison of Nim vs. Rust
#77Earlier quoted context omitted.
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 has little benefit and requires new tooling to do simple refactoring like "rename". > Besides it would be trivial to write a refactoring tool that can autoreplace all instances with the preferred form. This should be part of the language if it's being so lax with identifier uniqueness. And if it's so trivial, you should write it so people can't complain anymore.
[deleted]
Re: A Quick Comparison of Nim vs. Rust
#78Earlier quoted context omitted.
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 has little benefit and requires new tooling to do simple refactoring like "rename". > Besides it would be trivial to write a refactoring tool that can autoreplace all instances with the preferred form. This should be part of the language if it's being so lax with identifier uniqueness. And if it's so trivial, you should write it so people can't complain anymore.
I don't get why people get so worked up over this. It's not a "little" benefit in my opinion. In regards to drawbacks I can only see one, and that is grepping for the identifiers becomes more difficult.
Re: A Quick Comparison of Nim vs. Rust
#79Nim 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.
The web forum is better than 90% of the forums out there. It is very fast, looks great, has syntax highlighting and a fast search. How could you possibly think that a mailing list is better? What is this, 1981? I hate mailing lists. The github issues is where a lot of serious discussion goes on and if you give github your email and contribute or subscribe you can get spammed with every single issue discussion like me. Anyway I think the highest bandwidth most advanced option is sometimes IRC which of course Nim has too.
Re: A Quick Comparison of Nim vs. Rust
#80Earlier quoted context omitted.
rust uses LLVM (a C++ library) as a backend; nim uses clang (a compiled C++ executable) as a backend. While there are differences, neither is clearly superior. Generally, the LLVM route will be faster/more compact when compared to Clang. However, nim can just as easily use gcc, or MSVC, or tcc, which rust cannot. Especially with respect to tcc, this means a stand-alone all-inclusive nim compiler executable can quite…
What would make a standalone Rust executable 20 MB in size? Last time I checked, Rust did not expect to carry libc with it, and can run entirely without a runtime.
For purposes of comparison, the Rust compiler (which is the most extensive Rust program on my computer at the moment) clocks in at 8MB.
EDIT: Servo, which is the largest Rust program in existence at the moment, is 21MB. Personally I doubt the above claim that writing this in C would reduce the binary size by 95%. I obviously don't have any statically-linked written-in-C web browsers on hand, but if I poke around in Chrome's install directory I see 85MB of DLLs (the entire directory is about 475MB, though surely not all of that is due to binaries).