I'm not a Nim user. But I have a question.
Many people claim don't use Nim, because Nim miss many libraries. Nim community is small, that could be difficult to develop a big Nim ecosystem libraries with pure Nim.
Rust is safer and faster than Nim, and has a bigger community. So a Rust libraries is better than a Nim library (safer,faster,more actively maintened,..)
Why all Nim libraries don't just wrap Rust libraries if we don't intent to improve any feature? Write a Rust wrapper should be much easier than develop a pure Nim library. Or even better, directly call Rust from Nim
Rust is safer and faster than Nim,
How do you know that it's faster? There are quite a lot of benchmarks where Nim can beat Rust.
So a Rust libraries is better than a Nim library (safer,faster,more actively maintened,..)
Again not true - the language being "safer" doesn't mean that the library is also safer or that the library is faster or more actively maintained. Despites that, why would we need Nim anyway if we were to just use Rust libraries for everything?
Write a Rust wrapper should be much easier than develop a pure Nim library
Writing a Nim wrapper of a C library is even easier, and C "ecosystem" is much bigger than Rust's :)
From the "safer" webpage you linked:
All in all Nim is fairly safe if you stick to the Nim layer, but since it has 1:1 C/C++ interop you can of course expose yourself to all the bugs that can arise from those languages (either by yourself, or through a wrapper).
At my job I have to learn Rust. I was just now reading about cxxbridge and bindgen, two of the (multiple) tools Rust developers have to create bindings for C/C++. This is a common thing to do in Rust, and it inevitably means that one exposes oneself "to all the bugs that can arise from those languages (either by yourself, or through a wrapper)."
On this score, Rust is no safer than Nim. Plus, you have to work with Rust, definitely a negative in my book (so far).
People are allowed to have preferences. I have more fun writing Nim than writing Rust ¯\_(ツ)_/¯.
Now let's address the rest:
Rust is safer
Rust is less safe than Ada Sparks or Formally Verified C. There is a reason why on audit Rustls was recommended to switch to formally verified C primitives for cryptography: https://github.com/rustls/rustls/blob/master/audit/TLS-01-report.pdf
Nim also has a borrow checker via lent and owned ref semantics.
A borrow checker however only catches memory issues and data races. It doesn't catch design bugs or race conditions, you need formal verification for that (like Ada Spark).
Hopefully in the future Nim gets the Z3 theorem prover support (see DrNim) and we can have primitives with mathematical proofs of correctness: https://github.com/nim-lang/RFCs/issues/222
By the way regarding safety, I don't understand the choice of default unsigned integer when those are a recipe for underflow bugs everytime you do a substraction, say for a in 0..(vec.len - 2) {...}
and faster
I'm still waiting for:
Nim is probably the best language to develop domain-specific language and new languages in. It is excellent at rapid development and time to market with it's scripting feel.
Rust doesn't run on all hardware ISA as LLVM doesn't support all ISAs. All ISAs have a C compiler.
Write a Rust wrapper should be much easier than develop a pure Nim library
So it should be easy for you to write an equivalent to my cryptography library?
https://github.com/mratsim/constantine, pro tips you need:
I would also be interested to see a Rust high-performance computing and image manipulation library similar to https://github.com/numforge/laser/tree/master/laser/lux_compiler/core with codegen for parallel CPUs and GPUs and the possibility to setup vectorization (SSE, AVX, Neon), parallelization and other HPC goodies that can generate code at runtime or compile-time.
Pro tip: you need AST manipulation at compile-time, https://github.com/numforge/laser/blob/master/laser/lux_compiler/core/lux_types.nim
I would also be very interesting in a JIT compiler that doesn't do text interpolation for generating opcodes:
Instead in Nim you can do everything in a clean macro, with proper checks of types and arguments: https://github.com/mratsim/photon-jit/blob/747ae2d/photon_jit/x86_64/x86_64_ops.nim
How do you know that it's faster? There are quite a lot of benchmarks where Nim can beat Rust.
I say it base on:
Most benchmark show Rust is faster. As Rust doesn't have GC, it should be also faster in theory. Maybe exists some benchmark where Nim is better than Rust, but I think maybe it is because implementation, algorithm and compilation used by Nim is optimized, and no for Rust. But it is not because the language is faster.
Writing a Nim wrapper of a C library is even easier, and C "ecosystem" is much bigger than Rust's :)
Yes, I ask for Rust because Rust library is more safer.
So, I don't know, if write wrapper is easily in Nim. Why it exist still some pure Nim library with same feature than libraries in C or Rust ecosystem? Why developer don't focus the effort to improve the Nim tooling ecosystem, instead of spend time to develop a existing feature in other ecosystem.
As Rust doesn't have GC, it should be also faster in theory
That's not true. Both Rust and Nim allow for dynamic heap management and both rely on reference counting (RC) for that. The Nim compiler optimizes RC heavily (runtime elision), therefore, many refcount updates can be avoided. I doubt that Rust is on par with that. Optimization of RC has been a major topic in Nim for a very long time.
At my job I have to learn Rust. I was just now reading about cxxbridge and bindgen, two of the (multiple) tools Rust developers have to create bindings for C/C++. This is a common thing to do in Rust, and it inevitably means that one exposes oneself "to all the bugs that can arise from those languages (either by yourself, or through a wrapper)." On this score, Rust is no safer than Nim.
Yes, but Rust have a better memory safety and a safer type system than Nim. A Nim wrapper around Rust should be reliable, I guess.
So Why developer don't focus the effort to improve the Nim tooling ecosystem, instead of spend time to develop a existing feature in Rust ecosystem, a Rust wrapper should solve the problem?
@fzrg - you are overinterpreting benchmarks (which in the Nim versions are written by Nim beginners and/or poorly optimized) and also ignoring caveats and details in the very pages you yourself link to -- all toward the result of coming to inappropriately strong conclusions, repeating yourself, and ignoring rebuttals. While you seem earnest, I don't see how you hope to persuade people here with this trouble.
Rust is not safer as per your own initial comparison link and not safer than formally verified C as per mratsim's rebuttal. Rust is not faster as per Nim can also be "portable assembly" like C & Rust as per this discussion you posted. Here is a small, self-contained example and that thread more broadly discusses problems with at least some Nim code in that kostya benchmark. Most benchmarks are only informative when very cautiously interpreted and most very uncautiously interpreted.
Once you allow near assembly-like non-portable code like SIMD intrinsics, which the benchmarks game started doing long ago, all benchmarks reduce to "exercises in patience of contributing devs". Rust people obviously have a lot of patience given how long they wait for compiles..C++ people as well. Based on that population bias of contributing dev people alone, one might expect "in the broad cultural ensemble" of these benchmark competitions to see more "won" by Rust and C++. This is not indicative of language traits in "more real" problem settings and that goes beyond memory & runtime metrics, whether it is how much unsafe shows up in Rust code or unsafe constructs in Nim or really anything.
This issue is not even unique to measuring computer programs. See Goodhart's Law.
the answer to your question you repeatedly ask is that different people have different tastes in what programming language they would like to write in. This answer should be news to -- exactly no one.
I think you have misunderstand my question. I'm not trying to convince any thing. My question is: Nim have a nice language interoperability. Why some people still spend time to develop a existing feature in C/Rust ecosystem? I don't see usefulness of doing that. Most Nim lib is in early stage, and miss feature, not actively maintened compare to a Rust or C lib. Why people don't just wrap this full feature, actively maintened, industrially used library. Users can benefit a good quality library, developer of lib can save time.
Your continued pressing of the question
I continue ask the same question, because I see most people don't really answer my question: "why don't write just a wrapper". Most answer is about Nim is or not safer and faster than Rust. But it is not my question, it is just one of the assumptions that my question base on.
combined with ignoring all rebuttals
I haven't ignored any thing, I just reply the people who answer me, and express my mind about what he said.
But it is not my question, it is just one of the assumptions that my question base on.
Well the assumptions are wrong and even if we accept them as true, the question isn't all that hard to answer. See my previous replies. And by that let me lock the thread. Feel free to read my replies as often as you need.
A Nim wrapper around Rust should be reliable, I guess.
Have you tried to bind Rust to other languages? It's not fun, and safety is not really guaranteed for non-trivial systems.
Why [Nim] developer don't focus the effort to improve the Nim tooling ecosystem, instead of spend time to develop a existing feature in Rust ecosystem, a Rust wrapper should solve the problem?
I thought @arnetheduck's response was the mic drop; there's no reason Nim can't use Rust (or C, C++, or JS ...) libraries. If the OP wants Nim bindings over Rust, they can write them.
If the question is rather, 'why doesn't someone else do what I want', that has many answers. As a Rust fan (and someone who has been paid to write Rust) let me say that I'd rather see more pure Nim libraries, especially for things Rust is arguably good/better at. I want to see the Nim design pushed hard in many directions, and "low level systems programming" is one of the important directions, scientific computing being another.
This thread is why I use Nim. Because core developers, especially Araq and mratsim, bring state of the art research into the language and these ideas come up in conversations.
Nim might not be a popular language but it's a heck of a learning tool.