6 ms·

I really like Rust, it hits a lot of sweet spots for me – strongly typed, neat type system, the mild functional-ness thats useful while keeping people from goin

I really like Rust, it hits a lot of sweet spots for me – strongly typed, neat type system, the mild functional-ness thats useful while keeping people from going too crazy with functional patterns, usually low on boilerplate, static binaries, clever little things like ? ... but sometimes I wish there was a garbage-collected version of it, the constraints of the borrow checker make things like tree structures at least an order of magnitude harder to get right, and I'd love to have the ergonomics of the language and the ergonomics of a gc-ed runtime. Not going to happen I guess, but I feel like there's an opportunity for a Rust-ish language that is somewhat less finnicky, at the cost of making some abstractions more expensive, for microservices with complex business logic and such.

winrid 5y ago
Sounds like you're looking for Nim!
estebank 5y ago
For what is worth, you can opt-into reference counting and internal mutability with container types (Arc/Rc, Cell/RefCell, RwLock/Mutex), and get the same performance characteristics as a GC language (but without a JIT) for the cost of more complex types in your signatures. Edit: > the constraints of the borrow checker make things like tree structures at least an order of magnitude harder to get right The constraints of the borrow checker make those things more unlikely to compile without extra ceremony. The likelihood of getting them right is orthogonal from making the compiler "happy", even in Rust but specially in other languages. The way I've heard it described is that Rust is a language where you get the hangover first. It upfronts dealing with the error conditions of your problem space in a way that (you can argue) hinders the exploration phase, but that makes of a very quiet maintenance phase.
- sizediterable 5y ago
  People like to bring up reference cycles a lot as if it's always a deal-breaker, but for short-lived processes it kind of seems like a non-issue. Anecdotally, we've seen Instagram get overall gains by disabling GC in Python (which will still do reference counted cleanup).
  - gnulinux 5y ago
    Exactly, I like implementing compilers and I personally never bother with anything other than reference counting nowadays. Ref count gives a very easy to reason semantics. So I count as a feature in my language even if it's slower than GC. Moreover, some of the "memory leak" discussions nowadays miss the biggest issue behind memory leak, which is resource allocation. Some people measure memory leak as the # bytes that process didn't deallocate at the time of exit.
- Const-me 5y ago
  > and get the same performance characteristics as a GC language Pretty sure modern state of the art GCs, like the ones found in Java or .NET runtimes, are way more efficient than reference counting. Reference counters have that unfortunate RAM access pattern where the counter is frequently updated from multiple threads concurrently. On modern processors, this means concurrent access to a cache line by different CPU cores. These cache coherency protocols are pretty slow. On many CPUs, reading a cache line recently modified by another core costs 300-500 clock cycles, even more expensive than a cache miss and roundtrip to system RAM.
  - sizediterable 5y ago
    Python is experimenting with a novel approach where objects have two reference counts, one exclusively for the owning thread and another for all other threads, improving performance when most of the increments/decrements are done by the owning thread. https://lwn.net/Articles/872869/ https://lwn.net/Articles/872869/
  - pjmlp 5y ago
    They are, specially when ARC marketing from Apple gets validated. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages
sizediterable 5y ago
A Rust team alum has actually written a bit about the topic: https://without.boats/blog/notes-on-a-smaller-rust https://without.boats/blog/notes-on-a-smaller-rust https://without.boats/blog/revisiting-a-smaller-rust https://without.boats/blog/revisiting-a-smaller-rust
pcwalton 5y ago
I actually support the idea of adopting Rust's ideas in a memory-safe, garbage collected language. I like garbage collection—it's not always the right tool, but it's a great tool in the proper domains. Modern GC builds upon decades of research to achieve memory safety at runtime with good performance and very low cognitive overhead on the part of the programmer. What I don't agree with is the idea of taking Rust's ideas and putting them into manually-memory-managed, unsafe languages. We should be moving away from such languages as an industry.
- cultofmetatron 5y ago
  > I actually support the idea of adopting Rust's ideas in a memory-safe, garbage collected language. sooo... ocaml?
  - johnisgood 5y ago
    Or many other programming languages, but yes, OCaml is a pretty good one, and it is perfectly suitable for systems programming.
