Java at 30: Interview with James Gosling

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" ?

> 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.

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.

> 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

Okay, but I have hit the joyful part of some other languages long before a few months. What gives?

i didn't "find" it. As i said, it's a well known one : 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.

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.

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.

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.

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.

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.

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. Nothing really weird. Just async hitting the limits of the current rust design.

Not all lifetime problems are just a matter of learning. I've been picking up Rust every few years to catch up, and every single time I've eventually expressed a lifetime that either required unstable Rust at the time or hit a known lifetime bug.

> 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.

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++

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!

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.

i indeed got the feeling that rust style favors macros over complex function signatures.

I'm still unsure if it's a good thing in general, because as a general rule meta programming is always harder to debug. But for simple macros it seems like a nice trick.

> 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

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.

What guarantees are you speaking of exactly?

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.

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.

That's a paper from 20 years ago. GCs have improved since then.

Since you're mentionning it : i was surprised to find no golang "context" equivalent in rust's axum. How do you manage cancelling a long-running operation triggered inside an http request handler when the connection closes ? is it via RAII ?

Yeah due to the design rule that "futures do nothing unless polled", it's enough to simply drop them and it cancels the whole tree of work. That doesn't necessarily cancel other tasks that were spawned that the future might have been waiting on. That's really easy to build if it's needed, since we do have RAII. This is part of why Rust's futures compose really well in ways that goroutines just do not and JS promises struggle with.

Never thought of it like that. Super interesting, thanks.

Edit: isn't that the case for all "async" systems, in every language ?