4 ms·

Funny. I've been trying rust for the past 2 months fulltime, and i'm really wondering how you can call it a "joy to work with" when compared to java, at least f

by bsaul 1y ago

Funny. I've been trying rust for the past 2 months fulltime, and i'm really wondering how you can call it a "joy to work with" when compared to java, at least for server development. Rust feels like walking on a minefield, praying to never meet any lifetime problem that's going to ruin your afternoon productivity ( recently lost an afternoon on something that could very well be a known compiler bug, but on a method with such a horrible signature that i never can be sure. in the end i recoded the thing with macros instead). The feeling of typesafety is satisfying , i agree. But calling the overall experience a "joy" ?

mynameisash 1y ago
> I've been trying rust for the past 2 months fulltime, > recently lost an afternoon on something that could very well be a known compiler bug With respect, at two months, you're still in the throes of the learning curve, and it seems highly unlikely you've found a compiler bug. Most folks (myself included) struggled for a few months before we hit the 'joyful' part of Rust.
- johnisgood 1y ago
  Okay, but I have hit the joyful part of some other languages long before a few months. What gives?
  - asa400 1y ago
    Rust is genuinely novel, so for most of us its going to be less familiar, so it will take longer to learn. It's not like learning Python if you already know Ruby, for example. The upside is that it offers some pretty great guarantees you can't (yet) find elsewhere. If you want those guarantees it will be worth it, if those guarantees don't matter to you, it may feel like a slog.
    - johnisgood 1y ago
      What guarantees are you speaking of exactly?
      - asa400 1y ago
        The banner one is memory safety without garbage collection. This enables is a terrific degree of library composition. Unlike C/C++, you can generally expect that libraries you pull in will also be memory safe. The other one is thread safety, due to the compiler-enforced ownership semantics that prevent threads from accessing shared data unless they do so in a well-defined way.
- bsaul 1y ago
  i didn't "find" it. As i said, it's a well known one : https://github.com/rust-lang/rust/issues/110338 https://github.com/rust-lang/rust/issues/110338 Simply using axum with code using multiple layers of async was enough. But then again, it looked like this bug (the error message is the same), however at this point i'm really unsure if it's exactly the same. The error message and the method signature was so atrocious that i just gave up and found a simpler design using macros that dodged the bullet.
- heavyset_go 1y ago
  IME, new users do weird things that can expose bugs no one ran into because they wouldn't think to do things the weird way.
  - bsaul 1y ago
    I hope the same, and TBH it's the only reason i'm keeping up developing that backend in rust. I hope that in the end, it's going to improve my style. Go felt the same way (but with a much lower order of magnitude) : you feel like bumping into language limitations, but once you learn to do it "simply" in go, your style will have changed into something much more elegant. As for the bug in question, it has been quite "popular" for about 5 years now, and is actively tracked : https://github.com/rust-lang/rust/issues/110338 https://github.com/rust-lang/rust/issues/110338. Nothing really weird. Just async hitting the limits of the current rust design.
- vips7L 1y ago
  > With respect, at two months, you're still in the throes of the learning curve, It shouldn’t take 2 months of full time programming to beat the learning curve.
asa400 1y ago
I'm not discounting your experience, or saying you're wrong or anything like that. I've been writing Rust for a while, and for me, that feeling went away. Lifetime/ownership problems used to run me over but it almost never happens anymore. I think Rust has a rather severe "hump" that a lot of people run headlong into, but it does get better, I promise you. You start thinking in ownership/borrowing terms and it just fades into the background at some point. Rust is easily my most productive language now. Again, not discounting your experience at all, it can be rough starting out.
- bsaul 1y ago
  i do feel much more comfortable with lifetimes than at the beginning. I get the general concept, and i barely have to explicitely set them (i did start by religiously reading the rust book, of course). However, at the moment i still feel i'm using a huge amount of layers upon layer of complex type definitions in order to get anything done. Just using an object's reference across async calls in a safe manner leads to insane types and type constraints, which read like ancient egyptian scripture. And at every layer, i feel like changing anything could blow everything up with lifetimes. The language has this very special feel of something both advanced and extremely raw and low-level at the same time. It's very unique.
  - charlotte-fyi 1y ago
    In my experience, beginners often make the mistake of assuming just because you can do things with references and lifetimes that you should. Unless you’ve done profiling, just start with the easy thing and clone an `Arc` (or whatever other data structure helps you avoid lifetime problems)! Also, it’s worth saying, you probably don’t need async.
    - bsaul 1y ago
      oh, believe me, cloning and Arc-ing is something i realized very early that i was going to use. But that's the point: you still end up with things like : Arc<tokio::RwLock<dyn MyTrait>> for every single dependency. Then you want to declare an async function that takes an async closure over that dependency. And you end up with a total garbage of a method signature. As for async, the ecosystem for server-side is totally filled with async everywhere now. I don't think it's realistic to hope escaping those issues anyway in any real-world project. i thought i might as well learn to get comfortable with async.
