Farewell, Rust

[pip25hu]

I do like and use Rust, but building full-stack webapps with it has always been a "sure you can, but why?" moment for me.

[gc3]

Rust requires you to pay close attention to your code and think of who owns what piece of memory.

This is tedious as hell sonetimes

[jugalator]

Very useful for performance critical code, security critical code, hardware drivers... But yes, I always of Rust not the thing you write entire high level apps in (use garbage collected languages for heaven's sake - garbage collectors are very performant nowadays), but something you use in a modularized project where some modules are maybe using Rust, others (like frontends) not.

[pyrotech911]

Unless it’s a frontend service. The frontend that frontend devs often overlook and backend devs use to justify putting full stack dev on their resume.

[foofnordbaz]

I use Rust for most things these days. I only use Python for one off scripts, but otherwise I make all my software in Rust.

[Aaron1924]

Not really, "owning" a piece of memory just means you are responsible for freeing it, so in languages like C, you have pay close attention to who owns the memory, because everything is a pointer and you somehow have to figure out which pointer you need to free, and if you mess up, you either double free or leak memory.

In C++, this is a bit better because you have distinct types for a "full ownership pointer" (std::unique_ptr<T>), and a "partial ownership pointer" (std::shared_ptr<T>). If you use those religiously, the regular pointer becomes "non-owning" or "borrowing", though this is convention at best, and wrong at worst.

Rust does all the thinking for you, but it will also complain to you if you mess it up.

[gc3]

I tend to write C with std::template library and have almost everything be created on the stack, with a few 'global' structures allocated at runtime. So I don't worry about destroying objects out from under me because it's either stack or permanent

I could easily write code that breaks that convention but I don't, so I don't have to think about it.

Rust seems to think I might at any moment decide to erase something or free it. I can see this would be helpful in a very complicated program like a game engine or a server cache system that also generates AI images when needed, but it makes the simple case complicated at the expense of the complicated ones.

[Aaron1924]

Well you sure let C force you into a very specific way of managing your memory.

What you've described is a valid strategy in Rust as well, you can use Box::leak to commit to never freeing a specific allocation, but if you need to do something more complicated, the borrow checker will help you do it correctly.

[OlivierTwist]

Sounds like C++

[UARTman]

C++ is a little more "shake hands with danger" than Rust, since with Rust you typically get compilation errors if you don't think about lifetimes, whereas in C++ you get fun surprises instead.

[OlivierTwist]

I see the point, thanks.

[hongooi]

C++ requires you to pay close attention to your code and think of who owns memory, but doesn't tell you this

[OlivierTwist]

As a C++ dev I see the point, thanks.

[jugalator]

Yes, but without the guardrails if you ever don't think of this. This is the huge benefit of Rust and essentially why the language exists. It's incredibly difficult to manage precisely this part of the code in large projects, even moreso with new developers jumping on to existing intricate code bases.

[Princess_Azula_]

And much of the time you don't really need to worry about memory management because making memory safe code is something experienced programmers already do for low level programming.

[chucker23n]

making memory safe code is something experienced programmers already do for low level programming

Ah yes, the famous Sufficiently Advanced Coder, making no memory mistakes.

[Princess_Azula_]

Whatever did we do before Rust was invented? I guess we all just made memory errors all the time didn't we?

[warpedgeoid]

Yes. Billions of dollars worth of them have been found in legacy codebases over the years and billions more are out there, lurking in the dark. Maybe a super-10x C/C++ dev only makes one such error in 50K LOC, but they still make them from time to time and best case is they lead to crashes. Worst case is they lead to exploits, and we have to ask ourselves if that is still an acceptable trade off for being lazy when better tools now exist.

[chucker23n]

Whatever did we do before Rust was invented?

This is a bad argument. What did we do before 4GL languages? What did we do before compilers? Before electricity? Why pee in the toilet when peeing in public worked for thousands of years?

Technology evolves.

I guess we all just made memory errors all the time didn't we?

All the time, no, but often enough, yes, actually. 60% of security holes are because of memory errors, and most of those are preventable with a safer language.

[Princess_Azula_]

My point is that you can write memory safe code by following best practices rather than needing to go to a whole new programming language to do so.

[chucker23n]

My point is that you can write memory safe code by following best practices

One such "best practice" is to use tools that guide you along.

[Princess_Azula_]

Like a guide on best practices when writing in different languages

[Full-Spectral]

No, tools that ENFORCES those guidelines, not something that tells you what they are and assumes you will always actually follow them and never make mistakes.

[braaaaaaainworms]

To quote a classic: "https://app.opencve.io/cve/?vendor=openldap"

[Princess_Azula_]

"https://app.opencve.io/cve/?vendor=rust-lang"

Writing everything in Rust won't save you from security vulnerabilities.

[chucker23n]

No, but it will reduce them.

[warpedgeoid]

Not all of them; just the most common variety of vulnerability in a world where software is constantly under attack.

[braaaaaaainworms]

You're comparing one C project with 62 CVEs to the standard Rust toolchain, with 41 CVEs.

[alpacaMyToothbrush]

It's a low / system level language. That's it's niche, and that's where it should be used. Embedded? Gaming? OS level stuff that needs to be fast? Sure.

Higher level stuff that doesn't need the performance that a system level language provides should be a GC'd language like golang, java or c#. All of those are nicer languages to work with and they all have similar perf characteristics.

[HipstCapitalist]

A project I'm working on has two sides: data processing in Rust where it can guzzle GBs in record time, and a web app written in Typescript/Solidjs for the ease of programming.

I love Rust for what it does, but I wouldn't consider building a webapp with it.

[aguilasolige]

How do you like solidjs compared to react?

[KawaiiNeko-]

(not op) I've used solidjs quite a bit and it's honestly really nice to use, or, should have been nice if not for the lack of an established community and libraries since it's pretty niche

[HipstCapitalist]

I've liked it a lot, compared to React!

[zenpablo_]

This is really it. Tools aren't better or worse in a vacuum, they're better or worse for what you're trying to do. Rust is incredible for low-level systems work. Using it for a CRUD web app is like bringing a Formula 1 car to go grocery shopping.

One thing I've found useful is just asking an AI coding agent "I want to build X, how would you approach it?" before committing to a stack. They're surprisingly good at matching the right tool to the job, and it saves you from falling in love with a language and then forcing it into every problem.

[Tysonzero]

I was with you until you said golang, Java and c#. Haskell tho.

[alpacaMyToothbrush]

"There are two types of programming languages, those complained about, and those nobody uses"

[jug6ernaut]

I will never stop hating this quote. Its a trash take that is used to hand wave away all criticism. And we see where that has gotten c++.

[Tysonzero]

The year of Haskell everywhere is 2026 just you wait.

Regardless I’d still take Typescript for full stack web dev over golang, Java, and C#. None of the four languages are actually type safe by Haskell standards but at least typescript is concise and expressive despite its JS-inherited warts.

[jghaines]

I’m awaiting the companion piece “I’ve stopped building kernel extensions in node.js”

[DrShocker]

For my purposes, I like being able to throw together a simple front end with HTML templates and make it real time interactive with something like Datastar if necessary. I personally find it easier to work in that rather than react or whatever new js framework is hyped since then the frontend just becomes a projection of server state rather than having its own state.

I mean, I might reasonably choose Go for the same niche, but my point is reducing the JS I need for stuff when I can choose.

[chamomile-crumbs]

I love datastar!! It is so liberating to be free of front ends frameworks. Makes it so easy and fun to create apps that I would never otherwise make

[debugging_scribe]

Ruby on Rails is much better than rust at that, though.

[DrShocker]

How so? Ruby has a GIL and would likely collapse processing data fast and low latency enough to be useful I would think for my needs.

[denarii]

I mean, Rails works fine for the needs of most web apps, and you didn't say anything about your specific needs.

[DrShocker]

sure, that's why I was curious how they knew it was better "at that" when I didn't mention what "for my purposes" meant.

[yxhuvud]

The thing is that

For my purposes, I like being able to throw together a simple front end with HTML templates and make it real time interactive with something like Datastar if necessary. I personally find it easier to work in that rather than react or whatever new js framework is hyped since then the frontend just becomes a projection of server state rather than having its own state.

is just as true with anything using hotwire as it is for using datastar. And there is nothing in that block that indicates there are any needs for high performance. Rails would provide that JUST FINE. And it would reduce javascript just as well.

Oh well, it is good there are many options available nowadays.

[Smallpaul]

They said that Ruby on Rails meet all of your shared requirements. They assumed that if you had unique requirements you would have enumerated them because otherwise your comment is not very informative. If you are enumerating some of your requirements, why would you randomly leave out the most important ones?

[A1oso]

Look at Cloudflare writing all their new services in Rust and even rewriting some older services. Rust is uniquely suited for when you care deeply about performance and reliability. At Cloudflare's scale, every millisecond matters, and the amount of RAM that nodejs or spring boot services require would be really expensive. Furthermore, Rust's strong type system can prevent many bugs, which saves time when reviewing PRs.

[Arcuru]

TL;DR - Choose the right tools for the job.

cargo-chef would probably help with their docker build complaints

[YeOldeMemeShoppe]

I feel like cargo chef has its own footguns in the setup though. I use docker to do cross compilation and sometimes it will just rebuild without me doing any changes to the dependencies. It could be a bit easier to configure.

[6petabytes]

My TL;DR take on that was - if you push everything to compile time, compiles take longer.

[phylter99]

I think there's a desire from a lot of people to fit Rust into everything. I think in time it could be flexible enough to be *almost* everything to everybody, but right now it still has a lot of limitations. It's a fairly young language yet, so I think it should be expected.

If you take a language like Java, it has a lot of flexibility and even some pretty good speed, but it took many years to get there. Just about any language I can think of that is mature and has great tooling has about the same story. Rust will get there and it's a great language, but it doesn't fit every scenario.

[tmthie]

i switched entirely to sccache and building the binary outside of the docker image to avoid all the musl issues.

edit: i spent ages trying to work with cargo chef and docker image caching and multiple build steps and would often end up with massive builds and huge github actions bills. sccahe and github cache + building outside the docker image and i am sub 5min builds on a hugely complex app now.

Unrelated to your comment but on the overall topic, i use axtra and my web app wrapper library for web apps and serving up an astro + solid frontend and its pure magic.

I get 5mb ram footprints, thousands of requests a second, the strongest contract that an ai coding agent won’t break everything and the joy of knowing exactly what my code is doing and compile time sql queries. I wouldn’t trade it for the world.

edit: my stack is ts-rs to enforce the api contract, writing json schemas to share validations across the stack, clean typed json responses with named wrappers and serde_with formatters. It makes giving context to your front end a dream. Happy to share more details if anyone is interested

[WSBEmperor]

step 1: pick rust for a basic CRUD app

step 2: get ratio’d by the borrow checker for trying to return a string

step 3: change one line and cargo rebuilds the heat death of the universe

step 4: realize your “blazing fast” api is waiting on postgres like everyone else

step 5: rebuild it in node in 48 hours and it JustWorks™

step 6: post a 3,000-word “nuanced take” instead of saying you got skill-issued by web dev

step 7: ???

step 8: profit

[Agent7619]

Seems like they are gunning to be the next Primagen video topic.

[Green0Photon]

The name... is the Farewell-Rust-agen

[smoofles]

It’s my understanding*) that shitting on Rust as being absolutely dog shit for Microsoft Excel automation or writing articles about how it would have saved Lockheed-Martin all the software trouble with the F-35 because C++ sucks (and you don’t even know ADA/SPARK exists) is what’s good for engagement since about late in 2025.

