Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Farewell, Rust for web

yieldcode.blog

Post reply on HN
Print view View original

121–130 of 197 posts

Re: Farewell, Rust for web

#121

Post by ceteia »

throw-the-towel wrote: post #11
cyberax wrote: post #7

Well, yep. People underappreciate the Typescript/JS ecosystem. Typescript is pretty type-safe, and it's perfectly integrated with hot code reload, debuggers, and all the usual tools. Adding transpilation in that flow only creates friction. That's also why things like Blazor are going nowhere. C# is nicer than Typescript, but the additional friction of WASM roundtrips just eats all the advantage.

IDK, I still miss Rust's strictness and exhaustive enum matching.

Enum matching is one of the better aspects of Rust.

Re: Farewell, Rust for web

#123

Post by atherton94027 »

himata4113 wrote: post #111
pjerem wrote: post #88

Earlier quoted context omitted.

> Go is a bit unique a it has a really substantial stdlib It’s not that unique though. I can say that Python and hell, even PHP have pretty complete but also well documented stdlib. Java is meh tier but C# is also pretty good in this aspect. It’s totally a choice for Rust not to have a real stdlib and actually I feel like that would maybe make Rust maybe the best language overall.

java didn't have an http client (I guess it had a url 'stream') for the longest time and STILL doesn't have an http server.

Not really? Iirc `HttpUrlConnection` has been around since the 90s?

Re: Farewell, Rust for web

#124

Post by totally-a-human »

I work on a large mixed Rust/C systems codebase — been converting it piece by piece for a couple years now. The author's frustrations are legit, but I think the real question is simpler: how expensive are your bugs?

If a bug in your system means silent data corruption that nobody notices for a week — and I've lived this — Rust is worth every second of compile time. If a bug means a 500 and you redeploy, you're paying for insurance you don't need. Different worlds, different tools.

The thing I actually love about Rust — and this sounds weird — is how it handles failure. In C, every function call is an implicit "and also maybe something went horribly wrong, but let's just hope it didn't." You get used to it. You stop seeing it. Then one day you're staring at a corruption bug and you trace it back to an error return that got silently swallowed six call sites ago, and you feel physically ill. Result types are annoying when you're validating form input. They're a gift from god when you're the one who has to explain why someone's data is gone.

But yeah, for web stuff? Just use TypeScript. Life's too short to fight the borrow checker over a blog.

Re: Farewell, Rust for web

#125

Post by bilbo0s »

himata4113 wrote: post #111
pjerem wrote: post #88

Earlier quoted context omitted.

> Go is a bit unique a it has a really substantial stdlib It’s not that unique though. I can say that Python and hell, even PHP have pretty complete but also well documented stdlib. Java is meh tier but C# is also pretty good in this aspect. It’s totally a choice for Rust not to have a real stdlib and actually I feel like that would maybe make Rust maybe the best language overall.

java didn't have an http client (I guess it had a url 'stream') for the longest time and STILL doesn't have an http server.

java didn't have an http client [...] and STILL doesn't have an http server.

Wow.

How long has it been since you guys have used Java?

Serious question?

Re: Farewell, Rust for web

#126

Post by wofo »

jmalicki wrote: post #80
wofo wrote: post #33

I'm a heavy Rust user and fan, but I'd never pick Rust for web. There are way more mature ecosystems out there to choose from. Why would you waste "innovation tokens" in a Rust-based web application?

For a web backend? Rust is pretty mature there, it doesn't even feel like an innovation token - it's by my favorite thing to use Rust for. You have very mature webservers, asyncio, ORMs, auth, etc., it's very easy to write, and the type safety helps a ton. In 2020 it might have taken some innovation tokens, but the only things that require a ton less (for web backend) are probably Java, python, and node.js, and they…

It's been a while since I last had a detailed look at web applications in Rust (i.e., stuff with databases, auth, etc). You could use axum for the web server, which is very mature, but I'd say it's too low-level (IIRC you cannot even generate an OpenAPI spec of your endpoints, which IMO is table-stakes). Have you found something more batteries-included, with a similar level of maturity, and actively maintained by a community you can trust? It's a very high bar.

Your reply made me curious about ORMs, btw. Which one would you recommend? Maybe things have improved since I last checked. Last time I didn't like any of them and ended up settling on `sqlx` + hand-written SQL (the code is open source, hosted at https://github.com/rustls/rustls-bench-app/tree/main/ci-benc...).

Re: Farewell, Rust for web

#127

Post by anon-3988 »

