[sylvain_kerkour]

As an indie developer, switching from Go to Rust for web APIs was extremely satisfying. At first there was a productivity loss, but after a few months the productivity was better than Go thanks to Rust's functional features which make it extremely pleasant to write business logic, and the type system catching bugs during development instead of production.

You can read more about the experience here: https://kerkour.com/blog/rust-for-web-development-2-years-la...

The only thing I'm missing is Go's awesome TLS support (with autocert & co).

That being said, I understand your point regarding hiring: a friend of mine totally refuses to learn Rust because the syntax looks not good to him.

[novok]

How much of a productivity boost would you’ve gotten from java or kotlin which provides a lot of those features with all the complexity and build times?

[sylvain_kerkour]

I did a bit of Java and Kotlin for Android development, but never for web APIs so I can't really tell, but one thing I'm sure is that Rust's build system and dependency manager (Cargo) is far more pleasant to use than the experience I had with Java.

Other great things are the ease of packaging with Docker, the low resources usage which helps to keep Heroku's bills small, and the excellent IDE support.

[peppery-idiot]

For web work, are there benefits to using Rust over a garbage collected language that also benefits from a similar type system?

[sylvain_kerkour]

Do you have a specific language in mind?

Honestly, I don't feel that I spend time managing memory in Rust: I use ARC pointers for long-lived shared object (Database connections pool, mailer...) and otherwise the ownership is pretty straightforward during the lifecycle of a request, data is moved from the top layer (HTTP handlers) to the bottom (Repositories to access Database) and back for the response.

[peppery-idiot]

From my limited knowledge, Rust's type system is quite close to the ML family-- so perhaps F# would be a general-purpose GC'd language equivalent?

I am mainly interested to know how much overhead time is spent appeasing the borrow checker and managing memory that would otherwise free up mental cycles if a GC were available . The async story for Rust also seems confusing (but I hold my hands up and plead ignorance on this count).

[skohan]

> I use ARC pointers for long-lived shared object (Database connections pool, mailer...)

Does that mean you basically enforce sequential database reads? Seems like a bottleneck if your server is concurrent

[masklinn]

Arc just allows sharing between multiple threads, it doesn't prescribe any sort of locking.

If they're sharing a connection pool then each HTTP request would get its own connection out of the pool, and they'd be concurrent (access to the pool may or may not be serialised depending on the pool's details, sqlx is internally mutated not externally locked for instance).

The mailer might be behind a mutex (its access completely serialised), or the "mailer" might just be the input side of a queue / channel, and the actual mailing work be done in a separate process (that seems way more likely than bounding the request on sending emails really).