deleted 1y ago
[deleted]
worik 1y ago
> I've been trying rust for the past 2 months fulltime Rust has a horrid learning curve I've programmed for decades in many languages, and I felt the same as you Persevere. Surrender! to compile Weather the ferocious storm You will find, true bliss
- bsaul 1y ago
  I am keeping up, but honestly i feel like rust dev is a bit like a trap : people like us love challenges and solving technical problems. So whenever we "triumph" over a rust tricky compilation issue, we feel intense gratification in solving it. However, at some point you have to ask yourself why you're accepting to face all those challenges. Is it worth it ? When was the last time i faced a race condition when developping a backend ? The reason i started with rust was for a very specific need on building a cross-platform library (including wasm), and that was a good justification, and i'm happy that i did. However now that i'm using it for the server as well and face the same kind of challenges, i seriously question whether this is a wise choice.
  - worik 1y ago
    Generally Rust is the wrong choice. Generally garbage collectors are very worthwhile But whe you need it, it is so much better than C or C++
treyd 1y ago
You eventually learn you leverage lifetimes. You just need to get over that point in the learning curve. I very rarely run into those types of issues, and it's very freeing knowing that I can write libraries that are so hard to misuse because you can leverage the type system. And macros are a part of that!
- rwmj 1y ago
  Why do I need to? Why can't I let the garbage collector deal with it? Rust's macros on the other hand are excellent, and more languages should have expressive macros like that.
  - bitwize 1y ago
    > Why do I need to? Why can't I let the garbage collector deal with it? Determinism. With Rust lifetimes, you can statically prove when resources will be released. Garbage collectors provide no such guarantees. It has been shown that garbage-collected languages have a space-performance tradeoff: you need five times as much RAM to achieve the same performance, even with a "good" GC, as the same program with explicit memory management: https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf
    - int_19h 1y ago
      That's a paper from 20 years ago. GCs have improved since then.
  - treyd 1y ago
    You need lifetimes in order to make the affine types ergonomic to use through borrowings and aliasing mechanics. You want the affine types to prove all kinds of things about resource management, beyond just freeing allocations, which we generally call RAII. You model file and network handles as RAII, mutex locks as RAII. Other languages use constructs like context managers or try-with-resources to capture this, but these constructs are very limited and make it very hard or impossible for these resource types to be put into a container and passed between threads. In Rust this is trivial and actually just works. Garbage collectors usually give much weaker guarantees about when objects are freed, so destructors (which are sometimes not even available, like in JS) might only be called much later. You can't rely on a GC to unlock a muted for you. But in Rust it happens when the guard is dropped, always, immediately after it's last needed.

by bsaul 1y ago

mynameisash 1y ago

> I've been trying rust for the past 2 months fulltime, > recently lost an afternoon on something that could very well be a known compiler bug With respect, at two months, you're still in the throes of the learning curve, and it seems highly unlikely you've found a compiler bug. Most folks (myself included) struggled for a few months before we hit the 'joyful' part of Rust.

johnisgood 1y ago
Okay, but I have hit the joyful part of some other languages long before a few months. What gives?
- asa400 1y ago
  Rust is genuinely novel, so for most of us its going to be less familiar, so it will take longer to learn. It's not like learning Python if you already know Ruby, for example. The upside is that it offers some pretty great guarantees you can't (yet) find elsewhere. If you want those guarantees it will be worth it, if those guarantees don't matter to you, it may feel like a slog.
  - johnisgood 1y ago
    What guarantees are you speaking of exactly?
    - asa400 1y ago
      The banner one is memory safety without garbage collection. This enables is a terrific degree of library composition. Unlike C/C++, you can generally expect that libraries you pull in will also be memory safe. The other one is thread safety, due to the compiler-enforced ownership semantics that prevent threads from accessing shared data unless they do so in a well-defined way.
bsaul 1y ago
i didn't "find" it. As i said, it's a well known one : https://github.com/rust-lang/rust/issues/110338 https://github.com/rust-lang/rust/issues/110338 Simply using axum with code using multiple layers of async was enough. But then again, it looked like this bug (the error message is the same), however at this point i'm really unsure if it's exactly the same. The error message and the method signature was so atrocious that i just gave up and found a simpler design using macros that dodged the bullet.
heavyset_go 1y ago
IME, new users do weird things that can expose bugs no one ran into because they wouldn't think to do things the weird way.
- bsaul 1y ago
  I hope the same, and TBH it's the only reason i'm keeping up developing that backend in rust. I hope that in the end, it's going to improve my style. Go felt the same way (but with a much lower order of magnitude) : you feel like bumping into language limitations, but once you learn to do it "simply" in go, your style will have changed into something much more elegant. As for the bug in question, it has been quite "popular" for about 5 years now, and is actively tracked : https://github.com/rust-lang/rust/issues/110338 https://github.com/rust-lang/rust/issues/110338. Nothing really weird. Just async hitting the limits of the current rust design.