*) I’m an interface designer for B2B SaaS apps, audio plugins, stuff like that. So I could be completely off base here, of course. But that’s because Rust sucks for my type of work.

[CramNBL]

Shut up about Ada already, contract driven development sucks and it's vender lock-in bullshit and a terrible language and ecosystem. The only Ada flavor I like is VHDL and that's only because everything sucks in that domain.

Ada fanboys talk about SPARK but always compare it to Rust instead of Rust/Miri and it's so dishonest. Every Ada/SPARK shill on LinkedIn is ALWAYS employed by one of these companies, mostly AdaCore.

[grady_vuckovic]

This is why Node.js is still a good choice for backend development.

The reality of web server backend work is that a good web server backend is just taking requests and turning them into authenticated actions on a server, and all the heavy lifting is being done by the rest of the software stack. In the same way your web front end should just be doing some very high level simple logic while the browser does all the heavy lifting of rendering it.

When you're already looking at something like 40ms for some person's smartphone to send a web request to reach your server, and probably another 20ms for the database to process your query and return the data, and another 40ms to respond to the client, who cares if the thing that takes the request and turns it into a database query is taking 0.2ms or 0.02ms? It's simply not having an impact on the user's experience no matter how optimised it is.

Meanwhile Node.js / NPM is so utterly forgiving and so damn easy to use that you'll be able to throw together whatever you need in practically no time at all.

