3 ms·

There has to be a simpler solution than Rust though. Rust seems to have started with some clear objectives but evolved into a nightmare. We should be putting t

by m0xte 6y ago

There has to be a simpler solution than Rust though. Rust seems to have started with some clear objectives but evolved into a nightmare. We should be putting the effort into the compilers and keeping the language free of cruft and any unsafe concerns. Much like Delphi did for example.

rwmj 6y ago
For most, average userspace programs garbage collectors work very well. (Of course there are exceptional cases as I'm sure people will be quick to point out.) However if you deny garbage collection for all programs you have to replace it with something very complex to reason about, like RAII for C++ or borrow checking in Rust. Or you end up reimplementing GC inefficiently (C++ reference counting). Also certain algorithms -- persistent data structures with shared subgraphs and therefore cheap updates -- become very difficult to write because there's no local ownership of nodes, only something with a global program view (a GC) knows when an object is unreferenced and can be freed.
- foldr 6y ago
  This. The Rust community seem to be pushing Rust as a more-or-less general purpose programming language. But giving up garbage collection never makes sense unless you have to. The applications where you really can't use GC are a tiny niche relative to the ones where you can.
  - StreamBright 6y ago
    >> The applications where you really can't use GC are a tiny niche relative to the ones where you can. And this is one space Rust is targeting explicitly. Why would people replace Go with Rust for performance reasons otherwise? https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f https://blog.discord.com/why-discord-is-switching-from-go-to...
- tomp 6y ago
  It's funny that one of the key selling points of Rust is "fearless concurrency", but IMO if you want "real" concurrency - i.e. not just "split work between threads" which is what Rust can do easily, but different threads doing the same work concurrently (e.g. accessing the same data structures, sending messages, etc.) you need lock-free data structures, and for those you need GC (or something different, e.g. epoch-based reclamation - but from what I've read (no practical experience though), it's just as tricky to implement and performs worse than good GCs). I think the future is combined GC (for concurrency & unpredictable lifetime patterns) / reference counting (for resources - files, sockets, large primitive arrays) / safe manual (e.g. memory pools). I just need to figure out all the details :D
  - zozbot234 6y ago
    The crossbeam crate implements epoch-based GC for concurrency in Rust. It's widely used and seems to work fairly well.
- StreamBright 6y ago
  Especially, if you have do limited scope GC like Erlang, and let the programmers pick when GC is happening. Sort of like malloc/free but without the fear of introducing bugs like double free.
blackrock 6y ago
Sometimes when I look at the strange constructs of Rust, and all the hoops that you must jump through to do certain things, I end up yearning for C++. Or even plain old C. And I tell myself, that I’ll be more careful with memory handling.
- kumarvvr 6y ago
  Exactly, C seems saner in my view, and in its own way, elegant too.
- nicoburns 6y ago
  I have the opposite: when I see C or C++, I'm terrified of touching it for fear of messing up the memory handling. Rust allows me relax.
zozbot234 6y ago
I'm not really seeing the whole "nightmare" part of Rust. If the borrow checker ever becomes an issue (and it really shouldn't be one in most cases, if you're familiar with the semantics) you can easily opt into increased flexibility. It just takes a little more boilerplate than in other languages.
petre 6y ago
There is. It's called Dlang or D.

by m0xte 6y ago

rwmj 6y ago

For most, average userspace programs garbage collectors work very well. (Of course there are exceptional cases as I'm sure people will be quick to point out.) However if you deny garbage collection for all programs you have to replace it with something very complex to reason about, like RAII for C++ or borrow checking in Rust. Or you end up reimplementing GC inefficiently (C++ reference counting). Also certain algorithms -- persistent data structures with shared subgraphs and therefore cheap updates -- become very difficult to write because there's no local ownership of nodes, only something with a global program view (a GC) knows when an object is unreferenced and can be freed.

foldr 6y ago
This. The Rust community seem to be pushing Rust as a more-or-less general purpose programming language. But giving up garbage collection never makes sense unless you have to. The applications where you really can't use GC are a tiny niche relative to the ones where you can.
- StreamBright 6y ago
  >> The applications where you really can't use GC are a tiny niche relative to the ones where you can. And this is one space Rust is targeting explicitly. Why would people replace Go with Rust for performance reasons otherwise? https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f https://blog.discord.com/why-discord-is-switching-from-go-to...
tomp 6y ago
It's funny that one of the key selling points of Rust is "fearless concurrency", but IMO if you want "real" concurrency - i.e. not just "split work between threads" which is what Rust can do easily, but different threads doing the same work concurrently (e.g. accessing the same data structures, sending messages, etc.) you need lock-free data structures, and for those you need GC (or something different, e.g. epoch-based reclamation - but from what I've read (no practical experience though), it's just as tricky to implement and performs worse than good GCs). I think the future is combined GC (for concurrency & unpredictable lifetime patterns) / reference counting (for resources - files, sockets, large primitive arrays) / safe manual (e.g. memory pools). I just need to figure out all the details :D
- zozbot234 6y ago
  The crossbeam crate implements epoch-based GC for concurrency in Rust. It's widely used and seems to work fairly well.
StreamBright 6y ago
Especially, if you have do limited scope GC like Erlang, and let the programmers pick when GC is happening. Sort of like malloc/free but without the fear of introducing bugs like double free.

blackrock 6y ago

Sometimes when I look at the strange constructs of Rust, and all the hoops that you must jump through to do certain things, I end up yearning for C++. Or even plain old C. And I tell myself, that I’ll be more careful with memory handling.

kumarvvr 6y ago
Exactly, C seems saner in my view, and in its own way, elegant too.
nicoburns 6y ago
I have the opposite: when I see C or C++, I'm terrified of touching it for fear of messing up the memory handling. Rust allows me relax.

zozbot234 6y ago

I'm not really seeing the whole "nightmare" part of Rust. If the borrow checker ever becomes an issue (and it really shouldn't be one in most cases, if you're familiar with the semantics) you can easily opt into increased flexibility. It just takes a little more boilerplate than in other languages.

petre 6y ago

There is. It's called Dlang or D.