Live data from Hacker News

Farewell, Rust for web

yieldcode.blog

71–80 of 197 posts

Re: Farewell, Rust for web

#71

It'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 n…

How would one do an if condition or enumerate a list in HTML alone? For that functionality you need another language to generate/manipulate the HTML.. not to mention interpreting HTML for display.

HTML is a markup language, it's even in the name... but it's not a complete programming language by any stretch.

Re: Farewell, Rust for web

#72
post #32

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

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

Lisp is the master of all. Or it would be except "Parens? Eugh! Brotha, eugh!"

Re: Farewell, Rust for web

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

I think the big thing keeping Blazor back is that C# doesn't work well with WASM. It was built at a time when JIT-optimized languages with a larger runtime were in-vogue. That's fine in a lot of cases, but it means that C# isn't well suited for shipping a small amount of code over the wire to browsers. A Blazor payload is going to end up being over 4MB. If you use ahead of time compilation, that can balloon to 3x more. The fact that C# offers internal pointers makes it incompatible with the current WASM GC implementation.

Blazor performance is around 3x slower than React, it'll use 15-20x more RAM, and it's 20x larger over the wire. I think if Blazor could match React performance, it'd be quite popular. As it stands, it's hard to seriously consider it for something where users have other options.

Microsoft has been working to make C#/.NET better for AOT compilation, but it's tough. Java has been going through this too. I don't really know what state it's at, but (for example) when you have a lot of libraries doing runtime code generation, that's fine when you have a JIT compiler running the program. Any new code generated at runtime can be run and optimized like any other code that it's running.

People do underappreciate the JS/TS ecosystem, but I think there are other reasons holding back stuff running on WASM. With Blazor, performance, memory usage, and payload size are big issues. With Flutter and Compose Multiplatform, neither is giving you a normal HTML page and instead just renders onto a canvas. With Rust, projects like Dioxus are small and relatively new. And before WASM GC and the shared heap, there was always more overhead for anything doing DOM stuff. WASM GC is also pretty new - it's only been a little over a year since all the major browsers supported it. We're really in the infancy of other languages in the browser.

Re: Farewell, Rust for web

#74

As 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. F…

I think this is spot on. I've used Iced and Dioxus and both are great. I do take the author's point that the actual UI code, even in Dioxus, is verbose. It is. And that's a trade off I'm willing to make for guaranteed correctness.

I haven't used Iced but re. Dioxus, I don't know if it's necessary more verbose conceptually. One of the most frustrating things with React is handling async updates, and while Rust's async story is conceptually difficult, it's ultimately much easier to reason about (imo). Like are we sure a comparable component in React would be any less verbose?

   let mut breed = use_signal(|| "hound".to_string());

   let dogs = use_resource(move || async move {
     reqwest::Client::new()
       .get(format!("https://dog.ceo/api/breed/{breed}/images"))
       .send()
       .await?
       .json::()
       .await
   });

   rsx! {
     input {
       value: "{breed}",
       oninput: move |e| breed.set(e.value()),
     }

     div {
       display: "flex",
       flex_direction: "row",
       if let Some(response) = &*dogs.read() {
         match response {
           Ok(urls) => rsx! {
             for image in urls.iter().take(3) {
               img {
                 src: "{image}",
                 width: "100px",
                 height: "100px",
               }
             }
           },
           Err(err) => rsx! { "Failed to fetch response: {err}" },
         }
       } else {
         "Loading..."
       }
     }
   }
Imo the RSX here is much less verbose than JSX. Inline match statement, inline if statement, inline for loop, .take(3) compared to `Array.from({ length: 3 }).map((_, i) => urls[i]))`, etc etc. This gives you automatic cancellation of the future, whereas with React you would need a third party library like React Query, and then manually abort requests in the asynchronous function with an abort signal -- in Rust, you get that for free. You also get data validation for free, instead of needing eg. Zod for manual runtime validation.

Re: Farewell, Rust for web

#75
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?

Good to know! You probably saved me a lot of pain.

Re: Farewell, Rust for web

#76

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…

With Go it's good to keep in mind the Proverbs, which includes this gem:

  A little copying is better than a little dependency.

Re: Farewell, Rust for web

#77

Earlier quoted context omitted.

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

That's fair and makes sense. In my case it was just a regular web app where the only reason for it being in Rust was that I like the language.

Re: Farewell, Rust for web

#78
post #64

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…

The tradeoff Go made is that certain code just cannot be written in it. Its STD exists because Go is a language built around a "good enough" philosophy, and it gets painful once you leave that path.

[deleted]

Re: Farewell, Rust for web

#79
post #59

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…

The dependency creep keeps on happening in web frameworks where ever you look. I was thinking of this quote from the article: > Take it or leave it, but the web is dynamic by nature. Most of the work is serializing and deserializing data between different systems, be it a database, Redis, external APIs, or template engines. Rust has one of the best (de)serialization libraries in my opinion: serde. And yet, due to the…

Rust has trouble supporting higher-kinded types like Functor (even though an equivalent feature is available, namely Generic Associated Types) due to the distinctions it makes between owned and referenced data that have no equivalent in Haskell. Whether these higher abstractions can still be used elegantly despite that complexity is something that should be explored via research, this whole area is not ready for feature development.

Re: Farewell, Rust for web

#80
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 all have their unique pain points that it doesn't seem at all crazy?

Post reply on HN