5 ms·

Here's the post that the video is about https://www.reddit.com/r/rust/comments/12b7p2p/the_rust_programming_language_absolutely/ https://www.reddit.com/r/rust/

by bena 3y ago

Here's the post that the video is about https://www.reddit.com/r/rust/comments/12b7p2p/the_rust_programming_language_absolutely/ https://www.reddit.com/r/rust/comments/12b7p2p/the_rust_prog...

msh 3y ago
I dont know rust but the following comment from the reddit thread resonates with me: So you started learning rust by trying to make something multithreaded that also interops with C instead of starting with something simpler so you can learn to understand the borrow checker? That's a recipe for disaster.
- mikece 3y ago
  The choice of language was forced on the dev. He did a Java version of the app -- ON HIS OWN TIME -- and management nixed it.
  - imtringued 3y ago
    That doesn't excuse his choice of words. >am truly convinced that all the people who claim Rust is great are either lying to themselves or others A Rust novice telling every Rust developer in the world being wrong? There must be some irrefutable wisdom in there somewhere!
  - rob74 3y ago
    Yeah - there's a huge psychological difference between adopting a language out of your own free will and it being forced upon you. I suspect that's where a lot of the current hyperbole about Rust comes from...
- gizmo 3y ago
  The issue here is that Rust presents itself as a systems language, i.e. a language where the programmer has control over how the system's resources get used. However, Rust has safety mechanisms that will stop you from doing what you want, even when what you want to do is safe and sensible. There is a contradiction here that Rust enthusiasts endlessly make excuses for. Rust is more like Go than C. Both Rust and Go can be used to write high performance services. Both Rust and Go have many modern convenience features. And both languages expect you to write code in a specific idiomatic way, wrt borrow checking and go channels respectively. If you need shared memory and fine-grained locking for performance you're not going to have a good time. And that makes Go and Rust unsuitable for a large chunk of applications.
  - cmrdporcupine 3y ago
    This is simply false. Having written code like what you're talking about... There is always an escape-hatch. Rust just wants to make sure you really know what you're doing before letting you go there. The idea being to provide safety-minded well crafted but performant libraries where the hard thinking about atomics & locking and unsafe-bounded memory shenanigans are confined in well-tested locales. Also don't see why you're comparing with Go. Entirely different bowl of soup. Go is not a systems programming language.
  - goku12 3y ago
    Rust is used for writing entire OS (e.g Redox) or parts of the OS that needs precise management of resources (e.g Linux kernel, Windows). It is used to write parts of web browsers (servo and quantum parts of firefox), game engines and in embedded systems. It's used everywhere that traditionally used C, C++ or Ada. There really isn't a justification to dismiss Rust as a systems programming language. The limitations that you claim are not there. The reasons are there in the other reply to you.
  - mike_hearn 3y ago
    There is unsafe{} if you want to do something not normally allowed. But, well, it's unsafe. I was surprised to learn of a memory management vulnerability in a Rust serialization library the other day (for capn'proto). It was using unsafe. You'd think that serialization is the sort of library where Rust's guarantees are most valuable.
titzer 3y ago
Thanks for posting the link. The video is useless, it's just rage-baiting. Stepping back from the emotional overreaction in the OP, this seems to be the relevant bit: > Right off the bat, as a total Rust newbie, I'm hitting all kinds of rough edges in Rust. For example, I'm trying to use rusqlite. It would be natural to stash DB prepared statements in a thread local for reuse in my multi-threaded code. I can't pass the connections around, because I need them in a C call-back (too much detail here I know) so I have to be able to look them up. Alas, after banging my head against the wall for a full day, I'm just giving up on the thread-local approach, because I simply can't get it to work. Part of the problem is that I can't stash a prepared statement in the same (thread local) struct as the connection from which they are created, due to lifetime limitations. It also seems that you can't really use two thread locals (one for the connection and one for the prepared statements) either. If there's a way to do it, I can't figure it out. What I take from this is that the library was designed to work with lifetimes a specific way, and the OP is trying to use them in a way not intended. Rust lifetimes being baked into the language means there is really no way around the design the library authors had in mind. If the library authors made bad choices, you are basically stuck. This is the crux of the matter. A poorly designed library in Rust comes with a straightjacket that you must wear. I've had students hit this kind of things several times. This kind of experience absolutely kills the flow and sucks all the joy out of programming. Poorly-designed lifetimes are non-composable and lead programmers down completely unnecessary, totally unproductive rabbit holes. Making memory management orthogonal APIs is the only way to make them composable.
- cmrdporcupine 3y ago
  I actually ran into these precise problems with rusqlite and found them equally frustrating, and ended up ripping that code out in the end. The lifetimes model in that library are, IMHO, "wrong".