totally-a-human wrote: post #124

I work on a large mixed Rust/C systems codebase — been converting it piece by piece for a couple years now. The author's frustrations are legit, but I think the real question is simpler: how expensive are your bugs? If a bug in your system means silent data corruption that nobody notices for a week — and I've lived this — Rust is worth every second of compile time. If a bug means a 500 and you redeploy, you're paying…

> But yeah, for web stuff? Just use TypeScript. Life's too short to fight the borrow checker over a blog.4

I am not sure about TypeScript. I think having static typing is just too good of an insurance against stupid bug and for your own sanity. I think for web purposes, especially with LLM around, you probably should just use Go. You don't have to like it, but there's enough training dataset for your CRUD application. So all you really need to do is to be able to read it.

Re: Farewell, Rust for web

#128

Post by strawhatguy »

tasn wrote: post #18
robviren wrote: post #14

I find the dependency creep for both rust and node unfortunate. Almost anything I add explodes the deps and makes me sweat for maintenance, vulnerabilities, etc. I also feel perpetually behind, which I think is basically frontend default mode. Go does the one thing I wish Rust had more of which is a pretty darn great standard library with total backwards compatibility promises. There are awkward things with Go, but m…

These are two sides of the same coin. Go has its quirks because they put things in the standard library so they can't iterate (in breaking manners), while Rust can iterate and improve ideas much faster as it's driven by the ecosystem. Edit: changed "perfect" to "improve", as I meant "perfect" as "betterment" not in terms of absolute perfection.

Iterating often is not helpful for stable systems over time.

I like go's library it's got pretty much everything needed out of the box for web server development. Backwards compatibility is important too.

Re: Farewell, Rust for web

#129

Post by skydhash »

bobbylarrybobby wrote: post #48
incrudible wrote: post #21

Earlier quoted context omitted.

The cost of "perfecting" an idea here is ruining the broader ecosystem. It is much much better for an API to be kinda crappy (but stable) for historical reasons than dealing with the constant churn and fragmentation caused by, for example, the fifth revision of that URL routing library that everyone uses because everyone uses it. It only gets worse by the orthogonal but comorbid attitude of radically minimizing the s…

I think “the fifth revision of that URL routing library that everyone uses” is a much less common case than “crate tried to explore a problem space, five years later a new crate thinks it can improve upon the solution”, which is what Rust’s conservatism really helps prevent. When you bake a particular crate into std, competitor crates now have a lot of inertia to overcome; when they're all third-party, the decision i…

Is there that much to explore in a given problem space. I believe a lot of people will take the good enough, but stable API over the unstable one that is striving for an unknown state of perfection. The customer of a library are programmers, they can patch over stuff for their own use case. A v2 can be released once enough pain points have been identified, but there should be a commitment to support v1 for a while.

Re: Farewell, Rust for web

#130

Post by lesuorac »

ajross wrote: post #101
slopinthebag wrote: post #51

Earlier quoted context omitted.

Those deps have to come from somewhere, right? Unless you're actually rolling your own everything, and with languages that don't have package managers what you end up doing is just adding submodules of various libraries and running their cmake configs, which is at least as insecure as NPM or Crates.io. Go is a bit unique a it has a really substantial stdlib, so you eliminate some of the necessary deps, but it's also…

> Those deps have to come from somewhere, right? Unless you're actually rolling your own everything The point is someone needs to curate those "deps". It's not about rolling your own, it's about pulling standard stuff from standard places where you have some hope that smart people have given thought to how to audit, test, package, integrate and maintain the "deps". NPM and Cargo and PyPI all have this disease (to be…

I mean somebody could make a singular rust dependency that re-packages all of the language team's packages.

But what's the threat model here. Does it matter that the Rust STD library doesn't expose say "Regex" functionality forcing you to depend on Regex [1] which is also written by the same people who write the STD library [2]? Like if they wanted to add a back-door in to Regex they could add a backdoor into Vec. Personally I like the idea of having a very small STD library so that it's focused (as well as if they need to do something then it has to be allowed by the language unlike say Go Generics or ELM).

Personally I think there's just some willful blindness going on here. You should never have been blindly trusting a giant binary blob from the std library. Instead you should have been vendoring your dependencies and at that point it doesn't matter if its 100 crates totaling 100k LOC or a singular STD library totaling 100k LOC; its the same amount to review (if not less because the crates can only interact along `pub` boundaries). [1]: https://docs.rs/regex/latest/regex/

[2]: https://github.com/rust-lang/regex

Post reply on HN