Hacker News new | ask | show | jobs
by iopq 1091 days ago
When Rust was able to get rid of a class of memory bugs, undefined behavior, concurrency bugs without a garbage collector, it achieved a breakthrough. You can now write JS or Java VM in a language that doesn't have buffer overflows, dangling pointers and all kinds of other nasty security vulnerabilities.

Nim doesn't GUARANTEE memory safety, so it's basically... better Pascal? It's an iterative improvement that nobody is getting super excited about. Why is it better than D, V, Delphi?

3 comments

There is more to software engineering than just memory safety.
The question is not whether Nim is better than Rust, the questions are:

Does a C++ developer have reasons to switch to Rust

and

Does a C++ developer have reasons to switch to Nim

Why switch? Is it that weird to know and use more than a language?

In case of adoption, both answers are yes, because Rust and Nim don't occupy the same niche. The reason why Nim has not caught like wildfire is that its niche is often shared with Python or Go, which have a much larger mind share.

Which is why asking this question from the memory safety point of view misses the mark.

It is not. I use 3 languages on a weekly basis for work, and 2 more for hobby stuff.

It's about use cases- frontend, jvm, systems/low-level, realtime/sockets, ML. There could be more overlap, but for reasons they don't.

Sure, but does nim have any breakthrough innovations in any of those other areas?
Do you need breakthrough innovations to adopt a language? Listen, I like Rust and it has its niche for some of my projects, but not all projects should be written in Rust. Least of all because it is an innovative language. That works well as a marketing slogan, not as a factor to decide which language is more apt for the project at hand.

Do I need memory safety? If yes, Rust is the best choice.

But other times I need quick iteration times (Python, or maybe Nim) or immutability, or painless concurrency (Elixir), or meta-programming (Lisp & derivatives). I don't spend any time to ask myself whether a language is innovative, when I got deadlines and results to deliver.

> Do you need breakthrough innovations to adopt a language?

No, but the question wasn't "why has literally nobody on earth adopted nim?" (Which would obviously be false). The question was "why isn't it as popular as rust". There are thousands of languages out there. To be at the top of the pack, nim would have to really stand out somehow. Nim hasn't, so its a little bit niche somewhat mid-popularity language. Which is totally fine, not everything has to rule the world. However that is the reason why it is not ruling the world.

> To be at the top of the pack, nim would have to really stand out somehow. Nim hasn't, so its a little bit niche somewhat mid-popularity language.

I'm not sure about this argument. If Mozilla had created and pushed Nim instead, would it be as popular as what they did for Rust? I'm sure the marketing department would have found some angles to push for Nim. Maybe it would have been memory management options or that its somewhat like a compiled version of Python. I'm sure corporate minds would have figured something out. So if we could see alternate dimensions, where Nim was under Mozilla, it might be nearly as popular.

As it is, some would argue that Rust is somewhat niche, reserved for cases where memory safety without a GC is both necessary and critical. Rust ranks 20th on the TIOBE index. While nothing to sneeze at, nobody knows if it will go higher on the charts or fall back down.

> If Mozilla had created and pushed Nim instead, would it be as popular as what they did for Rust?

In my opinion, definitely not. I knew people excited about and working in Rust back in ~2016 when very few people knew about Rust. They proselytized me, I converted others, et cetera. It's all grassroots spread and has nothing to do with Mozilla marketing.

And that grassroots marketing spread rapidly and easily because of Rust's killer unique features.

Yes, many actually.
Yes, so if we get away from the elevator pitch, Rust provided:

* Cargo for managing dependencies and a sensible module system

* Option/Result based error handling without using null

* Zero (runtime) cost abstractions like iterators and async

Nim does guarantee memory safety if you don't use unsafe features like raw pointers.
Does Nim make you explicitly enter an unsafe mode to access raw pointers?
What that even means? Just random words. unsafe block is just an illusion and doesn't prevent any bugs. Don't get me started on the cult that shames repos that use it.
Sure, but upon review it was found some of the code was using unsafe without reason, and people submitted pull requests which made the code better. It's better because you are sure it doesn't have a memory unsafety bug, even if the code "looked" right before.
Given how Actix was used for benchmarking, I'd imagine that there was a reason the original developer wanted to use unsafe a lot. Nginx was written in pure C, and that is an act of wizardry. I can't imagine wanting to do any work for a language with a 'community' full of people eager to flame or do worse things to developers who don't meet their pompous definition of safety.
No, what's the point of that? It's not hard to recognize unsafe code.
You can't grep for it, but you can grep `unsafe`
`ptr`, `addr` and `cast` are the only ways to introduce unsafety, as I understand it. You have to run three greps, but you can definitely grep.
`grep -w 'pointer|ptr|addr|cast'` would do it in one.. (One can surely do a shell alias called `find-unsafe`..).

Finding unsafe constructs in Nim code is not that hard, at least at the same level of accuracy as `grep unsafe *.rs` (e.g. inside comments & strings, etc.).

To evaluate the power of this general line of argument, consider -- if Nim shipped with a `find-unsafe` source-level search utility, how much would this change your mind?

The advantages of a language that uses words rather than random punctuation.
Rust doesn't guarantee memory safety.

I think anything that can generate a trivial hello world program that doesn't leak memory is better than V.

Besides the attempted slap on V coming from "out of left field", in regards to what the above commenter was talking about, V doesn't leak memory like that. V, since becoming beta (last year), uses an optional GC and does flexible memory management[1]. Giving users choices, somewhat like D and Nim do.

It provides 4 choices: default optional GC (that can be turned off), autofree (either alone or with GC), arena allocation (-prealloc), or manual memory management (-gc none). This flexibility has already been proven, like with their Vinix OS project[2].

Lastly, for developing languages going through alpha and beta phases, think that people should acknowledge how the process works and update their information. Rust or Nim, for example, aren't the same language they were 5 years ago or when still in beta.

[1]: https://github.com/vlang/v/blob/master/doc/docs.md#memory-ma... (4 ways to manage memory in V)

[2]: https://github.com/vlang/vinix

If you don't use `unsafe` then it guarantees it barring compiler mistakes. The compiler has had issues with memory safety before, they were found, and they were fixed. There might be some left lurking, but they are extremely unlikely since people are using it in production and haven't seen anything weird.

If you use `unsafe` you have to make sure of it yourself, but you can easily grep for this keyword and see where the monsters lurk.

The issue is that any Rust code is going to be targeted at performance processing (since otherwise you would write it in a higher level language). And for performance processing, you need to use unsafe (because at some point, the most efficient thing is getting or setting data at a certain memory address without anything extra). Look at any big Rust project, like Amazon Firecracker, and its littered with unsafes.
You really don't, I worked on a Rust project:

https://github.com/ujh/iomrascalai

it doesn't need unsafe code despite being performance-optimized

If you use any language with garbage collection then you won't have memory safety problems (barring unusual corner cases). That is an actual guarantee of memory safety.