3 ms·

It’s interesting to note and probably underappreciated how many of these safety issues are addressed simply by having a garbage collector — eliminating manual m

It’s interesting to note and probably underappreciated how many of these safety issues are addressed simply by having a garbage collector — eliminating manual memory management prevents all of these kinds of bugs except for data races. Of course there are situations where you cannot afford a GC, but for how many programs is avoiding a GC worth all the additional language complexity? Preventing data races is no small thing, but this observation certainly suggests that the approach of GC + tasks & channels + a good race detector is more powerful than it is commonly given credit for — think about how much user-facing language complexity it replaces. This sounds like a pitch for Go, and to some extent it is, but Julia takes very much the same approach for the same reasons.

oleganza 6y ago
The power of a software is in composing things via powerful abstractions. When you write a useful library in a PL with GC, you automatically make it unavailable in all applications that can't use GC. What's worse, other libraries that could've built something around yours have to choose whether to limit their applicability to applications with GC or find another way. But if you have a clever language that navigates this tradeoff and lets you build powerful zero-cost abstractions (C++, Rust, Zig), then it attracts significantly more talent that compounds.
- pjmlp 6y ago
  There are many ways to compose software and libraries, it doesn't need to be static linking all the time. Everyone praises UNIX for pipes in the shell and forgets about OS composition APIs.
- StefanKarpinski 6y ago
  That’s a fair point. Something we’re very interested in is exposing libraries written in Julia without the full runtime, ditching the JIT or the GC if you don’t need them. It would be easy to write a libm replacement in Julia, for example, without using either of those. Regarding talent, it depends on the kind of talent you’re talking about. Yes, systems programmers like Rust. On the other hand, needing to deal with a strict borrow checker excludes a very large number of people with numerical computing, data science and machine learning expertise (not all, but definitely most). So it cuts both ways.
tene 6y ago
One other underappreciated point is how to deal with other resources besides memory. Go has a GC, which helps with memory, but you're entirely on your own for files, sockets, database connections, mutexes, channels, etc. The features that Rust uses for memory management are fully general-purpose, and also help you with safely handling all other kinds of resources. Consider how many ways you can misbehave with a Mutex in Go that are all caught by rustc at compile-time. This has nothing to do with memory management, but the same thing that prevents use-after-free is what also prevents using a mutex-protected value after releasing the lock.

oleganza 6y ago

The power of a software is in composing things via powerful abstractions. When you write a useful library in a PL with GC, you automatically make it unavailable in all applications that can't use GC. What's worse, other libraries that could've built something around yours have to choose whether to limit their applicability to applications with GC or find another way. But if you have a clever language that navigates this tradeoff and lets you build powerful zero-cost abstractions (C++, Rust, Zig), then it attracts significantly more talent that compounds.

pjmlp 6y ago
There are many ways to compose software and libraries, it doesn't need to be static linking all the time. Everyone praises UNIX for pipes in the shell and forgets about OS composition APIs.
StefanKarpinski 6y ago
That’s a fair point. Something we’re very interested in is exposing libraries written in Julia without the full runtime, ditching the JIT or the GC if you don’t need them. It would be easy to write a libm replacement in Julia, for example, without using either of those. Regarding talent, it depends on the kind of talent you’re talking about. Yes, systems programmers like Rust. On the other hand, needing to deal with a strict borrow checker excludes a very large number of people with numerical computing, data science and machine learning expertise (not all, but definitely most). So it cuts both ways.

tene 6y ago

One other underappreciated point is how to deal with other resources besides memory. Go has a GC, which helps with memory, but you're entirely on your own for files, sockets, database connections, mutexes, channels, etc. The features that Rust uses for memory management are fully general-purpose, and also help you with safely handling all other kinds of resources. Consider how many ways you can misbehave with a Mutex in Go that are all caught by rustc at compile-time. This has nothing to do with memory management, but the same thing that prevents use-after-free is what also prevents using a mutex-protected value after releasing the lock.