Hacker News Reader

Comment by 0xblinq | Hacker News Reader

Using Rust for a CRUD application is a terrible choice. Of course it won't work.

It's like using Rails to write a database or a DNS server. You're just trying to use the wrong tool for the job.

It's not a terrible choice. It's not necessarily wildly better than alternatives, but it's not wildly worse, either.

Among other reasons to consider it: if you want to run on a FaaS platorm or container setup, Rust has much faster cold start time and makes for smaller container sizes.

Among reasons to not consider it: if you want to iterate rapidly by editing text and near-instantly hot-reloading your code, Rust web frameworks aren't really there yet. They will be one day, but they're not yet.

> Among other reasons to consider it: if you want to run on a FaaS platorm or container setup, Rust has much faster cold start time and makes for smaller container sizes.

Faster start time maybe, but I’m not sure about smaller containers. Rust is terrible with binary sizes in my admittedly limited experience.

I just compiled and checked:

- sqlx binary: 200+ crates, 5.4Mb (after strip), 27 kb per crate on average.

- zero2prod last example: 400+ crates, 14Mb (after strip), 35 kb per crate on average.

Binary is statically linked, so Docker container is very small too.

Exactly, 14Mb for a simple API server like zero2prod is rather large. That's with stripping, if you want the ability to debug and get pretty panics it'll be even larger.

You can download a pre-compiled sqlite tools package includes four binary CLI tools in only 6.5 MB vs that one sqlx binary which is 5.4 MB. Of course they're not the same, but the general trend I've seen is that Rust is as large or often larger than bloated C++ projects.

For example I worked with Rust on a Yocto project where you can't use Rust's stripping config because it breaks (broke?) the hashing Yocto does. A very small IoT API project ended up being 50+ MBs. It was larger than the rest of the entire Linux system. I've written IoT projects of similar complexity in Go and Nim which come in under 3-4MB with full debugging no stripping needed.

It's 14Mb with 400+ libraries included. `cargo bloat` shows that top function by size is from rustls (SSL support). For a container with a single binary, it's huge space saver. Moreover, I can easily optimize binary by size to 7.9Mb binary (20kb per crate on average).

> because it breaks (broke?) the hashing Yocto does.

It's problem with Yocto. In my case (few years ago, before the war), I just build RPM packages by my own build system and then install them on top of pure Yocto system. I optimize my binaries for embedded by size.

In theory, debug symbols can be separated to a separate debuginfo rpm, and installed only when needed or mounted remotely from a host system. In practice, I just install the binary enhanced for debugging (with debugging and tracing features enabled) directly to Yocto device, then add test case to reproduce the problem on host, because I hate debuggers.

That is often because of static linking and the high chance that Rustls is linked in there somewhere

In my experience, CRUD applications in Rust are good: they are easy to write and test. :-/

Why you think that Rust is a wrong choice for a simple or a complex CRUD application? Can you explain, please?

Because it's not about the language. It's about the ecosystem, the tools, the libraries and the frameworks. There's no world where your barebones hyper performant Go/Rust/etc and its minimalistic routing library you might want to call a "web framework" can match Rails/Laravel/django/etc productivity wise.

If you don't like being paged at night, then Rust for CRUD apps is fantastic -- having worked with Python, c#, and nodejs backends, I'll take Rust backends every day of the week.

Reply on news.ycombinator.com