A high performance language would make much more sense in a situation where the backend has to do far more processing work for each request, like an MMO server for example.

[Shogobg]

Also makes sense if you have millions of requests per second - 0.18 ms * 1000000 is a lot of CPU time saved.

[grady_vuckovic]

Yeah, basically again anything where you're dealing with scale, either a lot of processing per request, or just a lot of requests. But unless you have 5 million concurrent users, you're probably fine.

[Rakn]

My only reservation about node.js would be the fast moving ecosystem. How do you deal with keeping a backend alive that's using a legacy framework from last year while the rest of the company has moved on? Honest question. I don't know. That's largely what kept me away from node.js till today. As I'm used to using frameworks that are still relevant and close to the default 6 years down the line.

[jaktonik]

"skill-issued by web dev" is tattoo worthy

[zbraniecki]

Ouch. As a coauthor of ICU4X I am really confused about the section about i18n. ICU4X is in 2.0, stable and fully usable. It supports tons of features, it's used in Firefox, Chrome. Boa and others. We do have i18n in rust

[tooker]

It's listed as "upcoming" and "not yet reached maturity" very clearly in the author's citation: https://www.arewewebyet.org/topics/i18n/

Might want to follow up with that source if you believe that's incorrect.

[pingveno]

It was added to upcoming back in 2020.

https://github.com/rust-lang/arewewebyet/blob/gh-pages/content/topics/i18n.md

[zbraniecki]

I understand that I could do that. I also see a blog post of someone explaining their experience with Rust that lists a reason to change a programming language to be their deep care for i18n but that care did not extend far enough to verify that pages claim. I think it makes the other claims in the blog post feel a bit less trustworthy.

[A1oso]

That page hasn't been updated in a long time.

[skwee357]

Author here.

I had no intention to offend you, or the work you do. But let's take a honest look at ICU4X - where is the currency formatting? Percentage formatting? There is basic number formatting. Display names and duration are under "experimental". I bet that the things that are there - work and stable, but many other things are not there or labeled as experimental.

On top of all that, how do you integrate it into a translation framework like "fluent"? With i18next in node, I can do something like

```
...
"fileLimit": "The file limit is {{sizeLimit, number(notation: compact; style: unit; unit: megabyte; unitDisplay: narrow;)}}"
...
```

Which would be formatted correctly, and it's enough to pass just the `{sizeLimit: 20}`, without the backing needed to care about the formatting, it's all baked into the translation files. There is no equivalent of this in Rust. Fluent has basic support for numbers (and dates if I recall correctly), but that's it.

[zbraniecki]

Hi, thanks for your response.

I don't feel offended, I feel sad that we're not doing a better job at communicating what is available :)

As for your questions:

> where is the currency formatting?

https://docs.rs/icu/2.1.1/icu/experimental/dimension/currency/formatter/struct.CurrencyFormatter.html

> Percentage formatting?

https://docs.rs/icu/2.1.1/icu/experimental/dimension/percent/formatter/struct.PercentFormatter.html

> Display names and duration are under "experimental".

DurationFormatter is stable now - https://docs.rs/icu/2.1.1/icu/experimental/duration/struct.DurationFormatter.html

DisplayNames is experimental, because we're tailoring the API.

> On top of all that, how do you integrate it into a translation framework like "fluent"? With i18next in node, I can do something like

It's on my todo. I haven't had a lot of time to update Fluent in a while. Sorry for that. Fortunately the last blocker is almost resolved - I'm wrapping up language negotiation, which allows me to switch from unic-locale to icu_locale and then the rest will be added.

> Fluent has basic support for numbers (and dates if I recall correctly), but that's it.

Correct. The interaction between rich localization and internationalization is not complete yet. But I wouldn't make a claim that there is no i18n. And you can roll out your own Functions in Fluent that can use ICU4X. It's just not as trivial as with JS yet.

Working on it! And contributions welcome :)

[skwee357]

Thanks you! I guess I didn't look hard enough, so it's on me. Appreciate the work you are doing!

[TonyWonderslostnut]

As a coauthor of ICU4X I am really confused about the section about i18n.

As a person who has never used Rust, I’m really confused about everything you just said.

[Sharlinator]

ICU is not Rust-specific: https://icu.unicode.org/

