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

101–110 of 197 posts

Re: Farewell, Rust for web

#101

Post by ajross »

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…

> Those deps have to come from somewhere, right? Unless you're actually rolling your own everything

The point is someone needs to curate those "deps". It's not about rolling your own, it's about pulling standard stuff from standard places where you have some hope that smart people have given thought to how to audit, test, package, integrate and maintain the "deps".

NPM and Cargo and PyPI all have this disease (to be fair NPM has it much worse) where it's expected that this is all just the job of some magical Original Author and it's not anyone's business to try to decide for middleware what they want to rely on. And that way lies surprising bugs, version hell, and eventually supply chain attacks.

The curation step is a critical piece of infrastructure: thing things like the Linux maintainer hierarchy, C++ Boost, Linux distro package systems, or in its original conception the Apache Foundation (though they've sort of lost the plot in recent years). You can pull from those sources, get lots of great software with attested (!) authorship, and be really quite certain (not 100%, but close) that something in the middle hasn't been sold to Chinese Intelligence.

But the Darwinian soup of Dueling Language Platforms all think they can short circuit that process (because they're in a mad evangelical rush to get more users) and still ship good stuff. They can't.

Re: Farewell, Rust for web

#102

Post by ajross »

Mond_ wrote: post #64
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…

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.

> The tradeoff Go made is that certain code just cannot be written in it.

Uh... yeah? That's true of basically all platforms, and anyone who says otherwise is selling something.

> it gets painful once you leave that path

Still less painful than being zero-day'd by a supply chain attack.

Re: Farewell, Rust for web

#103

Post by sroerick »

cyberax wrote: 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 feel like it was less than a year ago that Typescript was basically the only game in town and if you liked anything else you were a loon.

I have been an anti Typescript guy for a long time but I wouldn't deny for a moment that it's probably by far the most mature ecosystem.

Re: Farewell, Rust for web

#104

Post by robinsonb5 »

xnyan wrote: post #86
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.

> the packaging story for Python is awful. Big caveat that this is just for me personally, but uv has fixed this for me personally. Game changing improvement for Python. Appropriately, uv is written in rust.

The fact that you have to know to use uv rather than any of the other package managers is kind of the point.

Re: Farewell, Rust for web

#106

Post by itishappy »

__mharrison__ wrote: post #26
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.

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.

that's polars for ya

uv should not impact runtime performance at all

Re: Farewell, Rust for web

#108

Post by pie_flavor »

Paul-E wrote: post #8

I want to address this one point: > Similar thing can be said about writing SQL. I was really happy with using sqlx, which is a crate for compile-time checked SQL queries. By relying on macros in Rust, sqlx would execute the query against a real database instance in order to make sure that your query is valid, and the mappings are correct. However, writing dynamic queries with sqlx is a PITA, as you can’t build a dyn…

You appear to have entirely confused sqlx and diesel. You don't 'feel like' you're writing SQL in sqlx, you are writing SQL in sqlx.

Re: Farewell, Rust for web

#109

Post by mr_00ff00 »

zem wrote: post #52
andrewaylett wrote: post #47

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…

agreed, it's a hill i am very willing to die on too.

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

Re: Farewell, Rust for web

#110

Post by pie_flavor »

andrewaylett wrote: post #47

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…

HTML requires you to understand symbolic representations, where means something special. It is more verbose, but no more structurally complex, than Markdown. It does not require you to understand imperative dynamic logic. Getting the hang of symbolic representations is easy, and getting the hang of imperative programming is very hard and most people can't do it. That's why the dividing line is where it is. Making a static bulleted list isn't a 'capability' in HTML if you weren't thinking it was one in Markdown, and inventing your own precisely crafted definition with no purpose other than to include HTML then calling all others unreasonable doesn't convince anyone.
Post reply on HN