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

21–30 of 197 posts

Re: Farewell, Rust for web

#21

Post by incrudible »

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.

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 scope of dependencies.

Re: Farewell, Rust for web

#22

Post by mixmastamyk »

bryanlarsen wrote: post #20
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…

Python used to have a great standard library, too. But now it's stuck with a bunch of obsolete packages and the packaging story for Python is awful. In a decade or so Go the awkward things about Go will have multiplied significantly and it'll have many of the same problems Python currently has.

Lots of removals have already happened and uv took over packaging in Python-land.

Re: Farewell, Rust for web

#25

Post by NewJazz »

due 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.

Re: Farewell, Rust for web

#26

Post by __mharrison__ »

bryanlarsen wrote: post #20
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…

Python used to have a great standard library, too. But now it's stuck with a bunch of obsolete packages and the packaging story for Python is awful. In a decade or so Go the awkward things about Go will have multiplied significantly and it'll have many of the same problems Python currently has.

I just ported (this week) a 20-year-old Python app to uv/polars. (With AI it took two days). App is now 20x faster.

Re: Farewell, Rust for web

#28

Post by dwattttt »

incrudible wrote: post #21
tasn wrote: post #18

Earlier quoted context omitted.

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.

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…

> 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.

Re: Farewell, Rust for web

#30

Post by ChadNauseam »

resonious wrote: post #19
ChadNauseam wrote: post #15

Earlier quoted context omitted.

Running 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…

It 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...

The 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
Post reply on HN