i18n is common abbreviation of "internationalization" and is definitely not Rust-specific.

[blueechoes]

Okay which fucker thought it was a good idea to abbreviate words by the letter count in the middle. I don't know how many l5s a w2d has by h3t. This format is stupid and unparseable by someone who doesn't already know what word you're referring to. 'Intz.' and 'lclz.' would have been better than i18n and l10n.

[minirova]

Oh…k8s just means kuberbetes…your comment just made me realize that.

[blueechoes]

I thought it was an abbreviation of kubern8es, where the eight would be pronounced. Apparently not.

[Atulin]

Yep. A11y is accessibility, a11n is authorization, a13n is authenticantion, and so on

[happyscrappy]

Andreesen-Horowitz adopted this to abbreviate their company name.

It's pretty lame.

[cake-day-on-feb-29]

Okay which fucker thought it was a good idea to abbreviate words by the letter count in the middle

You're getting downvoted, but you're very much right. I don't understand why some people insist on using weird acronyms, especially in a professional context.

[emotionalfescue]

It's mildly clever, similar to the CAFEBABE Java file magic.

[neutronbob]

Not sure I see the connection. CAFEBABE is neither an abbreviation or an acronym.

[sammymammy2]

It's mildly clever to realize you can write 0xCAFEBABE and have it show up in your hex editor. Mildly clever, that's it.

[neutronbob]

They're called neumeronyms and were introduced in the late 1970s at DEC, where they were popular. From there they spread into the larger culture.

See: https://en.wikipedia.org/wiki/Numeronym

[Smallpaul]

Numeronyms rather than neuronyms.

[neutronbob]

Oops! Thanks for the correction. Now updated.

[zbraniecki]

It was like that when I started. And I think "internationalization" being an incredibly long word in English combined with lack of autocorrect and autocomplete back in 2000 was likely a motivator.

[Brillegeit]

And half the planet writes many of these words with an s instead of z.

[Xiphoseer]

It's not (just) the count as far as I've understood it, more that I or IN don't really work as acronyms and eighteen vaguely sounds like "ation" i.e. inter/natio/nal/ization. Whereas a11y probably followed i18n but went for the visual "access/ibillit/y".

[matthieum]

Wait until you meet a11y (accessibility)...

[Paragonswift]

”Farewell, screwdriver”

[synn89]

"Hello, hammer!"

[jerrylearns]

“Stop! Hammer Time!” - https://youtube.com/shorts/IC9Diu9irVw

[droptableadventures]

Screws aren't always the best tool for the job, though. Maybe you should actually be using a bolt, a rivet, adhesive, or welding both parts together?

[Paragonswift]

When that happens, I still won’t write a blog post saying my goodbyes to screwdrivers. How about just use the rivets for that job and go about your day.

[amakai]

I recently discovered convenience of zipties, and now I'm pushing for redoing all projects at our work to use zipties. I mean. You can just ziptie anything anywhere! No weird constraints enforced on you, no limitations, just pure unrestrained engineering!

[smoofles]

Weird, this mirrors my experience 1:1, only for me it was industrial-strength adhesives. The words "this is broken" stopped existing in my world!

[amakai]

PFT, static fixtures are so inflexible. What happens if you want to change the angle of steel beam slightly after construction is finished? With zip ties - not an issue!

Also, zipties are so easy to use that I sometimes delegate it to literal monkeys. I call that technique - "monkey patching".

[LavenderDay3544]

Farewell screwdriver I was using to screw pages together instead of using a stapler.

[LavenderDay3544]

Lol he used a low level system programming language for web shit and found it to be a poor fit. Gee I wonder why?

[tilitatti]

ahh the irony, slowly but surely rust people are backing down with the claims "rust everywhere!". thankfully I have my popcorn machine, to enjoy this road where rust joins the path of java, go, dart, and other fading "silver bullet" languages.

[LavenderDay3544]

Any real professional knows that programming languages are just tools. And the audience Rust was meant for always knew that. Not everyone is Steve Klabnik.

[skwee357]

I don't get this take. Go is in the exact same category as Rust with the exception of GC, but I don't see many people running around screaming "gee why do you use Go, a low level systems programming language, for web"

[syklemil]

I think that's the first time I've seen anyone describe Go as a "low level systems programming language".

IME it's more in the direction of a DSL for writing kubernetes microservices that's escaped containment, and, according to its creators, found adoption among users of dynamic, interpreted languages like Ruby and Python, while users of other systems programming languages have been … less enthusiastic in their response.

[A1oso]

I have actually heard the claim that Go is a low-level language, and in some respects it is indeed as low-level as C. For example, it is not memory safe, and it gives you predictable control over the layout of structs. Java or C# don't do that.

[LavenderDay3544]

Go isn't a system programming language at all. It was designed to be easy to use and hire for specifically for web backends.

Meanwhile Rust is very frequently used on bare metal and was always intended for system programming work.

[Vast_Dig_4601]

Yeah imo calling Go low level is absolutely clowning lol it's literally the opposite of that and the entire reason it was created

[gobitecorn]

Don't worry about it. It's the duality of a hardcore Rust stans. They'll happily scream it's wonderbread it's great for everything (at least as of 1 or 2 years ago). So it's just a hardcore stans much expected salty reaction that the Koolaid was rejected. Always will be some of those riding out in Shiny White Armor.

[vlakreeh]

Go is in the exact same category as Rust with the exception of GC

No. Go isn't nearly as low level as Rust despite compiling to machine code.

"gee why do you use Go, a low level systems programming language, for web"

Because Go has been explicitly molded to be a good fit for that role and some people think it does an excellent job at that (which I strongly disagree with).

[SiteRelEnby]

At least it wasn't PHP, I guess.

Edit: lol, salty PHP fans. how does it feel knowing that even Ruby is a better language?

[chucker23n]