- skohan 5y ago
  > I actually support the idea of adopting Rust's ideas in a memory-safe, garbage collected language You're describing Swift
  - saghm 5y ago
    Swift also has some stuff coming from the history of Objective-C interop (inheritance is the big one I'm thinking of, although I'm sure there are others that are slipping my mind). I'm not sure how mainstream this opinion is, but personally I _prefer_ not having classes and inheritance, and while I could always choose not to use them in my own code, I imagine it's common enough in libraries that I'd end up dealing with it a bit anyways. Combined with the fact that Linux support still seems like it's a bit secondary makes me feel like there still is a potential niche out there for "Rust with garbage collecting" that Swift might not be filling entirely.
skohan 5y ago
You're describing Swift
- duped 5y ago
  It's a shame Swift isn't as usable outside Apple platforms
  - skohan 5y ago
    Totally agree - it's a nice language and I would love to be able to use it everywhere
m0zg 5y ago
>> Not going to happen I sure hope not. Borrow checker has little to do with memory allocation/deallocation. It's there so that you can't have unprotected mutable shared state.
pjmlp 5y ago
They already exist, OCaml, Haskell, F#, Scala, Swift.
musicmatze 5y ago
The constraints of the borrow checker do not make tree structures harder to get right! They just force you to get it right!
davidkunz 5y ago
I don't think Rust is low on boilerplate. As an example, here is a video of David Pedersen creating a simple Tower service: https://www.youtube.com/watch?v=16sU1q8OeeI&t=945s https://www.youtube.com/watch?v=16sU1q8OeeI&t=945s I found it intimidating how much you have to write to create a simple middleware.
- timw4mail 5y ago
  There's some amount of boilerplate that is unavoidable, but, if you have the patience, `macro_rules!` type macros can help cut down on syntactical boilerplate in many cases. Compared to C, and sometimes C++, there's generally less boilerplate in Rust. Compared to more traditional web languages, though, Rust will seem to have more boilerplate due to it's lower-level design.
sharno 5y ago
Totally agree, really wish for a language that has all rust features + GC. OCaml and F# come close enough but they are not as popular.

winrid 5y ago

Sounds like you're looking for Nim!

estebank 5y ago

For what is worth, you can opt-into reference counting and internal mutability with container types (Arc/Rc, Cell/RefCell, RwLock/Mutex), and get the same performance characteristics as a GC language (but without a JIT) for the cost of more complex types in your signatures. Edit: > the constraints of the borrow checker make things like tree structures at least an order of magnitude harder to get right The constraints of the borrow checker make those things more unlikely to compile without extra ceremony. The likelihood of getting them right is orthogonal from making the compiler "happy", even in Rust but specially in other languages. The way I've heard it described is that Rust is a language where you get the hangover first. It upfronts dealing with the error conditions of your problem space in a way that (you can argue) hinders the exploration phase, but that makes of a very quiet maintenance phase.

sizediterable 5y ago
People like to bring up reference cycles a lot as if it's always a deal-breaker, but for short-lived processes it kind of seems like a non-issue. Anecdotally, we've seen Instagram get overall gains by disabling GC in Python (which will still do reference counted cleanup).
- gnulinux 5y ago
  Exactly, I like implementing compilers and I personally never bother with anything other than reference counting nowadays. Ref count gives a very easy to reason semantics. So I count as a feature in my language even if it's slower than GC. Moreover, some of the "memory leak" discussions nowadays miss the biggest issue behind memory leak, which is resource allocation. Some people measure memory leak as the # bytes that process didn't deallocate at the time of exit.
