Hacker News Reader

I have been involved in training several "junior" devs in Rust and I would say that it's more about their ability as a developer rather than them being junior.

Developers who could get by professionally in Python, but were not particularly good, have struggled with Rust.

However, we have several developers who joined us directly from their undergraduate degrees who have picked up Rust extremely easily.

> TypeScript is probably a more appropriate choice for most situations – still a rich, powerful type system, great performance, and much faster compilation times

Compared to Rust's normal debug builds Typescript does not have any noteworthy compilation speed advantage in my experience. In fact I find incremental Rust builds very similar if not faster in some cases (of course there are extreme exceptions both ways; I've used a library that added 40 seconds to every Rust build, but also frameworks that didn't make a noticeable difference after the first build). Meanwhile the quality of TypeScript error messages is much worse. Also sometimes debugging gets confusing because TypeScript has a couple blind spots and in the end it still turns into JS with all its quirks. I find Rust's type checker significantly more precise and comprehensive. On the other hand TypeScript doesn't (need to) care about things like pointer ownership, so often there's much less to worry about.

We can cheat Typescript builds by using a different tool to strip the types, and generate type errors on a different thread. The type errors can be terribly slow, and the build times quite fast.

at my startup, we built a graphql server in elixir and its been great. very easy to onboard contractors and the language is very straightforward. https://absinthe-graphql.org/

The performance has been excellent compared to similar offerings in django and rails while having better dev productivity than the equivalent nodejs libraries.

Wouldn't Golang be the TypeScript here as alternative to Rust ?

Why? Golang has a much less advanced type system, comparable runtime performance, a smaller developer community, and a smaller package ecosystem.

Plus, if you're building a backend for a webapp, TS allows your engineers to build full-stack features in the same language, avoiding context-switching, code duplication, and other overhead.

I accept all your points, but comparable runtime performance? That's the only reason that people away from node/ruby/python towards gaoling.

As far as I know, after Node.js/V8 the only reasonable performance gain comes from switching to Rust/C/C++. Everything else is just a few % faster, not a magnitude.

I recently rewrote a computation-heavy Typescript program in Go and what once took 12 hours can now be done in about 3 minutes - there was also some trickery involved running things in parallel but Go made that possible, trying to do that in JS just froze my computer.

Plus it’s a binary I can drop anywhere, will always be backwards compatible, no updated dependency is going to break it, I’m a fan of Go.

Turns out I hadn't heard of go's fiber framework, which performs impressively on Techempower's composite benchmarks (just behind the top ten dominated by C++, Rust, and .NET Core, and barely ahead of Java).

Other than Fiber, the techempower composite framework benchmark[0] ranks gin (go), nodejs, clevergo, and fastify (node) one after the other, all scoring right around 1600.

To be fair, Express is half that good at ~800, but upgrading from express to fastify should be fairly straightforward for those seeking better performance; the much newer fastify has a similar (often compatible) API.

For comparison, Python's fastapi is only 1200, and Django/Rails a mere 250, so lumping Node in with Python and Ruby doesn't make much sense; it'll often perform an order of magnitude better.

For computation-heavy workloads, multiprocessing with Node remains a challenge; Go's a more clear winner there.

[0] https://www.techempower.com/benchmarks/#section=data-r20&hw=...

"difficult to onboard", yeah why not if your juniors are not self learning. But "too slow"? What?!

Edit: oh I get it, "too slow" as in "compilation time". I guess they really needed excuses to move back to another language.

I think "too slow" is "too slow to onboard juniors", not "too slow in terms of performance".

Correct – it took about 6 months for people to become fully productive in Rust, which matches what I've heard elsewhere.

Though I will note that the Rust compilation times were also far more painful than I'd expected – even the tiny (~5k sloc) app at hand would take what felt like a minute to recompute the red squigglies in my editor.

TS felt slow if it took 5-15sec, and Sorbet (for Ruby) was usually <3sec IIRC, so a minute+ was pretty bad.

Rust was in the realm of "just don't use this language if you have ADHD" since you really can't make progress without the compiler's exacting approval, and I'd constantly get distracted while waiting.

Make sure you're not using `cargo build` to check your project. `cargo check` (the thing that makes your squiggles red) has never once taken me a minute to complete. RLS (the default LSP for rust uses `cargo build` - definitely switch to Rust-Analyzer (the soon-to-be default). I just ran `cargo check` on my workspace (10 crates, about 5k LoC) and it took 3 seconds.

My mistake! Replacing RLS with Rust-Analyzer, it now takes 20-30s to incrementally check a trivial change to some core model code (compared to ~90s with RLS), though now rust-analyzer gives me an unrelated error which I assume may be the result of using a different rustup/cargo binary or something – so I'm back to RLS. Oh well. It looks like RLS and Rust-Analyzer are working on unifying their code, so I'm sure this will get better in the not-too-distant future.

Hmmmm RA has been good with me, unless I’m doing something with Arrayfire or PyTorch which are both sensitive to $PATH. RA is seriously the real deal, so I suggest wrenching around until it works. I had to modify my $PATH in VSCode to fix the issue - do you know what library you’re using that causes the issue?

Ah, thanks for the nudge. Looks like I had run into https://github.com/rust-analyzer/rust-analyzer/issues/6835, had to bump the patch version of a library to fix.

> you really can't make progress without the compiler's exacting approval, and I'd constantly get distracted while waiting

You can use cargo check for that, which is fast. It's only for running tests or the like that an actual build is required. Rust also has IDE integration via rust-analyzer, so the error-marking "squiggles" can be recomputed incrementally.

Ironically, I recently received an ADHD diagnosis…

Everyone and their mother is receiving an ADHD diagnosis nowadays. Call me a conspiracist, but I believe this is just one more case of deliberate overfitting by Big Pharma, coupled with the consequences of technology on our attention spans and other characteristics of our cognition and behavior.

As someone that might be similarly diagnosed for the same reasons, your comment does make me more optimistic of achieving something significant in my life, though.

Believe whatever you want, I am just glad that some things are starting to get better for me. I didn't need big pharma to tell me that stuff was bad, I struggled to even get help for far too long, and stigma around over-diagnosis certainly prolonged my problems here.

I'm sorry if I sounded like I was trying to invalidate your diagnosis. I'm sure ADHD is a real issue many people face their entire lives without receiving proper information or care and of course it's better to find out as early as possible. I realize now your comment wasn't the proper place for me to rant about this. I'm happy for you.

It's all good. It's a really, really tricky topic, for sure.

By the same author, nay help: https://www.lpalmieri.com/posts/fast-rust-docker-builds/

This is also covered in a chapter in the book when you deploy the project. I did not do a live deploy but the it looked like a nice setup even for a pet project.

It would be interesting to know where the difficulty was in training juniors to write comparatively simple code in Rust. Was it all about fighting the borrowck, or was there more to it?

> if your juniors are not self learning

At least one team member was a recent MIT course 6 graduate who was able to pick up other new technologies quite quickly without any oversight or assistance. They could get things done in Rust, too, but after a few months felt far from confident.