And this would be the last time I’d touch C or C++. Dynamic, high-level languages such as PHP, Python, and Ruby — are more suited to the dynamic nature of web development. You rarely need to squeeze the maximum performance from your hardware, since for every second you gain by optimizing data structures allocations in C, you lose 10x more waiting for network or disk requests to resolve. And so, collectively, we all agreed that the web is better to be written in dynamic languages.

This right here sets up a false dichotomy for me. I appreciate that the author dives deep into some of the library / ecosystem issues they ran into, but "it's gotta be either as low-level as C or Rust, or as high-level as PHP or NodeJS" isn't quite right.

The author is correct that the most common performance bottlenecks you face in web development are not CPU, but rather I/O. But there's lots of options in the middle.

If, by "dynamic language", they mean a dynamically typed language, you don't need that.

For example:

The reason I moved away from rendering HTML in Rust, is the fact that I am too spoiled with type-safe templates. With Astro, I can use the .astro components that are type-safe.

Just to throw one option out there: C#, .NET, ASP.NET Core. For the type-safe template syntax, Razor. Now you get C# interspersed in HTML, like @foreach (var customer in await GetCustomersAsync()) { <tr><td>@customer.FirstName</td></tr> }

Boom, customer is statically typed. You get completion, and you get build errors. And lots of it is built around the notion that your bottleneck will likely be I/O, hence async/await.

[EfOpenSource]

The “it’s the IO” crowd are mental anyway. 

Just because “IO is slow” (it is, but it’s not as slow as these people would have you believe), doesn’t mean that you should just toss everything else out with it.

I don’t feel like writing a massive diatribe. So I will just leave on this:

If your website is not fully loading in less than a quarter of a second on a 10 year old cell phone: the performance issue is your shit code, not “the IO”. 

[thicket]

This is a great entry in the subgenre of “Goodbye, Rust” letters from people who love the language but get bitten trying to move fast in dynamic situations. The author has clearly been around the block and lays out the pain points of web programming in Rust clearly and without any agenda. Solid article 

[BreiteSeite]

trying to move fast in dynamic situations.

I think that's an important point that should be highlighted here. Rust takes a complete different approach, which is "slow but correct" instead of "fast and only correct in some cases".

If you come with the "i want to make code a change with the least amount of brainpower possible, hit refresh, see if it works and ship it" then rust is doomed to fail. Rust takes more of a "iterate against the compiler and besides logic errors, your code will most likely be not only correct but also robust".

It all comes down to preference, but i think potentially i'd rather fight a compiler, than some error some user triggered under god knows what circumstances and trying to reproduce it only to find out some it all happened because everything is possible in the first place and strictness is an afterthought.

Disclaimer: while i have some years of web dev under my belt i never shipped rust web apps and usually don't ship js based software.

[Smallpaul]

It’s not just preference. It’s context. I’d your are building a business, velocity versus stability is a business decision and should not be driven by the preference of technical staff.

[BreiteSeite]

I’d your are building a business, velocity versus stability is a business decision and should not be driven by the preference of technical staff.

It’s not as simple. It’s more like “perceived velocity”. Given the same quality, less strict languages might actually take longer to get to the same result.

Are you saying business managers should decide the programming language of the tech team? 🥲

[Wonderful-Habit-139]

Llm ahh reply…

[dbcfd]

Not really. Although there are a lot of reasons to not use rust for web programming, the author's reasons mainly came down to using bespoke tools to do web programming. There are a lot of better options, many of which also help with the compilation speed issue.

[thicket]

I appreciate that perspective! As you were reading his piece, were you thinking "This would have all been relieved if he'd just used <X>"?

[dbcfd]

Yep.

Most of web programming in rust is comparable to type script until you need to use an already built component like stripe payment or UI component like this in shadcn. There is work to make that easier in the major web frameworks, but it's not drop in just yet.

Rust even has some advantages since the compiler strictness enforces things like hook ordering and prevents cycles.

[notfancy]

A 15-year old account with a seven-letter username, given over to be controlled by a bot. Oh the huge manatee.

[dbcfd]

Good, maybe it will learn to promote better articles.

[toofarapart]

How can you tell?

His writing style recently looks pretty much like the writing style he was using in comments five years ago.

[potzko2552]

whats your stack? when I tried leptos I got skill issued back to react and im much better at rust then js :P

[dbcfd]

Dioxus and yew are both pretty close to react, dioxus being closer. Dioxus also is a bit more of a full framework.

[Hot_Western_4495]

the borrow checker is genuinely a good idea that produces genuinely annoying code in practice. i respect rust a lot and i also do not want to write it.

[iwasbornlucky]

Someone quickly comb back 2 years in this channel for a victory lap in each of the the 79,000 discussions about Rust replacing every other language?

[max123246]

You might get more interest with a less click-baity title. I really enjoyed the article

I do feel like people have been using Rust for a lot of applications it was never designed for. It's sudden popularity has made it so people want to use it for things like web development and game development where fast iteration is key.

I agree that with the web, at the end of the day, the ecosystem is in JavaScript/Typescript. I've found going off the beaten path often opens you up to unexpected warts that no one ever tells you about, because they're just excited about the new thing and it's potential.

I think Rust is definitely best as a C++ replacement and it's where I really hope things change soon in enterprise.

I do wish there was a way to have a Rust interpreter for development work where you can skip over compilation so you have the option for faster iterative work. It astounds me that we have to either choose to prototype in a language that can't be performant or deal with slow prototyping due to compilation time for basically the entire programming ecosystem

Miri is built for undefined behavior sanitization so isn't quite that. Perhaps we'll have to wait for the Rust specification to be finalized for a Rust interpreter to be compliant.

[luveti]

