10 ms·
Farewell, Rust for web
- ewuhic 8mo ago[flagged]
- dang 8mo agoYou've been breaking the site guidelines so often and so badly that I've banned the account. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
- PowerElectronix 8mo ago[flagged]
- Night_Thastus 8mo agoLong compiles are always going to be more friction. No project stays small and quick to compile forever. Get better hardware, and then one day the project is large enough that you're back with long compile times.
- mrbluecoat 8mo agoBetter title: "Farewell, Rust for Web"
- testdelacc1 8mo agoYeah Astro is a great choice for a static or mostly static website. Moving to Astro is not a slight on any other language or framework.
- NewJazz 8mo agoAiui they are also migrating their backend api(s) from rust to node. They were already using astro with rust on the backend (after dropping ssr with tera).
- porcoda 8mo agoYes. This is one of the things that drives me nuts about a lot of titles on here: the context like “for the web” changes how it’s is interpreted a great deal. I see the same thing when I see posts about other languages and AI and such. Context matters versus making it sound like a broad, general statement. Alas, the broad, general statements likely get more engagement..
- dang 8mo agoOk, we'll use that above. Thanks!
- bigstrat2003 8mo agoAgreed! The context matters a lot. Rust is a great language, but using it for the web is a poor choice just like using JS outside the web is a poor choice. Programming languages all have domains where they do well or poorly, and trying to make a single language work for all cases is a fool's errand.
- pseudalopex 8mo agoFarewell, Rust for Web was a worse title. I thought it meant Rust ended WebAssembly support.
- aaroninsf 8mo agoThis is oddly timed in as much as one of the big success stories I've heard from a friend is their new practice of having Claude Code develop in Rust, than translate that to WebAssembly. That seems much more like the future than embracing Node... <emoji here>
- Wintamute 8mo agoIf you’re making a web app your fancy rust wasm module still has to interface with the dom, so you can’t escape that. Claude might offer you some fake simplicity on that front for awhile, but skeptical that’s it fully scalable
- slopinthebag 8mo agoThere are plenty of Rust frameworks that handle this interface for you, including calling Rust functions from JS and JS functions from Rust.
- bryanlarsen 8mo agoRust for Web is awesome for adding control interfaces etc to other programs who have a different primary purpose. And even then I do it by serving JSON API's and not by serving HTML.
- cyberax 8mo agoWell, 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.
- throw-the-towel 8mo agoIDK, I still miss Rust's strictness and exhaustive enum matching.
- socalgal2 8mo agoI don't know about what other strictness you're referring to but exhaustive enum matching is common check in most TS stacks via eslint. Yea, it's not builtin, just saying there's a solution and it's super common.
- cyberax 8mo agoYou can actually have it built-in (via default case in 'switch' statements having a 'never()' statement). But it's less powerful than Rust's.
- nikeee 8mo agoOr you don't use the defualt case and rely on definite assignment analysis or checks for returns in every code path. I find the never type in TS actually being a proper bottom type + having control-flow based types vastly superior to what rust offers.
- tcfhgj 8mo agolast time I researched enums in TS for a project, they were a mess such that it was better not to use enums in the first place
- 8mo ago
- fuddle 8mo agoThe TS/React ecosystem is so mature, it's hard for Rust to compete with it. My optimal stack is currently: Rust on the backend, Typescript/React for web with OpenAPI for shared types.
- ChadNauseam 8mo agoRunning rust in wasm works really well. I feel like I'm the world's biggest cheerleader for it, but I was just amazed at how well it works. The one annoying thing is using web APIs through rust - you can do it with web-sys and js-sys, but it's rarely as ergonomic as it is in javascript. I usually end up writing wrapper libraries that make it easy, sometimes even easier than javascript (e.g. in rust I can use weblocks with RAII)
- resonious 8mo agoIt does work well logically but performance is pretty bad. I had a nontrivial Rust project running on Cloudflare Workers, and CPU time very often clocked 10-60ms per request. This is >50x what the equivalent JS worker probably would've clocked. And in that environment you pay for CPU time...
- ChadNauseam 8mo agoThe rust-js layer can be slow. But the actual rust code is much faster than the equivalent JS in my experience. My project would not be technically possible with javascript levels of performance
- Paul-E 8mo agoI want to address this one point: > Similar thing can be said about writing SQL. I was really happy with using sqlx, which is a crate for compile-time checked SQL queries. By relying on macros in Rust, sqlx would execute the query against a real database instance in order to make sure that your query is valid, and the mappings are correct. However, writing dynamic queries with sqlx is a PITA, as you can’t build a dynamic string and make sure it’s checked during compilation, so you have to resort to using non-checked SQL queries. And honestly, with kysely in Node.js, I can get a similar result, without the need to have a connection to the DB, while having ergonomic query builder to build dynamic queries, without the overhead of compilation time. I've used sqlx, and its alright, but I've found things much easier after switching to sea-orm. Sea-orm has a wonderful query builder that makes it feel like you are writing SQL. Whereas with sqlx you end up writing Rust that generates SQL strings, ie re-inventing query builders. You also get type checking; define your table schema as a struct, and sea-orm knows what types your columns are. No active connection required. This approach lets you use Rust types for fields, eg Email from the email crate or Url from the url crate, which lets you constrain fields even further than what is easy to do at the DB layer. ORMs tend to get a bad reputation for how some ORMs implement the active record pattern. For example, you might forget something is an active record and write something like "len(posts)" in sqlalchemy and suddenly you are counting records by pulling them from the DB in one by one. I haven't had this issue with sea-orm, because it is very clear about what is an active record and what is not, and it is very clear when you are making a request out to the DB. For me, it turns out 90% of the value of an ORM is the query builder.
- cogman10 8mo agosqlx doesn't build queries, or at least it minimally builds them. Which I think is the thing the OP is complaining about. And, IMO, making dynamic queries harder is preferable. Dynamic queries are inherently unsafe. Sometimes necessary, however you have to start considering things like sql injection attacks with dynamic queries. This isn't to poo poo sea-orm. I'm just saying that sqlx's design choice to make dynamic queries hard is a logical choice from a safety standpoint.
- spoiler 8mo ago
- robviren 8mo agoI 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 man, not needing to feel paranoid and how much can be built with so little feels good. But I totally understand just getting crap done and taking off the tin foil. Depends on what you prioritize. Solo devs don't have the luxury.
- ngrilly 8mo agoSame. That’s why Go is such a great tool.
- tasn 8mo agoThese 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.
- incrudible 8mo agoThe 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 scope of dependencies.
- dwattttt 8mo ago> It is much much better for an API to be kinda crappy (but stable) for historical reasons But this does more than just add a maintenance burden. If the API can't be removed, architectural constraints it imposes also can't be removed. e.g. A hypothetical API that guarantees a callback during a specific phase of an operation means that you couldn't change to a new or better algorithm that doesn't have that phase.
- clarabennett26 8mo ago[dead]
- NewJazz 8mo agodue to the nature of safety in Rust, I’d find myself writing boilerplate code just to avoid calling .unwrap(). I’d get long chain calls of .ok_or followed by .map_err. I defined a dozen of custom error enums, some taking other enums, because you want to be able to handle errors properly, and your functions can’t just return any error. This can be a double edged sword. Yes, languages like python and typescript/JavaScript will let you not catch an exception, which can be convenient. But that also often leads to unexpected errors popping up in production.
- grim_io 8mo agoOften is not the word I'd use, from my experience. The times something like that happened to me AND wasn't a trivial fix can be counted on half a hand. A tradeoff I'd take any day to not have to deal with rust all of the time.
- imtringued 8mo agoJava exceptions usually have way more context to the point where I loathe every single developer who decided to catch an exception and only log the top level message. Having a long ass chain of 10 nested exceptions might be overwhelming to a beginner, but an experienced developer knows which types of exceptions are caused by what and instinctively tunes out the irrelevant ones and goes straight to the source of the problem since the stack trace directly tells you which chain of calls caused the issue.
- deleted 8mo ago[deleted]
- eYrKEC2 8mo agoI looove Rust for the backend. I've supported backends in typescript, python, Java, and Rust. Rust pages me the least at night. Sleep is beautiful.
- pjmlp 8mo agoYet Cloudflare happened.
- skwee357 8mo agoAuthor here. I agree with you. Rust is rock-solid. I had zero crashes with Rust. But, having said that, I so-far have zero crashes with Node.js as well. Maybe because I'm a one man team, and I'm very pedantic, so everything is wrapped in try/catch, schema validations, and strict typescript/eslint rules. I would agree with you that *by default*, Rust makes it harder to write bad/bug prone code compared to others, but with discipline (which big teams in "fast moving environments" usually don't have), you can get similar assurances with Node/Typescript.
- chrash 8mo agothe idea of one language to rule them all is very compelling. it’s been promised a lot, and now everyone hates Java. but the truth is that Rust is not meant for everything. UI is an abstraction layer that is very human and dynamic. and i can come and say, “well, we can hide that dynamism with clever graph composition tricks” à la Elm, React, Compose, etc, but the machinery that you have to build for even the simplest button widget in almost every Rust UI toolkit is a mess of punctuation, with things like lifetimes and weird state management systems. you end up building a runtime when what you want is just the UI. that’s what higher level languages were made for. of course data science could be done in Rust as well, but is the lifetime of the file handle you’re trying to open really what you’re worried about when doing data analysis? i think Rust has a future in the UI/graphics engine space, but you have to be pretty stubborn to use it for your front end.
- bryanlarsen 8mo agoRust is "Jack of all trades, master of some". There are real advantages to choosing a jack of all trades language for everything; for example it makes it easier for an engineer on one part of your project to help out on a different part of your project. But it sounds like the OP didn't get any of the benefits of "jack of all trades", nor did he choose a field where Rust is "master of some".
- bitwize 8mo agoLisp is the master of all. Or it would be except "Parens? Eugh! Brotha, eugh!"
- bsder 8mo agoLisp lost because none the the Lisperati came down from on high and deigned to explain how to use it for tasks running on the 1980s microcomputers. Lisp also lost because the 1980s Lisperati spent all their time explaining lists and recursion over and over instead of explaining hash tables, vectors, and iteration. Somehow, Lisp lost out to pathetically slow BASIC interpreters and C compilers that you had to swap floppies continuously for hours. That is a stunning level of fail.
- wofo 8mo agoI'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?
- u16 8mo agoI enjoyed using Rust/WASM for a web application I made. Once I got the build step figured out, which took a week, the application worked like I wanted right away. I was trying to build an HTML generator in Rust and got pretty far, but I don't think I'll ever be happy with the API unless I learn some pretty crazy macro stuff, which I don't want. For the latter project, the "innovation tokens" really rings true for me, I spent months on the HTML gen for not much benefit.
- daxfohl 8mo agoGood to know! You probably saved me a lot of pain.
- jmalicki 8mo agoFor 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 all have their unique pain points that it doesn't seem at all crazy?
- wofo 8mo agoIt'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-bench-runner https://github.com/rustls/rustls-bench-app/tree/main/ci-benc...).
- taylorallred 8mo agoRust shines in user-space systems-level applications (databases, cloud infrastructure, etc.) but definitely feels a bit out of place in more business-logic heavy applications.
- Kinrany 8mo agoYou must have meant something else because it's also great at business logic.
- andrewaylett 8mo agoIt's a throwaway comment in the article, but I feel it's important to push back on: HTML is very definitely a programming language, by any reasonable definition of "programming language". Edit to add: It might not be an imperative language, but having written some HTML and asked the computer to interpret it, the computer now has a programmed capability, determined by what was written, that's repeatable and that was not available apart from the HTML given. QED.
- zem 8mo agoagreed, it's a hill i am very willing to die on too.
- mr_00ff00 8mo agoSo is Markdown a programming language? Any logic for html, is therefore Markdown as well.
- zem 8mo agosure, it's a dsl for generating formatted output
- Dylan16807 8mo agoIf we trim markdown to just italic, bold, and underline, is it still a programming language? What if we trim even further, to just the ASCII control codes? My newline characters make the computer perform a special action to generate formatted output. Is that programming?
- zem 8mo agoif we trim a regex down to literal character matches is it still a regex?
- imtringued 8mo ago
- zem 8mo agorescript [https://rescript-lang.org/ https://rescript-lang.org/] would make a nice middle ground between rust and typescript
- squidsoup 8mo agoA fan of ML, and rescript looks lovely, but sadly typescript is good enough for UI work.
- stevage 8mo ago> And the occasional struggles with typescript where the runtime seems to be changing too often; is it ts-node? tsx? tsm? The built-in typescript runtime in node? deno? bun? This whole paragraph is so true. The last couple of years have been pretty rough in Node land.
- slopinthebag 8mo agoAs someone who went in the opposite direction from Node to Rust, I feel like OP is just trading one set of problems for another set of substantially worse problems. I guess the grass is always greener in the other ecosystem ¯\_(ツ)_/¯ Idk, it just feels like OP chose all the wrong approaches with Rust, including using a separate language and ecosystem for the frontend, which is where most of the friction comes from. For example, Dioxus is a React clone that is somehow leagues better than React (and Next.js, too), and it has hot-reloading that brings compiles down to subsecond times, which makes building UI with it just as productive as with Node / Vite etc. I use it for server side code as well and it's great. Compilation times can be an issue with Rust, it's something I miss from Go, but there are ways to improve on it, and just being smart about what deps you include, avoiding overuse of macros etc can make a difference. I know these things were not around when OP started using Rust for their application, but they are around now. Node and TS are quite frankly inferior to Rust in most ways. Bad language, ecosystem full of buggy unmaintained packages with the worse security profile of all the common languages, no unified build tooling that seems to break your project every 6 months, constant churn of blessed frameworks and tools, an stdlib that is not much more comprehensive than Rust's and outright broken in some ways, at least three different approaches to modules (esm, commonjs, umd, and more...?), I could go on an on. There is a reason why everyone seemingly reinvents the wheel in that ecosystem over and over again -- the language and platform is fundamentally not capable of achieving peoples goals, and every solution developed comes with massive tradeoffs that the next iteration attempts to solve, but that just creates additional issues or regressions for future attempts to tackle. I've been using Rust with Dioxus and was completely mind blown when I started with it. With barely knowing any Rust (just React) I was able to jump right in and build with it, somehow it was more intuitive to me than most modern JS full stack frameworks. It seemingly already has most if not all of the features that similar JS frameworks have been developing for years, and because it's written in Rust things like conditional compilation are built into the language instead of being a third party babel plugin. That helps to remove a ton of friction. And it's trivial to build those same apps for desktop and mobile as well, something that's basically not possible with the JS frameworks. Even stuff like websockets, go try to implement a type safe web socket connection with a server and client in Next.js or Astro. You'll need a ws library, something like Zod for validation, etc. In Rust it's just: #[derive(Serialize, Deserialize, Clone, Default)] enum SocketMessage { Hello(id: i32) } #[get("/api/ws")] async fn web_socket(options: WebSocketOptions) -> Websocket<SocketMessage> { options.on_upgrade(move |mut socket| async move { while let Ok(msg) = socket.recv().await { match msg { SocketMessage::Hello(id) => {} } // handle messages } }) } fn App() -> Component { let mut socket = use_websocket(web_socket); rsx!{ button { onclick: move || socket.send(SocketMessage::Hello(42), "say hello" } } }
- tracker1 8mo agoI would assume today that maybe Dioxus or Leptos would be considered. Though that would be the "all in" approach on Rust front to back... it wouldn't really reduce some of the handling conditions levied in the article though. I find C# can be a really good middle ground on the backend (not a blazor fan)... the syntax and expressiveness improves with every release. You can burrow as lot of patterns from the likes of Go as well as FP approaches. What I don't care for are excessively complex (ie: "Enterprise") environments where complexity is treated like a badge of honor instead of the burden of spaghetti that it is in practice.
- Kalpaka 8mo ago[flagged]
- lloydatkinson 8mo agoThis comment sounds like an AI wrote it.
- weedhopper 8mo agoWelcome to MoltNews. Can’t escape the slop.
- ysleepy 8mo agoRust for web backends is such a weird choice. Use a (statically typed) GC language for that.
- totally-a-human 8mo agoI 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.
- anon-3988 8mo ago> 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.
- Rohansi 8mo ago> 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. TypeScript has static typing though?
- deleted 8mo ago[deleted]
- deleted 8mo ago
- pjmlp 8mo agoRust doesn't make sense for web development, any compiled language with automatic memory management, and value types, has much better tooling and ecosystem. Use it where it is ideal, system programming level tasks where for whatever reasons automatic memory management is either not possible, or not wanted for various reasons.
- barelysapient 8mo agoI feel for this guys path. Rust has a place but not for the type of applications he’s writing. Personally would look at Go over Node as it gets a lot of the systems language patterns without the overhead.
- zelez 7mo ago[dead]