The Unglamorous Side of Rust Web Development | Hacker News Reader

The Unglamorous Side of Rust Web Development

blog.jetbrains.com

12 pointsvilasa6 comments

>"The ecosystem is fragmented. You choose almost every part of the stack yourself, which is powerful for experienced developers and overwhelming for everyone else."

But Rust is aimed at those who want max performance/min ram & cpu and max control? And will inevitably take time to learn. Its a replacement for C++/C

If someone doesn't want that level of performance and control, I would suggest Rust doesn't make sense as many other languages cater for that - c#, Java and Python being prominent examples.

The authors are making a "A batteries-included Rust web framework" but I would argue that majority of people will use Rust as the back end API and a Typescript based front end. (If not Django/Rails/Asp.net etc).

There are so many contributors to the existing web frameworks that I would say it is most likely is that a Rust based one will never be cutting edge.

Out of all the things listed, dependency tree and compile times are the most problematic things I face in Rust projects. As stated at the very end of the article, if you need tighter feedback loop, you might be happier with other languages.

I do feel weird about a major chunk of this article dedicated to ORMs; I guess people think they are still worthwhile, somehow.

I sometimes wonder how hard it would be to cut dependency trees to size by finding the largest and most easily replaced or disabled subtrees, including in dependencies (not just the main project). Then upstream those changes if possible, in case of disabled subtrees as optional features with compile-time switches.

I can't imagine that all of the 20 MB of code really need to be there in the binary of a 100 kloc main project which does not rely on anything that is traditionally considered a large software package.

A lot of this is still because rust is young. We want a competitive ecosystem so we don’t want to create victors just yet. For web id say follow things in the tokio project for the most cohesion. Tokio ORM runtime and web framework. It all works pretty well together

I don't think it's age. For some reason most languages don't end up having an ORM like Django's that does the entire setup from schema declaration to automated migrations (forward and backwards) to a memorable and powerful query API. JavaScript for example you'd expect to have at least one ORM that does all this given its relationship with the web but you'd be wrong.

wdym?

.Net - Entity Framewok Ruby On Railes- Active record Go - Gorm Rust - Diesel,SQLx,SeaORm Node - Prisma, Drizzle etc

Reply on news.ycombinator.com