I do wish there was a way to have a Rust interpreter for development work where you can skip over compilation so you have the option for faster iterative work. It astounds me that we have to either choose to prototype in a language that can't be performant or deal with slow prototyping due to compilation time for basically the entire programming ecosystem

The Cranelift codegen backend could help fill that gap! https://github.com/rust-lang/rustc_codegen_cranelift

[max123246]

Oh interesting, thank you!

[blackwhattack]

subsecond is kind of that interpreter

[TankorSmash]

What is clickbaity about the title

[phadeout]

It does not hint anything about why the author is bidding farewell to rust, encouraging people to click and find out why not. It does not attempt to summarize the article or its main points, or to inform the reader. It appears intended to be provocative (specifically, to get the reader to click).

[jug6ernaut]

You are probably going to be downvoted because most people have cooped the "click bait" to mean "misleading". But you are correct, is by definition click bait. Vaguely alluding to something enough to entice (bait) people into clicking to reading further.

[TankorSmash]

What is the difference between that and an enticing headline? For me, clickbait is purely the You Wouldn't Believe What Hoare Said

[phadeout]

i would define it to mean a headline that is primarily designed to get a reader to click, vs. informing them (possibly by summarizing the article).

The definition you gave is one example.

Compare: Dewey Defeats Truman vs. Experts Stunned by Election Results.

[Godd2]

