Hacker News Reader

Comment by xavxav | Hacker News Reader

> Is the Async crew mostly writing web servers and other things that operate using TCP and HTTP? Lower level (eg IP, Eth, network hardware drivers) isn't well supported by rust libs. Nor is higher - we have Flask analogs, but no Django analogs.

Something I have never understood is why people want to write web-apps in Rust. I love the language, but honestly, a managed language (like js/ruby/go) is always going to be better suited to the world of web-apps.

I feel like this imposes an undue burden on Rust to do everything for everyone which has to break down somewhere

View on HN

For me, I’m currently running a Rust webapp and a Python webapp on a server; both are of similar complexities, and I’m probably a bit better at Python. I keep on having to fix the Python app, because of both OS upgrades and problems with the implementation. The Rust app has been working without any issues for the last three years.

For a relatively simple web server, where I don’t need to collaborate with anyone, I’m choosing Rust.

I've got a similar thing. I wrote a bespoke time-series database in Rust a few years ago, and it has had exactly one issue since I stood it up in production, and that was due to pessimistic filesystem access patterns, rather than the language. This thing is handling hundreds of thousands of inserts per second, and it's even threaded.

Given that I've been programming professionally for over a decade in Python, Perl, Ruby, C, C++, Javascript, Java, and Rust, I'll pick Rust absolutely any time that I want something running that I won't get called at 3 AM to fix. It probably took me 5 times as long to write it as if I did it in Go or Python, but I guarantee it's saved me 10 times as much time I would have otherwise spent triaging, debugging, and running disaster recovery.

The answer to this question is often one of a few different things: reliability (“we didn’t touch our service for 18 months after deployment and it never ran into issues”), low resource usage (“we decommissioned X servers which saves us $Y/year”), and high performance are common responses.

Isn't Go pretty close to optimal here, though? C/Rust may use somewhat fewer resources, but when you look at Go's efficiency over, say, scripted languages like Python, Ruby, or JavaScript, further optimization seems like it's gilding the lily.

For most use cases, I agree.

But Rust is a better option when you also need one or more of the following:

a) tight control over allocations

b) deterministic performance

c) strong data race protection

d) zero overhead C interop (e.g., processing audio using ffmpeg)

It depends on what you mean by “optimal.” For many cases, sure, it’s not an issue, but Go has a big runtime that needs to exist. And its expectations mean that C FFI is not zero overhead, which is why you see so many pure Go packages, but isn’t appropriate in many of Rust’s use cases, which require zero overhead.

I agree - however, once you cross the border into C linkage/FFI, you’re losing both Go’s and Rust’s safety features. That seems like a wash to me. Besides, people are doing a splendid job writing pure Go libraries. It helps that Go has some fantastic observability tooling to help performance-minded engineers minimize unnecessary heap allocations.

Finally, the Go runtime just isn’t that big. A few megabytes, I think. That’s well below the noise floor for most server environments, and it’s far smaller than, say, a Python or Java runtime.

Yes, you're not wrong. I have gotten some threads crossed; I forgot this one is about the server side context. Yes, these sorts of things are often less of an issue than in other contexts.

Sometimes it still matters though. Just really depends on what you're doing.

FYSA I upvoted this for teaching me that cool and useful expression!

>Something I have never understood is why people want to write web-apps in Rust.

The vast, vast majority of web apps are the same CRUD endpoints and background job queue processing. I would label Rust as mature enough in this regard; I've written quite a few of these and am not left wanting in any regard (short of a clone of Django's automagic admin, but few things get close to this anyway...).

When you accept the fact that you're taking in some data, shoving it into the DB, and returning a response, the rest of the Rust ecosystem becomes pretty damn nice - deployment is an absolute breeze compared to some of the other ecosystems (Ruby/Python). I don't need to mess with Docker, I don't need to deal with broken package managers, I can just replace a binary and call restart.

It's amazing.

