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

181–190 of 197 posts

Re: Farewell, Rust for web

#181

Post by SPBS »

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.

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

The stdlib packages are far better designed in Go than in Python. “The standard library is where packages go to die” is literally not a thing in Go, in fact quite the opposite.

Re: Farewell, Rust for web

#182

Post by bryanlarsen »

SPBS wrote: post #181
bryanlarsen wrote: post #20

Earlier quoted context omitted.

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.

> 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. The stdlib packages are far better designed in Go than in Python. “The standard library is where packages go to die” is literally not a thing in Go, in fact quite the opposite.

So far. But Google's in charge, and Google is the place where things go to die.

Re: Farewell, Rust for web

#183

Post by bryanlarsen »

bitwize wrote: post #72
bryanlarsen wrote: post #61

Earlier quoted context omitted.

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!"

There are lots of places where Lisp is unsuitable. I wouldn't use it for real-time control, for instance. Works great for orchestrating real-time controls though.

Re: Farewell, Rust for web

#184

Post by Dylan16807 »

andrewaylett wrote: post #169
imtringued wrote: post #160

Earlier quoted context omitted.

So any text file is a programming language?

I would say that a "language" is a necessary component of a "programming language". An empty file was an IOCCC winner: https://www.ioccc.org/1994/smr/ but you need to interpret that empty file as C source in order to reasonably claim to have programmed the computer. My reasoning comes more from the other direction: someone who writes HTML is programming therefore HTML is a programming language.

Can you give a clearer definition of when a person "is programming"?

Your earlier definition talked about giving the computer a capability, but that capability just seemed to be displaying a specific file?

Where is the cutoff on the line from HTML to markdown to ASCII? (noting that ASCII uses control codes that trigger special behavior)

Re: Farewell, Rust for web

#185

Post by Kinrany »

riku_iki wrote: post #180
Kinrany wrote: post #162

Earlier quoted context omitted.

What's a better alternative for shared types? OpenAPI is really outdated and the tooling is always a mess. There is ts-rs [1], but it's only for TS. [1]: https://docs.rs/ts-rs/latest/ts_rs/

protobufs?

When serialized as JSON perhaps. Being able to inspect payloads in the browser is too convenient.

Re: Farewell, Rust for web

#186

Post by ChadNauseam »

tcfhgj wrote: post #93
ChadNauseam wrote: post #30

Earlier quoted context omitted.

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

the JS layer is slow, indeed, but it shouldn't be that much slower that it meaningfully impacts frontend apps A demonstration of that by the creator of Leptos: https://www.youtube.com/watch?v=4KtotxNAwME

Fascinating video, thanks for sharing.

Re: Farewell, Rust for web

#187

Post by Ygg2 »

ajross wrote: post #173
Ygg2 wrote: post #148

Earlier quoted context omitted.

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

> Wasn't that a suspected state actor? Against that threat model your best course of action is a prayer and some incense. No? They caught it! But they did so because the software had extensive downstream (!) integration and validation sitting between the users and authors. xz-utils pushed backdoored software, but Fedora and Debian picked it up only in rawhide/testing and found the issue. > Notably, xz utils didn't us…

> No? They caught it!

No? Who else has 2-3 years worth of time to become a contributior and maintainer for obscure OSS utils?

Plus made sockpuppets to put pressure on OG maintainer to give Jia Tan maintainer privilege.

> Exactly. Not sure how you think this makes the point different. Everything in Debian is volunteer, the fact that people do other stuff is a bonus.

What you mean exactly? This isn't curation working as intended. This is some random dev discovering it by chance. While it snuck past maintainers and curator of both Debian and Red Hat.

> Everything in Debian is volunteer, the fact that people do other stuff is a bonus. Point is the debian community is immunized against malicious software because everyone is working on validation downstream of the authors.

You can do same in NPM and Cargo. Release a v1.x.y-rc0, give everyone a trial run, see if anyone complains. If they do, it's downstream validation working as intended.

Then yank RC version and publish a non-RC version. No one is preventing anyone from making their release candidate version.

> No one does that for NPM. There is no Cargo Rawhide or NPM Testing

Because, it makes no more sense to have Cargo Rawhide than to have XZ utils SID.

Cargo isn't an integration point, it's infra.

Bevy, which integrates many different libs, has a Release Candidate. But a TOML/XYZ library it uses doesn't.

Re: Farewell, Rust for web

#188

Post by anon-3988 »

danny_codes wrote: post #146
anon-3988 wrote: post #127

Earlier quoted context omitted.

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

Well, I prefer one that does not let me get off free and have a gaping escape hatch.

Re: Farewell, Rust for web

#189

Post by danny_codes »

anon-3988 wrote: post #188
danny_codes wrote: post #146

Earlier quoted context omitted.

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

Well, I prefer one that does not let me get off free and have a gaping escape hatch.

It’s like 2 lines in tsconfig to eliminate any escape hatch. Though it’s probably not worth doing in most cases.

Re: Farewell, Rust for web

#190

Post by [deleted] »

Rohansi wrote: post #145
anon-3988 wrote: post #127

Earlier quoted context omitted.

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

[deleted]
Post reply on HN