Comment by jeremychone | Hacker News Reader

Comment by jeremychone | Hacker News Reader

Parent Full thread

Here are some random points, but you have more context at the end, so make the decision that fells right to you.

- I heard a lot of npm dependencies nightmare, but somehow, we do not hit that much. Once in a while (a couple of months at most), we get some weird errors, delete node_modules, and are back at it. IMO, TypeScript is a must for any code > 10K LOC (and I use it even with 100 LOC).

- NodeJS/TS's benefit is that it is the same language for the backend and frontend, allowing students to focus on the patterns rather than learning another language.

- However, I love Rust, and I think it is an excellent fit for cloud/web backend. We are moving our NodeJS/TS backend services (web service & job service) to Rust, at least for new ones. Still working on the blueprint, it is quite an effort, and the big question is how long it takes for a whole team to learn Rust well.

- If the university understands the pros/cons of Rust and want to "invest" in it, it might be a good idea to have a Rust backend. However, if they have no clue what it is, it might be too early for them.

- IMO, Rust will become more mainstream in the years to come, especially for backend services. It might take 5 to 10 years, but I hope and think it will get there.

Those are not recommendations, just thoughts, as this is a very contextual decision.

Best of luck, I am sure you will do well, you seem to have all of the right questions.

How does Rust compare to Go in terms of performance? I know that Rust supposedly should be more secure at handling memory than Go. Does Rust have the same mature libraries that Go has? Building a RESTful API, or an HTTP(s) server or for that matter any kind of server (UDP/TCP) should be quite easy to do in Go, due to the awesome net standard packages (libraries) included with the language. Does the same apply to Rust, are the net packages of Rust mature enough? I am just asking out of curiosity :)

I am not a Go developer, I just looked at it from afar, but I understand that the GoRoutine was the cornerstone of high concurrency performance.

In Rust, you have the async/await/future model. You can combine with MPSC (multiple producer single consumer) to have similar message-passing patterns or use traditional Mutex to access shared data. Although the async/await was not designed from the start, the Rust ecosystem has embraced this new concurrency model, which works very well. Tokio seems to be the major future executor crate available that most libraries gravitate around.

So, at zero cost abstraction, all of that allows taking advantage of NIO OS capabilities fully, with extremely efficient async/await/future design choice and implementations (there are some good reading out there about the design decision).

For example, I made a quick video on how to do a "blocking" Redis Stream Read over NIO, which shows concurrency with one thread.

Rust to Redis with Async/Await - https://youtu.be/uD5hBVHwyDM

Thanks for those, I agree. Although I think the term invest you used is very applicable, there'll definitely be a larger barrier to entry.

I don't think they've every heard of Rust and it is a relatively minor project for a small section of the uni. As much as I would love to jump on the Rust bandwagon, I feel more confident that Node.js would be a more "justifiable" choice. It might be easy to understand well written Rust code, but trying to implement something new will need an understanding of lifetimes and memory management.

I would love to see Rust in the web spotlight, it shares blood with C/C++, but it has real potential in higher level abstractions as well. It would be great to have a solid go-to web framework, like Phoenix or Rails, we'll have to wait and see. Good luck with your own endeavour!

I think you have a good point, Rust might be too much for them (at least for now).

Reply on news.ycombinator.com