Hacker News new | ask | show | jobs
by pcwalton 3804 days ago
- Non-thread-safe GC is unsafe. The way to make it safe is to make it thread-safe. Thread-safe GC does not have negligible performance overhead. (Actually, non-thread-safe GC doesn't either, not by a long shot, but it won't show up in small benchmarks as easily.)

- Just being able to allocate on the stack is not enough. You need to be able to freely make pointers to those stack objects. The ways to do that are to either (a) accept the lack of safety and admit dangling pointers; (b) use an imprecise escape analysis; (c) lifetimes and borrowing. Every choice has costs.

- Safety with runtime checks is not equivalent to what Rust does. Rust provides the safety without runtime checks. That yields better performance than safety with checks.

I'm not intending to spread FUD about Nim specifically. The more interesting question is whether it's possible to have a safe language with the same performance as C/C++ without any cognitive overhead. I strongly believe, after working in this space for over five years, it is not.

That's not to say Nim is a bad language. There are lots of things I like about Nim. It's just that it won't escape the basic tradeoff between cognitive overhead and safety/performance.

1 comments

Nim threads don't share memory. Each has its own GC heap with data exchanged through messages. The lack of thread safety is irrelevant when they can't normally get to each others memory. This of course has performance implications for certain types of parallelism. Nim optimizes for a model where workers don't have to have high speed, high volume inter-communication. If you need shared memory it is up to you to add it along with whatever safety measures you need.
Does Nim now deep copy all messages between threads and start every thread with a fresh environment? If so, it's safe. But it is really problematic for any parallelism. (asm.js tried this and developers felt it was unacceptable.) I think you really can't get away from thread-safe GC in practice.