8 ms·

'Becoming familiar with Rust, is one of the main benefits of learning Rust' The problem is that we seem to believe there is something 'inherent' about the way

'Becoming familiar with Rust, is one of the main benefits of learning Rust' The problem is that we seem to believe there is something 'inherent' about the way Rust solves these problems, and that by doing so with Rust lifetimes, we solve some kind of inherent issue in software. This makes us believe that Rust = Value in some ways which I believe is wrong. Rust is only 'one way' - and it may be far more complicated than it needs to be and in many cases more complicated than it is worth. I feel that Rust may be an experiment, our 'first attempt' at advanced compile time safety, like it's a kind of C++ whereas the Java/C# of memory safety will happen once we've ingested all of these lessons. Funny I feel that with Rust 'There's a much smaller and clearer language struggling to come out' like what Stroustrup said about C++.

hedora 4y ago
Coming from a C++ background makes me think Rust is the smaller and clearer language that came out of C++. The only successful C++ code bases I've worked on were multithreaded, and most were also asynchronous. If you assume those design decisions are required, then you'll find that programmers have to reinvent the borrow checker in their head and manually apply it to code in whatever language they're using. That's incredibly boring and tedious, and people are demonstrably terrible at doing it. Rust automates away all that stuff. I don't know of any approach to threading or I/O that doesn't rely heavily on reasoning about ownership and mutability. In that sense there really is only one way to do it.
- eru 4y ago
  > I don't know of any approach to threading or I/O that doesn't rely heavily on reasoning about ownership and mutability. In that sense there really is only one way to do it. Erlang's message passing style is interesting here. And so is eg Software Transaction Memory that you can try in Haskell. Have a look at deterministic parallelism, too.
  - jcelerier 4y ago
    > Erlang's message passing style is interesting here. it just hides who owns the message data object though, no ? The problem is still here. e.g. for instance I work on a C++ software where there is a lot of message passing across threads, but the OS thread on which "malloc" and "free" are called for the messages and any data they may contain really, really matters - some threads must never call "malloc" or "free" under any circumstance. Would I be able to manage this with Erlang, knowing that every thread should be able to send message to pretty much any other ? Also, looking at that code... https://www.erlang.org/blog/message-passing/ https://www.erlang.org/blog/message-passing/ I don't really see what this gains me over the trivial C++ solution: processing_thread.message_queue.send([=] (Context& ctx) { int x = ... some computation ... ctx.ui_thread.message_queue.send([x] { ... show some info ... }); }); which can become even simpler with coroutines in C++20 if one does not like callback style
    - eru 4y ago
      > it just hides who owns the message data object though, no ? The problem is still here. Erlang messages have a semantic as-if there are copied. (Because that's the only way to do it over a network, and Erlang wants to be agnostic over whether two 'processes' are on the same machine or not.) Erlang doesn't need to worry too much about ownership, because it has a garbage collector. If you want to explicitly control which thread uses malloc/free, then Erlang isn't at the right level of language in this case.
      - mwcampbell 4y ago
        > Erlang messages have a semantic as-if there are copied. (Because that's the only way to do it over a network, and Erlang wants to be agnostic over whether two 'processes' are on the same machine or not.) I think that approach could be called pessimization. The assumption that some components are on the same machine, or better yet the same address space, unlocks some significant optimizations. Sometimes you can be sure that a particular system won't need to scale beyond one machine. And of course, the more efficient the implementation is, the bigger a system can get without having to scale beyond one machine. (Aside: I was reading earlier today about how Uber heavily uses microservices. I wonder if Uber could be a monolith running on one machine given the right architecture and implementation.)
- jollybean 4y ago
  "you'll find that programmers have to reinvent the borrow checker in their head and manually apply it to code in whatever language they're using." There are definitely other ways to do things in concurrent programming, such as isolating data structures to a single thread etc. and other forms of synchronization etc..
verdagon 4y ago
This is actually what we're doing in Vale. [0] Rust is a stellar language, and there's a lot we as a field can learn from it. Its borrow checker is pretty amazing for optimization, but it can be a detriment for a program's overall architecture, not to mention the difficult learning curve, which people tend to underestimate as an issue. I want Rust to grow and succeed in the realms it's uniquely suited for, but I think we can make a general purpose programming language that combines its features in a new way and brings its strengths to the rest of the programming world. For example, we found a way to recreate the borrow checker based on regions [1] on top of a foundation of shared mutability with reference counting (or generational references [2] in Vale's case). Another example is inspired by Rust's RefCell; we found a way to decouple it from Rust's usual aliasability-xor-mutability rules to make it more flexible, in something we call Hybrid-Generational Memory. [3] If we succeed, then we'll have found a way to get the borrow checker's benefits without its complexity. We're a little over halfway done with implementing the region borrow checker [4] and haven't broken ground on HGM yet, but we're well on our way. Hopefully Vale will be the smaller, clearer language that's struggling to come out of Rust! [0] https://vale.dev/ https://vale.dev/ [1] https://verdagon.dev/blog/zero-cost-refs-regions https://verdagon.dev/blog/zero-cost-refs-regions [2] https://verdagon.dev/blog/generational-references https://verdagon.dev/blog/generational-references [3] https://verdagon.dev/blog/hybrid-generational-memory https://verdagon.dev/blog/hybrid-generational-memory [4] https://github.com/ValeLang/Vale/tree/master/Backend/src/region https://github.com/ValeLang/Vale/tree/master/Backend/src/reg...
- jollybean 4y ago
  That is extremely cool, 'region locking' is something I've wondered about myself. Good luck.
  - verdagon 4y ago
    Thanks!
- avgcorrection 4y ago
  Big claims. Are all of these things as zero-cost as the things that Rust uses?
amelius 4y ago
Yes. Rust doesn't even have a good GUI yet, which is telling because it clearly shows that while Rust may be good for some systems stuff, it may not be very good at everything else.
- mwcampbell 4y ago
  I think a more charitable interpretation is that the developers currently working on Rust GUI toolkits are still trying to figure out what a good Rust-native GUI looks like. I'm optimistic that the results will be worth the wait.
  - jollybean 4y ago
    It really doesn't make a whole lot of sense to build a UI in rust. UIs generally change a lot, errors aren't so critical, and there are types of abstractions and complexity that just don't exist at the lower layers. You could so some of the 'core' stuff in rust, but people building UIs would want to use a higher level language. Imagine writing websites in C. Why would you want to do that, even if you could (aside from novelty). It's quite beyond the scope of rust.
- dureuill 4y ago
  I mean another explanation is that GUIs take a tremendous amount of time and investment, especially in today's environment. C++ was out in 1985, and qt's first version wasn't until 1995, with kde starting in 1997. And these were simpler times. I'm very not convinced that lack of GUI is a rust specific problem

hedora 4y ago

Coming from a C++ background makes me think Rust is the smaller and clearer language that came out of C++. The only successful C++ code bases I've worked on were multithreaded, and most were also asynchronous. If you assume those design decisions are required, then you'll find that programmers have to reinvent the borrow checker in their head and manually apply it to code in whatever language they're using. That's incredibly boring and tedious, and people are demonstrably terrible at doing it. Rust automates away all that stuff. I don't know of any approach to threading or I/O that doesn't rely heavily on reasoning about ownership and mutability. In that sense there really is only one way to do it.

eru 4y ago
> I don't know of any approach to threading or I/O that doesn't rely heavily on reasoning about ownership and mutability. In that sense there really is only one way to do it. Erlang's message passing style is interesting here. And so is eg Software Transaction Memory that you can try in Haskell. Have a look at deterministic parallelism, too.
- jcelerier 4y ago
  > Erlang's message passing style is interesting here. it just hides who owns the message data object though, no ? The problem is still here. e.g. for instance I work on a C++ software where there is a lot of message passing across threads, but the OS thread on which "malloc" and "free" are called for the messages and any data they may contain really, really matters - some threads must never call "malloc" or "free" under any circumstance. Would I be able to manage this with Erlang, knowing that every thread should be able to send message to pretty much any other ? Also, looking at that code... https://www.erlang.org/blog/message-passing/ https://www.erlang.org/blog/message-passing/ I don't really see what this gains me over the trivial C++ solution: processing_thread.message_queue.send([=] (Context& ctx) { int x = ... some computation ... ctx.ui_thread.message_queue.send([x] { ... show some info ... }); }); which can become even simpler with coroutines in C++20 if one does not like callback style
  - eru 4y ago
    > it just hides who owns the message data object though, no ? The problem is still here. Erlang messages have a semantic as-if there are copied. (Because that's the only way to do it over a network, and Erlang wants to be agnostic over whether two 'processes' are on the same machine or not.) Erlang doesn't need to worry too much about ownership, because it has a garbage collector. If you want to explicitly control which thread uses malloc/free, then Erlang isn't at the right level of language in this case.
    - mwcampbell 4y ago
      > Erlang messages have a semantic as-if there are copied. (Because that's the only way to do it over a network, and Erlang wants to be agnostic over whether two 'processes' are on the same machine or not.) I think that approach could be called pessimization. The assumption that some components are on the same machine, or better yet the same address space, unlocks some significant optimizations. Sometimes you can be sure that a particular system won't need to scale beyond one machine. And of course, the more efficient the implementation is, the bigger a system can get without having to scale beyond one machine. (Aside: I was reading earlier today about how Uber heavily uses microservices. I wonder if Uber could be a monolith running on one machine given the right architecture and implementation.)
jollybean 4y ago
"you'll find that programmers have to reinvent the borrow checker in their head and manually apply it to code in whatever language they're using." There are definitely other ways to do things in concurrent programming, such as isolating data structures to a single thread etc. and other forms of synchronization etc..

verdagon 4y ago

This is actually what we're doing in Vale. [0] Rust is a stellar language, and there's a lot we as a field can learn from it. Its borrow checker is pretty amazing for optimization, but it can be a detriment for a program's overall architecture, not to mention the difficult learning curve, which people tend to underestimate as an issue. I want Rust to grow and succeed in the realms it's uniquely suited for, but I think we can make a general purpose programming language that combines its features in a new way and brings its strengths to the rest of the programming world. For example, we found a way to recreate the borrow checker based on regions [1] on top of a foundation of shared mutability with reference counting (or generational references [2] in Vale's case). Another example is inspired by Rust's RefCell; we found a way to decouple it from Rust's usual aliasability-xor-mutability rules to make it more flexible, in something we call Hybrid-Generational Memory. [3] If we succeed, then we'll have found a way to get the borrow checker's benefits without its complexity. We're a little over halfway done with implementing the region borrow checker [4] and haven't broken ground on HGM yet, but we're well on our way. Hopefully Vale will be the smaller, clearer language that's struggling to come out of Rust! [0] https://vale.dev/ https://vale.dev/ [1] https://verdagon.dev/blog/zero-cost-refs-regions https://verdagon.dev/blog/zero-cost-refs-regions [2] https://verdagon.dev/blog/generational-references https://verdagon.dev/blog/generational-references [3] https://verdagon.dev/blog/hybrid-generational-memory https://verdagon.dev/blog/hybrid-generational-memory [4] https://github.com/ValeLang/Vale/tree/master/Backend/src/region https://github.com/ValeLang/Vale/tree/master/Backend/src/reg...

jollybean 4y ago
That is extremely cool, 'region locking' is something I've wondered about myself. Good luck.
- verdagon 4y ago
  Thanks!
avgcorrection 4y ago
Big claims. Are all of these things as zero-cost as the things that Rust uses?

amelius 4y ago

Yes. Rust doesn't even have a good GUI yet, which is telling because it clearly shows that while Rust may be good for some systems stuff, it may not be very good at everything else.

mwcampbell 4y ago
I think a more charitable interpretation is that the developers currently working on Rust GUI toolkits are still trying to figure out what a good Rust-native GUI looks like. I'm optimistic that the results will be worth the wait.
- jollybean 4y ago
  It really doesn't make a whole lot of sense to build a UI in rust. UIs generally change a lot, errors aren't so critical, and there are types of abstractions and complexity that just don't exist at the lower layers. You could so some of the 'core' stuff in rust, but people building UIs would want to use a higher level language. Imagine writing websites in C. Why would you want to do that, even if you could (aside from novelty). It's quite beyond the scope of rust.
dureuill 4y ago
I mean another explanation is that GUIs take a tremendous amount of time and investment, especially in today's environment. C++ was out in 1985, and qt's first version wasn't until 1995, with kde starting in 1997. And these were simpler times. I'm very not convinced that lack of GUI is a rust specific problem