- mike_hearn 3y ago
  It seems almost worse - the author of rusqlite replies and says, essentially, that you just cannot do what he wants to do at all, and the "fix" is to either constantly re-prepare statements, or rely on some sort of library built-in cache! The first will lower performance perhaps by a lot, but performance is probably why you're writing Rust in the first place. The second is a nasty hack that will require you to remember this cache exists and keep its size carefully tuned. As all he wants to do is stash prepared statements in TLS, a pretty normal task, it seems like a valid complaint that this is so hard and rustql doesn't seem to allow it. One aspect of Rust I wonder about it is that when reading it I see way more cloning than you'd intuitively expect. Seems like people hit the borrow checker, can't see a way out and just copy the memory to escape. Presumably that will lead to diffuse performance losses all over the app of the sort that can't easily be spotted in a profiler, sort of like pointer chasing in languages without value types. I wonder if C++ will actually end up having an edge in performance due to this. I know there are very heavily tuned benchmarks that show Rust being the fastest but I mean for "real" code of the sort this person is needing to write (done under time pressure).
Verdex 3y ago
Thanks for the link. I saw the youtube video advertised to me by the algorithm, but wasn't about to waste my time watching it. After decades of trying to get C-style systems programming right, we're still finding unsafe memory related security issues (ignoring implicit integer casts and UB). Thesis: Maybe c-style systems programming is bad. Rust consumes what we learned from cyclone et al as well as leveraging llvm and while I think we had reason to be cautiously optimistic for a while there, now it honestly seems to be working. But it works because we abandoned what we thought were the bad parts of c-style systems programming. Meanwhile, someone tries to shove c-style programming back into rust and finds it's not actually possible. Then complains. Technically, this is fine. The part that isn't fine is to loudly proclaim that everyone who is able to learn how to use rust correctly must be lairs. [As an aside, there's D, P, jai, rust, odin, zig, carbon, vale, swift, c++11+, and more. A good rule of thumb is that a programming language takes about a decade to really get moving. There's a reason that an absurd amount of time has been dumped into replacing c-style systems programming.]
- c_crank 3y ago
  Bug free code only exists when it can be formally verified.
  - Verdex 3y ago
    | Bug free code only exists when it can be formally verified. ... okay. Although, on the other hand: | Beware of bugs in the above code; I have only proved it correct, not tried it - Knuth Perhaps bug free code does not exist?
    - c_crank 3y ago
      The replacement languages for C in systems programming aren't memory safe. They can cause segfaults. They have additional tools and syntax rules to make it less likely, but they can and will have memory bugs.
      - Verdex 3y ago

by bena 3y ago

Here's the post that the video is about https://www.reddit.com/r/rust/comments/12b7p2p/the_rust_programming_language_absolutely/ https://www.reddit.com/r/rust/comments/12b7p2p/the_rust_prog...

msh 3y ago

I dont know rust but the following comment from the reddit thread resonates with me: So you started learning rust by trying to make something multithreaded that also interops with C instead of starting with something simpler so you can learn to understand the borrow checker? That's a recipe for disaster.

mikece 3y ago
The choice of language was forced on the dev. He did a Java version of the app -- ON HIS OWN TIME -- and management nixed it.
- imtringued 3y ago
  That doesn't excuse his choice of words. >am truly convinced that all the people who claim Rust is great are either lying to themselves or others A Rust novice telling every Rust developer in the world being wrong? There must be some irrefutable wisdom in there somewhere!
- rob74 3y ago
  Yeah - there's a huge psychological difference between adopting a language out of your own free will and it being forced upon you. I suspect that's where a lot of the current hyperbole about Rust comes from...
gizmo 3y ago
The issue here is that Rust presents itself as a systems language, i.e. a language where the programmer has control over how the system's resources get used. However, Rust has safety mechanisms that will stop you from doing what you want, even when what you want to do is safe and sensible. There is a contradiction here that Rust enthusiasts endlessly make excuses for. Rust is more like Go than C. Both Rust and Go can be used to write high performance services. Both Rust and Go have many modern convenience features. And both languages expect you to write code in a specific idiomatic way, wrt borrow checking and go channels respectively. If you need shared memory and fine-grained locking for performance you're not going to have a good time. And that makes Go and Rust unsuitable for a large chunk of applications.
- cmrdporcupine 3y ago
  This is simply false. Having written code like what you're talking about... There is always an escape-hatch. Rust just wants to make sure you really know what you're doing before letting you go there. The idea being to provide safety-minded well crafted but performant libraries where the hard thinking about atomics & locking and unsafe-bounded memory shenanigans are confined in well-tested locales. Also don't see why you're comparing with Go. Entirely different bowl of soup. Go is not a systems programming language.
