Live data from Hacker News

Is Rust Ready for the Web Yet? (2020)

blog.devgenius.io

41–50 of 69 posts

Re: Is Rust Ready for the Web Yet? (2020)

#41

With all due respect does anyone else find Rust's syntax just horrible? #[get("/")] #[actix_web::main] std::io::Result HttpResponse::Ok().body("Hello world!") I mean, blegh! Anyway, just making conversation please don't take offense, some people think Ruby looks like ass.

As a sidenote to your sidenote: I've noticed that the term "syntax" seems to have two different meanings nowadays. There's the technical meaning, namely "the rules that govern how characters are parsed into abstract syntax tree nodes", which in your example, would cover whether Rust shoud use `.` or `::` as a namespace separator, whether to use `[]` or `` for generics, that sort of thing. (Both of which have trade-offs in constraining how other parts of the language can be designed.)

But I think sometimes, people use "syntax" in a blanket "how the language looks" way — that is, whether it's symbol-heavy, whether it's word-based, whether it's information-light or information-dense, and so on. This makes it more a function of which features of expressivity the language chooses to expose, than the individual syntactic choices that determine which characters we use and for what. Again in Rust's case, it has attributes, it has namespace separators, it has the zero-tuple, it has generics, and it has lifetimes, all of which need some way to be expressed.

Don't get me wrong, you're allowed to not use a language if you don't like the way it looks visually. Or maybe it makes good use of a certain character that's hard to type on your particular keyboard layout. That's fine. I also can't decree that either of these uses of the term "syntax" are wrong. But when we're talking about language syntax, it's important to remember when you're talking about syntax, and when you're instead talking about language features. If you don't like the way lifetimes look, that's one thing; if you don't like the way lifetimes make you change the way you write code, that's another.

So I have to ask: of those four code snippets, how would you prefer to write them? What would you change? And can you get away with making those changes without breaking anything else?

Re: Is Rust Ready for the Web Yet? (2020)

#42
post #29

Recently I wrote a simple forest fire simulation to test out using egui in WASM. I was impressed by how simple it was to get up and running. https://maxbondabe.github.io/forest-fire

This is not backend related though, WASM is just a binary that can be executed by the browser.

Re: Is Rust Ready for the Web Yet? (2020)

#43
post #41

With all due respect does anyone else find Rust's syntax just horrible? #[get("/")] #[actix_web::main] std::io::Result HttpResponse::Ok().body("Hello world!") I mean, blegh! Anyway, just making conversation please don't take offense, some people think Ruby looks like ass.

As a sidenote to your sidenote: I've noticed that the term "syntax" seems to have two different meanings nowadays. There's the technical meaning, namely "the rules that govern how characters are parsed into abstract syntax tree nodes", which in your example, would cover whether Rust shoud use `.` or `::` as a namespace separator, whether to use `[]` or ` ` for generics, that sort of thing. (Both of which have trade-o…

I have no idea how/why Rust works/looks the way it does. Never used it beyond a hello world. I just know it's syntax looks horrible to me. I can already imagine my pinky going sore typing all those characters.

Re: Is Rust Ready for the Web Yet? (2020)

#44
This is just a bad article. Yes it is ready and it's been for at least 2 years, we are building Caido (https://caido.io) entirely on rust from our proxy to the cloud backend and it is great. We use actix-web, diesel(proxy) / sea-orm(cloud), async-graphql. I don't want to go back to dynamically typed languages and no it's not like C++. It's a "Flask" level if you want a comparison but I absolutely hate Django (all frameworks really) so it is fine by me.

Re: Is Rust Ready for the Web Yet? (2020)

#45
post #36

Eh, HTTP with Rust is as fun as HTTP with C++. In both cases, there's people that swear they're very productive with it. I'm building an app powered by Rust, and I love it, but I'd rather use Elixir for the Web facing part. Perhaps when the whole async thing is more ergonomic I'll reconsider, but there is no chance any Rust framework can be as nice as any language running on the BEAM (or PHP, or Python, or Ruby, or G…

Lunatic runtime for Rust to avoid the async parts might become quite nice in the future: https://github.com/lunatic-solutions/submillisecond Not sure what it might take for someone to write database connectors for it but it does look promising.

Looks nice. But I'm not sure why the router needs to be a macro.

What's wrong with

    router.get("/foo", |req, res| -> Response {
      ...
    });

Re: Is Rust Ready for the Web Yet? (2020)

#46
post #14

Rust is pretty much the only language that runs well on all of front-end, back-end, iOS, Android, Windows & MacOS, with decent UI bindings. Javascript is the only real competition, but the needed shims are lossy at times. C++ is the closest, but Dioxus and Cacao are nicer than anything in the C++ ecosystem AFAICT. It's perhaps not the ideal language for any of those, but there's substantial benefit to having your who…

QT is still far ahead. This isn't a dig on Rust, but wherever Rust runs, so does C++. There are a lot of dimensions where Rust is better, but definitely not "runs everywhere" and "ecosystem".

Compare this demo: https://www.qt.io/web-assembly-example-pizza-shop?hsCtaTrack...

with this demo: https://github.com/DioxusLabs/example-projects/tree/master/e...

QT is unusably slow. Dioxus is indistinguishable from a Javascript app.

Re: Is Rust Ready for the Web Yet? (2020)

#47

Rust is pretty much the only language that runs well on all of front-end, back-end, iOS, Android, Windows & MacOS, with decent UI bindings. Javascript is the only real competition, but the needed shims are lossy at times. C++ is the closest, but Dioxus and Cacao are nicer than anything in the C++ ecosystem AFAICT. It's perhaps not the ideal language for any of those, but there's substantial benefit to having your who…

Runs well in a browser, with ergonomic integration with HTML, CSS, and other browser APIs?

Yes, check out Dioxus, which is essentially React for Rust, and is faster than react at many tasks.

Re: Is Rust Ready for the Web Yet? (2020)

#48

Rust is pretty much the only language that runs well on all of front-end, back-end, iOS, Android, Windows & MacOS, with decent UI bindings. Javascript is the only real competition, but the needed shims are lossy at times. C++ is the closest, but Dioxus and Cacao are nicer than anything in the C++ ecosystem AFAICT. It's perhaps not the ideal language for any of those, but there's substantial benefit to having your who…

Java?

Re: Is Rust Ready for the Web Yet? (2020)

#49
Are there really that many use cases in web development where you absolutely can not live with just using a language with automatic garbage collection?

I can see maybe using Rust for some performance critical parts but for the daily CRUD or API? I don't get how you could justify using it. (In a professional context that is, if it's just for fun, go ahead, of course.)

There are so many amazing backend-languages with huge ecosystems be it Elixir, PHP, Golang, Node or whatever you favorite poison may be. You would miss out on so much productivity.

Rust is amazing but it solves a very specific problem while most of the software world is better off using garbage collected languages.

Re: Is Rust Ready for the Web Yet? (2020)

#50
post #36

Eh, HTTP with Rust is as fun as HTTP with C++. In both cases, there's people that swear they're very productive with it. I'm building an app powered by Rust, and I love it, but I'd rather use Elixir for the Web facing part. Perhaps when the whole async thing is more ergonomic I'll reconsider, but there is no chance any Rust framework can be as nice as any language running on the BEAM (or PHP, or Python, or Ruby, or G…

I'm curious, are there any specific parts of the stack that make backend dev harder for you? My experience with async Rust on the backend is that it doesn't really slow me down too much, cause most of the problems are not really relevant there. Functions handling requests are usually of a form: get request data, fetch sth from the database, return a response. In this context you don't really need to care too much about async, lifetimes, ownership etc.
Post reply on HN