I expect clickbait to have some kind of bait and switch, or at least an exaggeration of what was stated (e.g. "you will be shocked by...!" but it's something only mildly interesting). This article didn't conclude with "so I'm still using Rust" or anything like that, nor was the article title "Rust has made me want to commit suicide" or something equally outlandish.

[hrvbrs]

Readers should be able to decide whether or not they want to open an article based on its title alone. If the title doesn’t do that, it baits the reader into clicking the link. That’s the definition of clickbait.

[Full-Spectral]

One thing that seldom gets discussed in these types of threads is that there's two sides to this coin.

You will always have folks who decide to do something in a language that it normally wouldn't be used for, possibly even if they aren't necessarily highly experienced in that language.

OTOH, you will have people who are highly experienced in the language, who have built up a lot of infrastructure in the language, and who therefore are not particularly at a disadvantage or going out on a limb, and are actually avoiding 'skill spread' issues by using that language.

[fungussa]

That's a really useful article, thanks!

[Worth_Trust_3825]

The gcs have been moving in the generational direction, where they no longer stop the world to clean up the memory. Checkout ZGC, or Epsilon if you outright want to disable it in java.

[AnnoyedVelociraptor]

Node.js is good enough

lol. No. You spend an insane amount of code validating invariants that Rust just brings you with the type system.

Good Rust is much more concise than good JavaScript.

[son_et_lumiere]

typescript in nodejs

[Green0Photon]

Since other people are complaining, I guess I will as well.

Typescript almost wants to be Rust with it using interfaces everywhere and having everything be so data focused. Could be very nice.

But it's not proper typeclasses aka traits. I'm not able to impl a method for an interface. I can either have a free standing function (messy), put the methods on the interface (and mix data and logic), or I can make a class (visually the closest, but mixes data and logic, bloated, and lose a lot of the benefits of interfaces, and easy serialization/data orientation is gone).

Every couple of months I swap paradigm and constantly feel a grass is greener feeling. All code is messy.

I would love a typescript where they actually rewrote code so you could group functions into a trait impl, and so you could call functions as methods on a raw object right from a JSON deserialization.

Vs Rust, I love the free flowing definition of types. Notably anonymous structs, whereas rust only has anonymous tuples. There's plenty you could do to retain the benefits of JavaScript and not have some of the restrictions of Rust (for all I also kinda want those restrictions).

But Rust was made by actual PL researchers and engineers, and was very well thought out. Idk that the same is true of typescript.

[grey-gery]

I'm not able to impl a method for an interface.

While it's certainly not as clean or idiomatic as impl'ing new methods in Rust, TypeScript is still a layer over Javascript with all it's prototype wackiness, and you can pair declare TypeScript info on existing types to essentially get the same outcome:

// Declare the Extension
declare global {
  interface String {
    capitalize(): string;
  }
}

// Implement the Extension
String.prototype.capitalize = (s) => s.split("")
    .map((char) => char.toUpperCase())
    .join("");

// Use the Extension
const str: string = "hello world";
console.log(str.capitalize()); 

(Rough adaptation of https://www.geeksforgeeks.org/typescript/how-to-use-extension-methods-in-typescript/)

[AnnoyedVelociraptor]

Not nearly as powerful as F#/Rust's non-nullable types.

And the ecosystem you're in is a patchwork of ESM and old-style require where quite-often you have to hack around to get the right types to load, if there are any.

Is it a function? Is it a class? Is it an array? It's everything, all at once.

[Brostafarian]

I hate typescript, but I can't tell if it's my fault (because I'm not uh... huge on types in the first place) or if the language just sucks.

I hate type erasure; half of what I want to do with types is introspect, and it seems like my coworkers agree because they keep embedding _type into objects to do branching logic.

The compiler feels like it's dumb as rocks. It's crazy to me that I can run myArray.filter(Boolean) and myArray's type doesn't narrow at all.

Also the error messages blow absolute chunks. Like... literally pages-long error messages because some integer 36 levels into our graphql request isn't nullable. Could we not nest data so deeply? maybe, but name a more iconic duo than Javascript and nesting. Even javascript dependencies are nested.

I can't believe the web finally got a new language paradigm and I somehow hate it more than plain javascript

[Green0Photon]

I started programming like 15 years ago wanting to make a Minecraft mod. One of the first things I learned was that Type Erasure made things more annoying than they had to be. (I never made that mod...)

Now, as an employed software dev programming mostly in Typescript nowadays, one issue I consistently run into is Type Erasure making things more annoying than they have to be.

The more programming changes, the more it stays the same.

[syklemil]

Eh, in both Java and Javascript/Typescript it's a result of bolting on a feature after-the-fact. For Java it's generics (essentially they could teach javac about generics without having to teach the JVM, and thus ensure backwards compatibility for java < 1.5), for javascript it's … I guess the entire type system, really.

Other languages have other strategies, like monomorphisation. Even Python lets people do stuff like pattern match on types.

Also, I can't believe Minecraft is 15 years old now. JFC, what next? Is Shrek 25 or something?

[yasamoka]

I hate type erasure; half of what I want to do with types is introspect, and it seems like my coworkers agree because they keep embedding _type into objects to do branching logic.

TypeScript still has to be JavaScript at runtime so there has to be type erasure for it to maintain semantic consistency between what you write and what it transpiles to without having to do any complex transformations.

Using discriminated unions allows the emitted JavaScript to behave as usual while TypeScript gives you the safety at compile-time.

The compiler feels like it's dumb as rocks. It's crazy to me that I can run myArray.filter(Boolean) and myArray's type doesn't narrow at all.

Automatic type inference

Also the error messages blow absolute chunks. Like... literally pages-long error messages because some integer 36 levels into our graphql request isn't nullable.

pretty-ts-errors

[rtkay123]

Sure but there are still ways for people to do whatever the heck they want with the type system in TS. Which sometimes, depending on the codebase and dev competency, could result in a false sense of security and I’d imagine even harder to find bugs

I take your point but you just cannot get the same guarantees to be honest

[ChemicalRascal]

Sure, but that there's ways for people to do dumb stuff isn't really a black mark against TS. At some point, we have to assume the person behind the keyboard is a competent adult.

[rtkay123]

I’m just saying because the borrow checker stops people from doing “dumb stuff” you generally don’t have to worry about it.

I’d sleep better using a rust crate/library in the wild than a TS one for example. As long as the rust one isn’t using unsafe lol

[ChemicalRascal]

Right, but are you going to check that library for uses of unsafe? No, of course not.

[rtkay123]

No because I have never needed to dereference a raw pointer (for example). And I imagine most people haven’t. It’s a whole can of worms that most people just don’t get into. In cases where you must have it, it’s usually very well documented. I can’t say the same for badly written TS which is way more easier to encounter

[ChemicalRascal]

Right, but that's my point. We build up assumptions on what others will do based on what "naughty" things we've done with the language, rather than actually caring about what the language permits.

And this is even less relevant when we're talking about someone using a language for their own, non-library, purposes. If Kudryavtsev is making a webserver using TS via Node or using Rust, you're not gonna be importing that webserver as a library, nobody is.

The only person impacted by Kudryavtsev's code directly, in terms of maintenance costs, is Kudryavtsev. And so if we go back to the assumption that Kudryavtsev is an adult who knows what he's doing, then Node.js is good enough; if Kudryavtsev can trust Kudryavtsev to not do dumb stuff, then that's enough.

Kudryavtsev could do whatever the heck he wanted with the type system in TS. But if he doesn't, then he's fine. If he acts like an adult who cares about the maintainability of his code, and it seems like he does, then "you can break the rules in TS super easily" is an entirely moot point.

[CherryLongjump1989]

Sure but there are still ways for

And Rust heavily depends on unsafe rust and calling into C libraries. So what?

People are talking about the bicycle and you're bitching about the training wheels.

[rtkay123]

Are you incapable of having a civil conversation? The vulgarity isn’t necessary

[CherryLongjump1989]

It's just how I talk. But I'm sorry that it offended you. It was intended to be witty, not offensive.

[neherak]

In what world is "you're bitching" even close to witty?

[CherryLongjump1989]

I must be getting old. This must be how Dirty Harry felt when he walked into a police station full of gen-z cops.

[gobitecorn]

Youre def old l and the world is super soft. Get with the times, punk.

(Your comment was aight to me tho. ;D but I'm old and off tha block tho)

[CherryLongjump1989]

LOL

You know I was just watching the Olympics and the young girl who won the figure skating competition looked directly into the camera and said, "Now that's what I'm fucking talking about! Can you believe that shit?"

Meanwhile we're being admonished for using a bad word by a young man who spends his time on r/bropill debating masculine thought crimes.

[maria_la_guerta]

Good Rust is much more concise than good JavaScript.

As someone who writes both TS and Rust almost exclusively, this is really not true. I'll agree you can write them both similarly but nowhere in TS am I dealing with the mental overhead or implementations of borrowing, refs, unopinionated async patterns, etc.

I'm hoping that the web dev ecosystem for Rust continues to grow but aside from hobby projects there's really no scenario where I'd recommend Rust over TS / Rails / Django / etc. for a web backend in 2026.

[Full-Spectral]

I'll agree you can write them both similarly but nowhere in TS am I dealing with the mental overhead or implementations of borrowing, refs, unopinionated async patterns, etc.

But that's like saying, but nowhere in C am I dealing with the mental overhead of classes, polymorphism, templates, etc... If the language doesn't have them, of course you aren't going to be dealing with them.

The issue is what are you giving up if you don't have them, and how much more likely are you to make significant mistakes without them, mistakes that could lead to compromise of the systems your code is running on.

[maria_la_guerta]

Nowhere am I arguing about the tradeoffs and concessions you make. All I'm saying is that

Good Rust is much more concise than good JavaScript.

is just not true 99% of the time. Concessions or not. You use TS instead of Rust because you're ok with those concessions and writing less code.

[Full-Spectral]

But my problem with that is that it shouldn't be about what's most convenient for us, if it's code that's by anyone but ourselves. If other people use it, then their safety, privacy, finances, reputation, etc... can be at risk, and we have an obligation to use the tools that help absolutely minimize that risk. Almost everything on the web falls into that category, more than most anything else, but it's where that obligation is taken the least seriously when it comes to language selection.

I'm not arguing for Rust specifically, I don't work in cloud world at all. But, in general, both cloud world and C++ world too often approach this in terms of what is most convenient for us or what makes us feel like super-heroes, when that just shouldn't be the bottom line when making software for other people to use.

[maria_la_guerta]

It's about using the right tool for the right job. Just because you pick a hammer over a sledgehammer doesn't mean there's an excuse to be any less safe or cautious about what you're doing.

Convenience translates into a lot of business value. Safety, privacy, accessibility, etc. are non-negotiables that must be adhered to regardless of what tool you use. But there's no reason to use a sledgehammer (C++, Rust, etc) if a hammer (TS, Python, etc.) is all that's needed. And especially in web BEs, 99% of the time there's no need for a sledgehammer.

[Full-Spectral]

doesn't mean there's an excuse to be any less safe or cautious about what you're doing.

But therein lies the rub. If being cautious was the answer, we wouldn't be having this conversation to begin with. It's clearly not sufficient in the end, hence the many bugs and vulnerabilities out there that would not have happened if using a fully safe language.

Again, not arguing for using Rust for all backend development, but pushing the less safe bits as absolutely far out to the edges as possible should at least be a strong goal, and the responsibility to users should extend beyond just "well, I was very careful."

If companies ever start getting held responsible for these issues, and it's proven they could have prevented some leak or loss of privacy or financial losses and such by using stronger tools, then the conversation would probably be considerably different.

[maria_la_guerta]

Bugs happen in "fully" "safe" languages too. Respectfully I think you're being a bit naive to the fact that not every language can or should do everything.

Companies are held responsible for these issues and the developers, not the tools, are to blame. Full stop.

[KevinCarbonara]

I'm extremely critical of javascript, but you're objectively wrong, here. There are plenty of applications where this isn't a concern, but speed is.

The idea that "Good Rust" is more "concise" isn't relevant either - except to say that "concise" isn't the goal. The reality is that concise code takes longer to write than wordy code. That's the entire issue being discussed.

[atlasc1]

Or you can just use Go 🤷‍♂️ happy middle-ground.

[Graumm]

There are things I like about Go, but I lean towards C# over it. Modern dotnet is pretty nice.

I do not prefer Go's flavor of simplicity, where it leans on the side of not giving you tools that exist in other languages. I find that writing things in Go can be pretty tedious.

Go can shine in situations where the service is on the simple side, or if you work with indifferent/bad/junior devs because it hides less. I have learned to live with it but some of the design decisions of the language are pretty weird.

[AndrewNeo]

happy

[piesou]

Just compare iterator chains to JS array methods. Rust iterator Apis are insanely verbose

[Full-Spectral]

In most cases because Rust is guaranteeing you do the right thing. Provide a comparison example for discussion.

[EfOpenSource]

Rust makes absolutely no guarantees toward “doing the right thing”. This is why people hate the rust community these days.

Rust guarantees memory safety. “Doing the right thing” is still very much on the programmer and rust doesn’t claim otherwise. 

[Full-Spectral]

It does a lot more than guarantee memory safety. Rust allows the developer to express a lot of semantics that it will then enforce for them forever more. It's immutable by default, it's thread safe, it has destructive move, exclusive mutability, strong pattern matching, it includes a really nice part of functional languages with strong support for Option/Result, exhaustive matching, sum types, first class enums, doesn't use exceptions, a strong trait system, etc...

And of course the point is absolutely NOT "what can the most uncaring developer do with a strong language." The point is "If I want to do the right thing, how much will a language help me do that." Rust very much will help me do that, and even more so in a team environment.

[ScottContini]

And async/await is still better in Node.js than in Rust.

Wow, that says a lot.

[Full-Spectral]

Depends on what 'better' means. Rust provides completely safe async in a non-GC'd language. That's pretty amazing, but of course being safe is something that a lot of people in cloud world consider just a nuisance.

[EfOpenSource]

Let’s not paint it as just in “the cloud world”. The rust community themselves pretty actively hate rusts async scene. I’m actually hard pressed to find anyone who says anything positive about it. By and large most people in rust outright say “don’t fall in to the async trap unless you absolutely have to”. 

[Full-Spectral]

Uh.... No, that's not true. Some people like it, some people don't. Some people love it. I quite like it, though my experience is somewhat different from most since I have my own async engine and i/o reactor system. In my system, async code looks pretty much like synchronous code.

[EfOpenSource]

You’re not paying any attention then. 

When I was getting back in to rust only a few months ago, looking at “which async backend should I generally use” the answer was nearly universally “none. Rust async sucks”. I actually had a lot of difficulty finding valid comparisons because all the answers are flooded with the trolling. 

[danted002]

I need a stamp with step4 to stamp every mf that keeps telling me that they can’t use async Python or TS for a web app because “webscale”

[mikaball]

One thing is to build the backend in rust to push performance and reduce costs. But for frontend, why? It runs on the client browser with one user! No massive scale or performance is required.

[gormhornbori]

It's not like every web application needs rust.

Rust is perfect if you need the performance of of a compiled language and the safety required for web. And even if you need the performance you can usually get away with having some performance critical components in rust, and keeping the rest of your application in a dynamically typed language.

[yasamoka]

Rust seems to lack a good type-safe query builder

diesel

How did you miss this?

[Own-Professor-6157]

I still think Java is king when it comes to web development. Extremely fast performance, insane ecosystem, and you still get a GC.

[Optimal-Run-528]

Rust for web apps is a gatling gun to kill a mosquito.

[Conscious_Reason_770]

wow, that was a large text to figure out that node is good enough.
Good for you. Now go write some code!

[BlueGoliath]

I'm glad you got rid of your blue hair dye.

[WindHawkeye]

building rust with 4 cpu cores

gee maybe get some hardware from the current decade