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

131–140 of 197 posts

Re: Farewell, Rust for web

#131

Post by lesuorac »

wofo wrote: post #126
jmalicki wrote: post #80

Earlier quoted context omitted.

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…

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…

Also curious about their opinion.

I've over the years began to interface with a lot of PHP code and there's a lot of really neat configuration stuff you can do. Ex. creating different pools for the incoming requests (so logged out users or slow pages are handled by the same pool). Like it seems to me for all of the rust web servers you have to still do a lot of stuff all on your own through code and it's not like you can create an existing Pool-ing struct.

Re: Farewell, Rust for web

#132

Post by ajross »

lesuorac wrote: post #130
ajross wrote: post #101

Earlier quoted context omitted.

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

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 successful supply chain attack that was stopped because the downstream Debian folks noticed some odd performance numbers and started digging.

There's no Debian equivalent in the soup of Cargo dependencies. That mistake has bitten NPM repeatedly already, and the reckoning is coming for Rust too.

Re: Farewell, Rust for web

#133

Post by skydhash »

rtpg wrote: post #119
papa0101 wrote: post #55

Earlier quoted context omitted.

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…

React is opinionated. The whole point of the library is having UI updates being driven by state mutation. When I hear complain about the hooks, I ask about what is the state, and where do mutations occur, and usually, I get blank stares in returns.

It's all about the state. `useState` is the starting point (adding new items to the state set), `useEffect` for tying the UI to external systems, `useMemo` for state transformation, `useRef` for storing stuff outside of the state you want to react to,... Then you use custom hooks to make the code modular, stuff like usePost, useProfile, useCommentUpvote,... (HN domain)

If you design your state well, the application, at least the UI layer, becomes easy to code and maintain.

Re: Farewell, Rust for web

#134

Post by jmalicki »

wofo wrote: post #126
jmalicki wrote: post #80

Earlier quoted context omitted.

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…

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 it. To me personally, the Diesel ORM is the #1 reason to be using Rust for a web backend - it has saved me so much pain from having db/model mismatches since they're caught early.

The only other thing I've heard that is close in any language is C#/F# LINQ (I mean I'm sure there's random other projects, but haven't talked to other people about actually deploying backends with similarly type safe ORMs other than that).

There is axum OpenAPI at https://docs.rs/axum-openapi3/latest/axum_openapi3/, I haven't personally used it, I've mostly been doing GraphQL which I find works very well (including the N+1 problem etc).

And of course, I personally find cargo and the dependencies there to be roughly as ergonomic as python. Its dependency ecosystem for web isn't as deep as python or node.js, but it's pretty solid IMO. It may not have downloadable clients for a lot of pre-existing OpenAPIs etc., but that's also something Claude can port in 5 minutes.

Re: Farewell, Rust for web

#135

Post by jmalicki »

lesuorac wrote: post #131
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…

Also curious about their opinion. I've over the years began to interface with a lot of PHP code and there's a lot of really neat configuration stuff you can do. Ex. creating different pools for the incoming requests (so logged out users or slow pages are handled by the same pool). Like it seems to me for all of the rust web servers you have to still do a lot of stuff all on your own through code and it's not like you…

I don't think it probably helps with a lot of the super easy stuff like creating a pool with a line of configuration - fair!

I (personally) would rather spend the fixed several hours of doing a few things like that manually, vs. pounding my head on the desk for impossible-to-find bugs.

Re: Farewell, Rust for web

#136

Post by Paul-E »

pie_flavor wrote: post #108
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.

When queries get complicated enough, you end up writing a custom query builder to build your SQL.

Ceci n'est pas une pipe

Re: Farewell, Rust for web

#137

Post by bsder »

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

Lisp lost because none the the Lisperati came down from on high and deigned to explain how to use it for tasks running on the 1980s microcomputers.

Lisp also lost because the 1980s Lisperati spent all their time explaining lists and recursion over and over instead of explaining hash tables, vectors, and iteration.

Somehow, Lisp lost out to pathetically slow BASIC interpreters and C compilers that you had to swap floppies continuously for hours. That is a stunning level of fail.

Re: Farewell, Rust for web

#138

Post by TheDong »

ceteia wrote: post #117
TheDong wrote: post #41

Earlier quoted context omitted.

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.

That caused compilation errors though, which are alright in my book, and don't increase my fear to update.

Silent runtime changes are what spook me and what I've gotten more often with Go.

Re: Farewell, Rust for web

#139

Post by jmalicki »

wofo wrote: post #126
jmalicki wrote: post #80

Earlier quoted context omitted.

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…

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…

> batteries-included

Rust tends to have more of the model of small packages that do one thing rather than monolithic frameworks.

e.g. as in the sibling comment, if you want openAPI you install axum-openapi, rather than being included in the framework.

Re: Farewell, Rust for web

#140

Post by IcyWindows »

bilbo0s wrote: post #125
himata4113 wrote: post #111

Earlier quoted context omitted.

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.

java didn't have an http client [...] and STILL doesn't have an http server. Wow. How long has it been since you guys have used Java? Serious question?

When I run into things like this that I know are wrong, I try to remember when reading things I don't know about...
Post reply on HN