Common things webapps use that Rust frameworks don't provide:

  - High-level DB migrations
  - Auth
  - Email
  - Admin
  - Templating

You get these immediately with eg Django, but not in Rust. I'm not trying to be contrarian; I'm confused, and have never heard an answer about this point.

No worries, I don't think you're being contrarian - I think projects that properly do this stuff have trouble rising above the micro-framework-style projects.

https://github.com/secretkeysio/jelly-actix-web-starter

I put all of this together some time ago, explicitly modeled after Django. This repo isn't up to date with actix-web 4 as I've been too busy with other (paying) work, but it absolutely exists. I've used this for services in production with no issues. I really do need to get time to finish and push the updates though.

Mine isn't even the first, I'm pretty sure there are others working in this space. Just needs the right people pushing it.

Oh wow! Very appropriate. Looking forward to seeing this fleshed out when you get more time. Will give it a shot on my next project.

People can be wary of these bolts-included/on-rails solutions because there is typically hell to be paid as soon as you venture slightly off of the rails. If not, they also tend to have an overabundance of features; leading to slowness or a fertile ground for vulnerabilities.

> High-level DB migrations

Having used Datadude[1] I can say for certain that there are few approaches worse than migrations. The problem is that, once you are stuck with a turn-key framework, you are completely stuck with their approach (which is usually horribly archaic).

Unbundling all of these things might require more work up-front, but can result in significantly improved productivity in the long run.

[1]: https://www.sqlshack.com/working-with-database-projects/

> People can be wary of these bolts-included/on-rails solutions because there is typically hell to be paid as soon as you venture slightly off of the rails

This is so very often the case, and you often can't tell in advance before you use the framework or library or whatever. You just have to use it, and get to a certain point of maturity in your project before you discover these limits.

I was reminded of Rust on Nails [0], which i found here [1].

[0] https://cloak.software/blog/rust-on-nails/

[1] https://github.com/tokio-rs/axum/blob/main/ECOSYSTEM.md#proj...

Better suited in what way? I've written HTTP APIs in all of the above - plus Python and PHP - and choose Rust for new ones 99% of the time.

Just recently I had a need for a fairly simple webapp. Whipped up the back end in Rust in, like, an hour; only had to bolt on a couple tests for the single complex bit of business logic, because I have a high degree of confidence that the compiler has me covered for everything else.

Now it sits there quietly using 4.9 MiB of physical memory and 1.5 millicores on two of my servers, primarily serving a k8s healthcheck every couple seconds.

If you accept the divide between back-end and front-end (and the need to have separate developers for each), this is fine. But I, for one, prefer full-stack server-side frameworks such as Rails, Django, and Phoenix, where the server side does HTML generation, HTML form processing (with CSRF protection), authentication with session cookies, etc. Bonus points if, like Phoenix or ASP.NET Core, the framework has integrated support for real-time applications using WebSockets. AFAIK, Rust doesn't have anything quite this comprehensive, though such a framework could certainly be developed.

Nope, as far as I know there's no serverside HTML generation crate. Granted, I haven't looked, but I feel like it would have come up on /r/Rust sometime.

Everything else you mentioned is out there, although I didn't love the websocket experience the one time I needed them for something.

Most rust web frameworks are server side, and generate HTML, so I’m not sure what you were looking at, but it absolutely exists. Most rust web stuff is server side generated.

Sure, obviously you can generate strings containing HTML and send those. I'm imagining something like the serverside rendering you get with e.g. React. That said, I don't know what specifically the previous poster was looking for.

I'm a bit confused, what's the difference? SSR React also ends up "generating strings containing HTML and sending those."

I don't really know what you mean by serverside HTML generation crate. HTML is just HTML. What I usually need is some templating system, and that can be used to produce HTML, SQL, or whatever else I want.

Use askama or tera, for example. Here's an example of using askama with axum: https://github.com/djc/askama/tree/main/askama_axum