vips7L 1y ago
> With respect, at two months, you're still in the throes of the learning curve, It shouldn’t take 2 months of full time programming to beat the learning curve.

asa400 1y ago

I'm not discounting your experience, or saying you're wrong or anything like that. I've been writing Rust for a while, and for me, that feeling went away. Lifetime/ownership problems used to run me over but it almost never happens anymore. I think Rust has a rather severe "hump" that a lot of people run headlong into, but it does get better, I promise you. You start thinking in ownership/borrowing terms and it just fades into the background at some point. Rust is easily my most productive language now. Again, not discounting your experience at all, it can be rough starting out.

bsaul 1y ago
i do feel much more comfortable with lifetimes than at the beginning. I get the general concept, and i barely have to explicitely set them (i did start by religiously reading the rust book, of course). However, at the moment i still feel i'm using a huge amount of layers upon layer of complex type definitions in order to get anything done. Just using an object's reference across async calls in a safe manner leads to insane types and type constraints, which read like ancient egyptian scripture. And at every layer, i feel like changing anything could blow everything up with lifetimes. The language has this very special feel of something both advanced and extremely raw and low-level at the same time. It's very unique.
- charlotte-fyi 1y ago
  In my experience, beginners often make the mistake of assuming just because you can do things with references and lifetimes that you should. Unless you’ve done profiling, just start with the easy thing and clone an `Arc` (or whatever other data structure helps you avoid lifetime problems)! Also, it’s worth saying, you probably don’t need async.
  - bsaul 1y ago
    oh, believe me, cloning and Arc-ing is something i realized very early that i was going to use. But that's the point: you still end up with things like : Arc<tokio::RwLock<dyn MyTrait>> for every single dependency. Then you want to declare an async function that takes an async closure over that dependency. And you end up with a total garbage of a method signature. As for async, the ecosystem for server-side is totally filled with async everywhere now. I don't think it's realistic to hope escaping those issues anyway in any real-world project. i thought i might as well learn to get comfortable with async.

deleted 1y ago

[deleted]

worik 1y ago

> I've been trying rust for the past 2 months fulltime Rust has a horrid learning curve I've programmed for decades in many languages, and I felt the same as you Persevere. Surrender! to compile Weather the ferocious storm You will find, true bliss

bsaul 1y ago
I am keeping up, but honestly i feel like rust dev is a bit like a trap : people like us love challenges and solving technical problems. So whenever we "triumph" over a rust tricky compilation issue, we feel intense gratification in solving it. However, at some point you have to ask yourself why you're accepting to face all those challenges. Is it worth it ? When was the last time i faced a race condition when developping a backend ? The reason i started with rust was for a very specific need on building a cross-platform library (including wasm), and that was a good justification, and i'm happy that i did. However now that i'm using it for the server as well and face the same kind of challenges, i seriously question whether this is a wise choice.
- worik 1y ago
  Generally Rust is the wrong choice. Generally garbage collectors are very worthwhile But whe you need it, it is so much better than C or C++

treyd 1y ago

You eventually learn you leverage lifetimes. You just need to get over that point in the learning curve. I very rarely run into those types of issues, and it's very freeing knowing that I can write libraries that are so hard to misuse because you can leverage the type system. And macros are a part of that!

rwmj 1y ago
Why do I need to? Why can't I let the garbage collector deal with it? Rust's macros on the other hand are excellent, and more languages should have expressive macros like that.
- bitwize 1y ago
  > Why do I need to? Why can't I let the garbage collector deal with it? Determinism. With Rust lifetimes, you can statically prove when resources will be released. Garbage collectors provide no such guarantees. It has been shown that garbage-collected languages have a space-performance tradeoff: you need five times as much RAM to achieve the same performance, even with a "good" GC, as the same program with explicit memory management: https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf
  - int_19h 1y ago
    That's a paper from 20 years ago. GCs have improved since then.
- treyd 1y ago
  You need lifetimes in order to make the affine types ergonomic to use through borrowings and aliasing mechanics. You want the affine types to prove all kinds of things about resource management, beyond just freeing allocations, which we generally call RAII. You model file and network handles as RAII, mutex locks as RAII. Other languages use constructs like context managers or try-with-resources to capture this, but these constructs are very limited and make it very hard or impossible for these resource types to be put into a container and passed between threads. In Rust this is trivial and actually just works. Garbage collectors usually give much weaker guarantees about when objects are freed, so destructors (which are sometimes not even available, like in JS) might only be called much later. You can't rely on a GC to unlock a muted for you. But in Rust it happens when the guard is dropped, always, immediately after it's last needed.