- goku12 3y ago
  Rust is used for writing entire OS (e.g Redox) or parts of the OS that needs precise management of resources (e.g Linux kernel, Windows). It is used to write parts of web browsers (servo and quantum parts of firefox), game engines and in embedded systems. It's used everywhere that traditionally used C, C++ or Ada. There really isn't a justification to dismiss Rust as a systems programming language. The limitations that you claim are not there. The reasons are there in the other reply to you.
- mike_hearn 3y ago
  There is unsafe{} if you want to do something not normally allowed. But, well, it's unsafe. I was surprised to learn of a memory management vulnerability in a Rust serialization library the other day (for capn'proto). It was using unsafe. You'd think that serialization is the sort of library where Rust's guarantees are most valuable.

titzer 3y ago

Thanks for posting the link. The video is useless, it's just rage-baiting. Stepping back from the emotional overreaction in the OP, this seems to be the relevant bit: > Right off the bat, as a total Rust newbie, I'm hitting all kinds of rough edges in Rust. For example, I'm trying to use rusqlite. It would be natural to stash DB prepared statements in a thread local for reuse in my multi-threaded code. I can't pass the connections around, because I need them in a C call-back (too much detail here I know) so I have to be able to look them up. Alas, after banging my head against the wall for a full day, I'm just giving up on the thread-local approach, because I simply can't get it to work. Part of the problem is that I can't stash a prepared statement in the same (thread local) struct as the connection from which they are created, due to lifetime limitations. It also seems that you can't really use two thread locals (one for the connection and one for the prepared statements) either. If there's a way to do it, I can't figure it out. What I take from this is that the library was designed to work with lifetimes a specific way, and the OP is trying to use them in a way not intended. Rust lifetimes being baked into the language means there is really no way around the design the library authors had in mind. If the library authors made bad choices, you are basically stuck. This is the crux of the matter. A poorly designed library in Rust comes with a straightjacket that you must wear. I've had students hit this kind of things several times. This kind of experience absolutely kills the flow and sucks all the joy out of programming. Poorly-designed lifetimes are non-composable and lead programmers down completely unnecessary, totally unproductive rabbit holes. Making memory management orthogonal APIs is the only way to make them composable.

cmrdporcupine 3y ago
I actually ran into these precise problems with rusqlite and found them equally frustrating, and ended up ripping that code out in the end. The lifetimes model in that library are, IMHO, "wrong".
mike_hearn 3y ago
It seems almost worse - the author of rusqlite replies and says, essentially, that you just cannot do what he wants to do at all, and the "fix" is to either constantly re-prepare statements, or rely on some sort of library built-in cache! The first will lower performance perhaps by a lot, but performance is probably why you're writing Rust in the first place. The second is a nasty hack that will require you to remember this cache exists and keep its size carefully tuned. As all he wants to do is stash prepared statements in TLS, a pretty normal task, it seems like a valid complaint that this is so hard and rustql doesn't seem to allow it. One aspect of Rust I wonder about it is that when reading it I see way more cloning than you'd intuitively expect. Seems like people hit the borrow checker, can't see a way out and just copy the memory to escape. Presumably that will lead to diffuse performance losses all over the app of the sort that can't easily be spotted in a profiler, sort of like pointer chasing in languages without value types. I wonder if C++ will actually end up having an edge in performance due to this. I know there are very heavily tuned benchmarks that show Rust being the fastest but I mean for "real" code of the sort this person is needing to write (done under time pressure).

Verdex 3y ago

Thanks for the link. I saw the youtube video advertised to me by the algorithm, but wasn't about to waste my time watching it. After decades of trying to get C-style systems programming right, we're still finding unsafe memory related security issues (ignoring implicit integer casts and UB). Thesis: Maybe c-style systems programming is bad. Rust consumes what we learned from cyclone et al as well as leveraging llvm and while I think we had reason to be cautiously optimistic for a while there, now it honestly seems to be working. But it works because we abandoned what we thought were the bad parts of c-style systems programming. Meanwhile, someone tries to shove c-style programming back into rust and finds it's not actually possible. Then complains. Technically, this is fine. The part that isn't fine is to loudly proclaim that everyone who is able to learn how to use rust correctly must be lairs. [As an aside, there's D, P, jai, rust, odin, zig, carbon, vale, swift, c++11+, and more. A good rule of thumb is that a programming language takes about a decade to really get moving. There's a reason that an absurd amount of time has been dumped into replacing c-style systems programming.]

c_crank 3y ago
Bug free code only exists when it can be formally verified.
- Verdex 3y ago
  | Bug free code only exists when it can be formally verified. ... okay. Although, on the other hand: | Beware of bugs in the above code; I have only proved it correct, not tried it - Knuth Perhaps bug free code does not exist?
  - c_crank 3y ago
    The replacement languages for C in systems programming aren't memory safe. They can cause segfaults. They have additional tools and syntax rules to make it less likely, but they can and will have memory bugs.
    - Verdex 3y ago