Const-me 5y ago
> and get the same performance characteristics as a GC language Pretty sure modern state of the art GCs, like the ones found in Java or .NET runtimes, are way more efficient than reference counting. Reference counters have that unfortunate RAM access pattern where the counter is frequently updated from multiple threads concurrently. On modern processors, this means concurrent access to a cache line by different CPU cores. These cache coherency protocols are pretty slow. On many CPUs, reading a cache line recently modified by another core costs 300-500 clock cycles, even more expensive than a cache miss and roundtrip to system RAM.
- sizediterable 5y ago
  Python is experimenting with a novel approach where objects have two reference counts, one exclusively for the owning thread and another for all other threads, improving performance when most of the increments/decrements are done by the owning thread. https://lwn.net/Articles/872869/ https://lwn.net/Articles/872869/
- pjmlp 5y ago
  They are, specially when ARC marketing from Apple gets validated. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages

sizediterable 5y ago

A Rust team alum has actually written a bit about the topic: https://without.boats/blog/notes-on-a-smaller-rust https://without.boats/blog/notes-on-a-smaller-rust https://without.boats/blog/revisiting-a-smaller-rust https://without.boats/blog/revisiting-a-smaller-rust

pcwalton 5y ago

I actually support the idea of adopting Rust's ideas in a memory-safe, garbage collected language. I like garbage collection—it's not always the right tool, but it's a great tool in the proper domains. Modern GC builds upon decades of research to achieve memory safety at runtime with good performance and very low cognitive overhead on the part of the programmer. What I don't agree with is the idea of taking Rust's ideas and putting them into manually-memory-managed, unsafe languages. We should be moving away from such languages as an industry.

cultofmetatron 5y ago
> I actually support the idea of adopting Rust's ideas in a memory-safe, garbage collected language. sooo... ocaml?
- johnisgood 5y ago
  Or many other programming languages, but yes, OCaml is a pretty good one, and it is perfectly suitable for systems programming.
skohan 5y ago
> I actually support the idea of adopting Rust's ideas in a memory-safe, garbage collected language You're describing Swift
- saghm 5y ago
  Swift also has some stuff coming from the history of Objective-C interop (inheritance is the big one I'm thinking of, although I'm sure there are others that are slipping my mind). I'm not sure how mainstream this opinion is, but personally I _prefer_ not having classes and inheritance, and while I could always choose not to use them in my own code, I imagine it's common enough in libraries that I'd end up dealing with it a bit anyways. Combined with the fact that Linux support still seems like it's a bit secondary makes me feel like there still is a potential niche out there for "Rust with garbage collecting" that Swift might not be filling entirely.

skohan 5y ago

You're describing Swift

duped 5y ago
It's a shame Swift isn't as usable outside Apple platforms
- skohan 5y ago
  Totally agree - it's a nice language and I would love to be able to use it everywhere

m0zg 5y ago

>> Not going to happen I sure hope not. Borrow checker has little to do with memory allocation/deallocation. It's there so that you can't have unprotected mutable shared state.

pjmlp 5y ago

They already exist, OCaml, Haskell, F#, Scala, Swift.

musicmatze 5y ago

The constraints of the borrow checker do not make tree structures harder to get right! They just force you to get it right!

davidkunz 5y ago

I don't think Rust is low on boilerplate. As an example, here is a video of David Pedersen creating a simple Tower service: https://www.youtube.com/watch?v=16sU1q8OeeI&t=945s https://www.youtube.com/watch?v=16sU1q8OeeI&t=945s I found it intimidating how much you have to write to create a simple middleware.

timw4mail 5y ago
There's some amount of boilerplate that is unavoidable, but, if you have the patience, `macro_rules!` type macros can help cut down on syntactical boilerplate in many cases. Compared to C, and sometimes C++, there's generally less boilerplate in Rust. Compared to more traditional web languages, though, Rust will seem to have more boilerplate due to it's lower-level design.

sharno 5y ago

Totally agree, really wish for a language that has all rust features + GC. OCaml and F# come close enough but they are not as popular.