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

141–150 of 197 posts

Re: Farewell, Rust for web

#141

Post by Ferret7446 »

TheDong wrote: post #44
incrudible wrote: post #21

Earlier quoted context omitted.

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…

Which has been working great for go, right. They shipped "log" and "flag" stdlib packages, so everyone uses... well, not those. I think "logrus" and "zap" are probably the most popular, but there's a ton of fragmentation in Go because of the crappy log package, including Go itself now shipping two logging packages in the stdlib ('log/slog'). Rust on the other hand has "log" as a clear winner, and significantly less o…

I think you underestimate how many programs use log and flag, if you just focus on the few (bloated) popular projects.

Re: Farewell, Rust for web

#142

Post by GuB-42 »

slopinthebag wrote: post #51
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…

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…

It is more of a cultural thing. Package managers encourage lots of dependencies while programmers using language with no package managers will often pride themselves in having as few dependencies as possible. when you consider the complete graph, it has an exponential effect.

It is also common in languages without package managers to rely on the distro to provide the package, which adds a level of scrutiny.

Re: Farewell, Rust for web

#143

Post by kcexn »

slopinthebag wrote: post #51
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…

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…

Technically it's the same. But behaviorally it's not. When pulling in more dependencies is so easy, it's very hard to slow down and ask the question do we need all of this?

Mucking around with cmake adds enough friction that everyone can take a beat for thoughtful decision-making.

Re: Farewell, Rust for web

#144

Post by jmalicki »

jmalicki wrote: post #134
wofo wrote: post #126

Earlier quoted context omitted.

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

I love Diesel for ORMs - it's very much in the same spirit as a type safe sqlalchemy, so it depends if you like that. The type safety is a great feature, it always saves me from writing incorrect queries (a huge one is nullability is represented as an option, so nullability mismatches are caught very early). It has an async version that is not as well maintained so it does lag behind, but I've never had an issue with…

Upon reflection, my comfort with sqlalchemy, diesel, C++ STL, and vibe coding all share one thing in common - I am pretty comfortable liking to code at a high level that is productive, while at the same time going deep to know what the abstractions produce under the covers. E.g. I at least spot check my vibe coded code, I spot check the assembly from C++ STL to ensure zero cost abstraction, I spot check the SQL from sqlalchemy or Diesel.

I am thinking a lot of people are not comfortable with this.

Personally, super high level abstractions where I do know what ultimately results is personally what I want to be productive - so this may color my love of Rust, vibe coding, and Diesel.

Re: Farewell, Rust for web

#145

Post by Rohansi »

anon-3988 wrote: post #127
totally-a-human wrote: post #124

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

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

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

Re: Farewell, Rust for web

#146

Post by danny_codes »

anon-3988 wrote: post #127
totally-a-human wrote: post #124

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

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

Typescript has static typing. It’s called typescript..

Re: Farewell, Rust for web

#147

Post by pstuart »

Ygg2 wrote: post #91
pstuart wrote: post #76

Earlier quoted context omitted.

With Go it's good to keep in mind the Proverbs, which includes this gem: A little copying is better than a little dependency.

Good luck, if little copying is ICU based localization.

The whole point of "a little copying" is when there's self-contained code that can be copypasta'd -- for situations that are appropriate.

Re: Farewell, Rust for web

#148

Post by Ygg2 »

ajross wrote: post #132
lesuorac wrote: post #130

Earlier quoted context omitted.

I mean somebody could make a singular rust dependency that re-packages all of the language team's packages. But what's the threat model here. Does it matter that the Rust STD library doesn't expose say "Regex" functionality forcing you to depend on Regex [1] which is also written by the same people who write the STD library [2]? Like if they wanted to add a back-door in to Regex they could add a backdoor into Vec. Pe…

> I mean somebody could make a singular rust dependency that re-packages all of the language team's packages. That's not the requirement though! Curation isn't about packaging, it's about independent (!) audit/test/integration/validation paths that provide a backstop to the upstream maintainers going bonkers. > But what's the threat model here. A repeat of the xz-utils fiasco, more or less precisely. This was a succe…

> A repeat of the xz-utils fiasco

Wasn't that a suspected state actor? Against that threat model your best course of action is a prayer and some incense.

Notably, xz utils didn't use any package manager ala NPM and it relied on package management by hand.

> because the downstream Debian folks

Not sure what you mean by this, but this was discovered by a Postgres dev running bleeding edge Debian. No Debian package maintainer noticed this.

> There's no Debian equivalent

How would Debian approach help? Not even their maintainers could sniff this one.

There exists a sort of extended std library of Rust dep. But no one is using it.

Re: Farewell, Rust for web

#149

Post by skwee357 »

eYrKEC2 wrote: post #29

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

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

Re: Farewell, Rust for web

#150

Post by Dylan16807 »

zem wrote: post #113
mr_00ff00 wrote: post #109

Earlier quoted context omitted.

So is Markdown a programming language? Any logic for html, is therefore Markdown as well.

sure, it's a dsl for generating formatted output

If 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?

Post reply on HN