6 ms·

> What I can't wait for is Pythonic Rust where we have a language that treats humans as first class citiziens but offers the guarantees that Rust does. The inn

> What I can't wait for is Pythonic Rust where we have a language that treats humans as first class citiziens but offers the guarantees that Rust does. The innate complexity of the ownership rules make a Pythonic Rust unlikely, someone must manage the memory so you either put up with that complexity, manually do it with malloc/free, or let the garbage collector do it (in which case it's not Rust anymore). Perhaps you could have a Go-like Rust where everything that escapes the function or breaks ownership is automatically transformed in a reference counted object (which is still a form of garbage collection, but deterministic and compatible with system programming). So that the syntax is simple and programs are easy to compile, but you might get performance bugs when the program does heavy use of the ref count, invalidating cache lines left and right etc.

15155 4y ago
> or let the garbage collector do it (in which case it's not Rust anymore). Arc<T> is still Rust. Not ideal, but very much still Rust. I wouldn't be surprised if despite wrapping absolutely every object in Arc, Rust still were to perform better than most high-level languages at whatever given task.
- tialaramex 4y ago
  Arc isn't a garbage collector though, Arc is just reference counting. You could write this by hand. Languages which have a GC may in some cases also do reference counting to reduce the load on the GC, but they need the GC because reference counting doesn't collect cycles. It's trivial to make a cycle, then destroy all references to it - and in Rust that cycle lives forever, it can't be destroyed because each part of it has references from the rest. With a GC this gets collected, eventually, exactly when will vary which is why in the GC language destructors aren't as useful for resource clean-up as they are in languages like C++ or Rust.
verdagon 4y ago
I think the future is in languages that offer "opt-in" borrow checking, so you can use it where it makes sense. After all, most of a program should prefer simplicity over performance, and only optimize where it matters. I think this is the path towards a more Pythonic Rust. Some languages that are going this direction, including D [0] and Vale [1]. Vale's particular insight is that we can get the benefits of borrow checking with isolates (from Pony) and integrating "pure blocks" and pure functions into the type system, so to speak. > ... breaks ownership is automatically transformed in a reference counted object ... Some languages actually do this! Lobster [2] uses borrow-checker-like semantics and falls back on reference counting. And worth mentioning is HVM [3], which falls back to cloning. [0] https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/ https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in... [1] https://verdagon.dev/blog/zero-cost-memory-safety-regions-part-1-immutable-borrowing https://verdagon.dev/blog/zero-cost-memory-safety-regions-pa... [2] https://www.strlen.com/lobster/ https://www.strlen.com/lobster/ [3] https://github.com/HigherOrderCO/HVM https://github.com/HigherOrderCO/HVM
- cornholio 4y ago
  Thanks for the link, Vale is promising and the "generational references" trick sounds neat. I'm not entirely sure how it impacts developer productivity (i.e. I use a refcount precisely because I don't want to manually manage memory; a cryptic, hard to reproduce runtime crash related to a "generation mismatch" is not much more helpful than a double free, "safety" guarantees that translate to runtime crashes are irrelevant in the real world except where they expose violation of the runtime invariants, such as access past the end of the array; but maybe I don't fully grasp the concept they are proposing). As a general sentiment, I fully agree that improving developer productivity while maintaining safety, speed and ahead of time compilation & static typing are open problems, and all current languages still suck more or less.

15155 4y ago

> or let the garbage collector do it (in which case it's not Rust anymore). Arc<T> is still Rust. Not ideal, but very much still Rust. I wouldn't be surprised if despite wrapping absolutely every object in Arc, Rust still were to perform better than most high-level languages at whatever given task.

tialaramex 4y ago
Arc isn't a garbage collector though, Arc is just reference counting. You could write this by hand. Languages which have a GC may in some cases also do reference counting to reduce the load on the GC, but they need the GC because reference counting doesn't collect cycles. It's trivial to make a cycle, then destroy all references to it - and in Rust that cycle lives forever, it can't be destroyed because each part of it has references from the rest. With a GC this gets collected, eventually, exactly when will vary which is why in the GC language destructors aren't as useful for resource clean-up as they are in languages like C++ or Rust.

verdagon 4y ago

I think the future is in languages that offer "opt-in" borrow checking, so you can use it where it makes sense. After all, most of a program should prefer simplicity over performance, and only optimize where it matters. I think this is the path towards a more Pythonic Rust. Some languages that are going this direction, including D [0] and Vale [1]. Vale's particular insight is that we can get the benefits of borrow checking with isolates (from Pony) and integrating "pure blocks" and pure functions into the type system, so to speak. > ... breaks ownership is automatically transformed in a reference counted object ... Some languages actually do this! Lobster [2] uses borrow-checker-like semantics and falls back on reference counting. And worth mentioning is HVM [3], which falls back to cloning. [0] https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/ https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in... [1] https://verdagon.dev/blog/zero-cost-memory-safety-regions-part-1-immutable-borrowing https://verdagon.dev/blog/zero-cost-memory-safety-regions-pa... [2] https://www.strlen.com/lobster/ https://www.strlen.com/lobster/ [3] https://github.com/HigherOrderCO/HVM https://github.com/HigherOrderCO/HVM

cornholio 4y ago
Thanks for the link, Vale is promising and the "generational references" trick sounds neat. I'm not entirely sure how it impacts developer productivity (i.e. I use a refcount precisely because I don't want to manually manage memory; a cryptic, hard to reproduce runtime crash related to a "generation mismatch" is not much more helpful than a double free, "safety" guarantees that translate to runtime crashes are irrelevant in the real world except where they expose violation of the runtime invariants, such as access past the end of the array; but maybe I don't fully grasp the concept they are proposing). As a general sentiment, I fully agree that improving developer productivity while maintaining safety, speed and ahead of time compilation & static typing are open problems, and all current languages still suck more or less.