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

111–120 of 197 posts

Re: Farewell, Rust for web

#111

Post by himata4113 »

pjerem wrote: post #88
slopinthebag wrote: post #51

Earlier quoted context omitted.

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

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

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

Re: Farewell, Rust for web

#112

Post by spartanatreyu »

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…

FYI: Deno includes:

1. The web standard APIs themselves 2. It's own standard library inspired by Go's standard library (plus some niceties like TOML minus some things not wanted in a JS/TS standard library since they're already in the web standard APIs) 3. Node's standard library (AKA: built-in modules) to maintain backwards compatibility with node.

Bun has 1 and 3, and sort of has it's own version of 2 (haphazard, not inspired by go, and full of bun-isms which you may like but may not, but standard database drivers is nice).

Re: Farewell, Rust for web

#114

Post by Grimburger »

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…

A Tauri hello world app has about 500(?) deps out of the box, always makes me laugh.

I get that cross platform desktop app is a complicated beast but it gives off those creepy npm vibes.

Re: Farewell, Rust for web

#115

Post by lukaszkorecki »

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

Earlier quoted context omitted.

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

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

It has one - it’s been a part of the JDK for a while https://docs.oracle.com/en/java/javase/11/docs/api/jdk.https...

Re: Farewell, Rust for web

#117

Post by ceteia »

TheDong wrote: post #41
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…

I've found Go's standard library to be really unfortunate compared to rust. When I update the rust compiler, I do so with very little fear. My code will still work. The rust stdlib backwards compatible story has been very solid. Updating the Go compiler, I also get a new stdlib, and suddenly I get a bunch of TLS version deprecation, implicit http2 upgrades, and all sorts of new runtime errors which break my applicati…

> When I update the rust compiler, I do so with very little fear. My code will still work. The rust stdlib backwards compatible story has been very solid.

This is not always true, as seen with rustc 1.80 and the time crate. While it only changed type inference, that still caused some projects like Nix a lot of trouble.

Re: Farewell, Rust for web

#118

Post by rtpg »

wofo wrote: post #33

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

I think there's a couple stories of people shipping some performant "webapp"-y stuff in Rust... but of course you can just compile those kinds of components and write the rest of your app in any other system

Re: Farewell, Rust for web

#119

Post by rtpg »

papa0101 wrote: post #55
fuddle wrote: post #9

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

React and its ecosystem is a pile of garbage perpetuated by industry inertia. UseState, useMemo, useThisAndThat where you have to guess whether that dependency will cause a re-render? Or 20 different routers, state managers, query builders? I'm not even talking about html-in-ts with `!!a && ( ... )` A stodgy, bloated, overhyped and misused monstrosity, that's what React is.

useMemo is definitely a scourge on my existence. Doesn't help that a bunch of people write articles like "don't bother with it!!" when memoisation results can cause actual real bugs when integrating with a third party lib.

Unmounting and then remounting the same component is actually a bad thing when you lose your component state in the process. And when you have enough useEffect's in your system that's exactly what happens unless you're liberally sprinkling useMemo

Re: Farewell, Rust for web

#120

Post by rtpg »

socalgal2 wrote: post #46
throw-the-towel wrote: post #11

Earlier quoted context omitted.

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

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

The thing you gotta make sure to do is basically return inside of switch statements. Typescript will gladly propagate a type that you think is never but is actually ThatOneCaseYouForgot if it's not ever used or referred to.

Every TS project I've worked on has an assertNever(val) thing specifically to check for this kinda stuff

Post reply on HN