Comment by codewithcheese | Hacker News Reader

Comment by codewithcheese | Hacker News Reader

Parent Full thread

> No, Nim doesn't have stronger or weaker safety guarantees than Rust [1]. Rust's memory safety is nothing new, either. It is mostly that some older languages like C/C++ are the exceptions in not being memory-safe. There is nothing new or magical about memory safety. LISP was already memory-safe when it was invented in 1958. The only question is how much performance you need to trade away for it (the value is never zero for non-trivial programs, but can vary greatly, depending on whether the language was designed with it in mind or not).

> The main difference between Rust and other languages is that it does some more (but not all [2]) safety checks at compile time rather than at runtime. It also allows you to avoid GC, but does not provide you any memory safety over GC. Rust's borrow checker allows you to statically prove that references are live [3]; a GC simply avoids deallocating any memory that has a live reference to it (on the other hand, a GC can ensure that references remain live even where this is hard or impossible to prove statically). The end result is the same with respect to memory safety (the reason some people want to avoid GC is for performance reasons, not memory safety).

https://forum.nim-lang.org/t/1961

While it's true that memory safety has been done in a lot of languages for a long time this overstates the point. Doing memory safety at compile time is an important change that allows replacing C/C++ in a lot more situations. In the benchmarks game for example Rust has been the only language capable of breaking into the C/C++ league, even after very many years of investment into Java for example.

Rust also uses the same mechanisms to get compile time thread safety with full memory sharing between threads. Does any other language that doesn't have a global lock, throwing away most of the advantage, have that? There are actual new and interesting advantages to the compile time ownership model.

> Rust also uses the same mechanisms to get compile time thread safety with full memory sharing between threads.

A minor advantage on the age of microservices and OS IPC to shared external resources.

Sendable doesn't apply when those threads are accessing shared external resources.

Benchmarks vary wildly but Haskell tends to perform in the same realm as C++, fwiw. It's GC'd, uses immutable data structures, and uses a green threading model that can be easily exploited by user code for extreme levels of parallelism with full memory safety. It's even possible to hold mutable references and share them across threads safely with STM (not a global lock).

If you want fully lock-free it might be possible to prove that with extensions like Liquid Haskell, via Linear types, and is definitely easier to prove with a theorem prover than it is, generally, for C++ code. Not sure about Rust though I realize quite a lot of its moving parts have already been formalized which is super cool.

There are reasons for using Rust but it's not the only game in town. And GC doesn't automatically mean pessimistic performance.

That's outdated information from 2016. Now Nim uses ARC/ORC. ARC implements memory management at compile time like Rust and it's still very fast at compiling.

Cool, I wasn't aware, thanks. https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...

> The main difference between ARC and Nim GCs is that ARC is fully deterministic - the compiler automatically injects destructors when it deems that some variable (a string, sequence, reference, or something else) is no longer needed. In this sense, it’s similar to C++ with its destructors (RAII). To illustrate, we can use Nim’s expandArc introspection (will be available in Nim 1.4).

> This shows one of the main ARC features: scope-based memory management. A scope is a separate region of code in the program. Scope-based MM means that the compiler will automatically insert destructor calls for any variables which need a destructor after the scope ends. Many Nim constructs introduce new scopes: procs, funcs, converters, methods, block statements and expressions, for and while loops, etc.

> ARC also has so-called hooks - special procedures that can be defined for types to override the default compiler behaviour when destroying/moving/copying the variable. These are particularly useful when you want to make custom semantics for your types, deal with low-level operations involving pointers, or do FFI.

Really. I did not know that. so, can I use today Nim but with a Rust-like ARC?

--gc:arc/--mm:arc has been around for a couple years (as per that blog post link) and fairly stable for >1 year. It is slated to become the default automatic memory management strategy in Nim-2.0. The hope is to release 2.0 this year.

You can always make it your own personal default with older versions (e.g. nim-1.6), by editing your $HOME/.config/nim/nim.cfg to say so or doing similar on per project/file basis.

Rust doesn't have ARC like Nim or Swift. (And Nim and Swift's are a bit different here but closer to each other than anything that exists in Rust.)

Anything you can statically prove at compile time is interest you don't have to pay at run time.

Rust is a huge, huge win for that reason. It allows for code written in a Lisp/OCaml/Nim style that's memory safe without any additional overhead.

Reply on news.ycombinator.com