If you mean something more significant, like what an ORM/query builder is to SQL, then I haven't really had a need for such a thing myself. It's far more likely to get in my way when I stray past common scenarios.

I’ve written quite a lot of rust GRPC web services. The reason being that we wrote a lot of propriety derivatives library code in Rust that we needed to Interface with. We could have wrapped this in python, but to be honest, it just wouldn’t have been worth the effort.

I ended up writing something that faced external clients in rust, that had to do traditional web app things, and it was okay. The pros were that you could write idiomatic interfaces to things like auth that wouldn’t look out of place in a Django app. The cons however, was that writing these Interfaces took some non trivial rust knowledge, especially since we did a lot of async rust.

I've been experimenting with Rust for web apps instead of Go, so I haven't used it in anger yet, and have started working on a blog post to get my thoughts straight. My experiments are for web apps that focus on server side rendering with just a little javascript through HTMX and AlpineJS.

The main thing I'm finding an issue with Rust so far are things that I could find packages for in Go. The main one is having an oidc helper library that can take various oidc services (github, twitter, etc), and provide me a standardised 'account'.

Apart from that, I'm finding the experience nicer overall. Examples:

* I have better/easier control over errors in ways that don't clutter up the readability of my handlers. I can easily define global rules about how errors from different systems (database, IO, etc) should be returned to the client.

* Compile time checks for things that would fail at runtime in Go, and therefore require more extensive tests base to catch when refactoring --sqlx and askama are examples enabling this (askama is particularly nice for this -- more work to get things to the stage of compiling)

* When it finally compiles, it usually just works, due to aforementioned fewer ways for failure at runtime

* Can express/encode some functionality much more succinctly than Go

* Macros for auto-generating code (though I haven't needed this in Rust yet), where with Go I'd make a small external tool for auto generating code. I use generated code a lot in Go, and even with the new 1.18 release, I see that continuing.

With more time for the ecosystem to grow, I can see Rust being just as useful. Apart from the ecosystem and the nice fact that you don't need .await's in Go, I can see Rust being really good for this sort of thing.

I don’t find the overhead of Rust to bad for web apps. Saying that I used to write web apps using EJB’s, JSP’s, Apache Struts although have also used NodeJS, various Jamstacks and PHP frameworks, Rails and a bunch of others extensively.

At the web level the biggest pain I have is the dev workflow isn’t as nice as the Jamstacks with hot reloading so you can see visual changes immediately in the browser. If doing backend for front end this pain goes away if front end is some NodeJs / php or other app.

Why is my preference now Rust? It’s fast and low on system resources. It means I can run my apps at a fraction of the cost compared to other languages. I can package my app in a Docker container that’s single digit MB’s. It’s not that to low level to be an inconvenience and high enough level to be reasonably productive. Being strongly typed and being able to find bugs with the compiler also helps.

100% agree. It drives me nuts when people use the wrong tool for the job.

I'm suspicious this occurs when there are too few tools in a given box. See also: NodeJS.

Are you confident it’s the wrong tool though? Curious have you tried web apps with framework such as Actix ?

If I would write it in C/C++, I would instead write it in Rust. Otherwise I would pick something more appropriate for the job. As far as performance, Java and Rust are neck and neck getting their asses kicked by Javascript (for web apps)!

https://www.techempower.com/benchmarks/#section=data-r20&hw=...

And yet real-world Rust projects consistently have significantly lower memory footprints than real-world Java projects (with people often commenting on the memory savings they observed from porting away from Java, even just to Node.js) as well as being free of some of Java's most common runtime exceptions.

It doesn't matter for webapps. At all. Further, they don't understand the defaults the JVM uses for maximum throughput. It uses most of your memory on purpose as it expects it is the only process running on your server. Generally you can set the max memory usage to be much lower and get basically the same performance. But who thinks anymore you know?

Funny. It seems to matter enough to me that I'm making plans to rewrite projects I can't host out of GitHub pages in Rust to optimize how much VPS I have to pay for.

Reply on news.ycombinator.com