Hacker News Reader

> A big problem with Rust, long-term, is that the kind of programs that really need it are somewhat out of today's mainstream. It's not that useful for webcrap. It's not that useful for phone apps. The AI people use Jupyter notebooks and Python to drive code on GPUs.

One thing this is missing is that Rust is useful for libraries callable by many different languages. You may or may not want to use it to build an actual Web app (I personally think it's a solid choice, but reasonable people can disagree). But for building, say, the Python cryptography library [1], which is used as a part of "webcrap", Jupyter notebooks, and in many other domains, Rust is clearly an excellent option. Nobody is going to build core Python infrastructure in Go or Node, and without the plumbing libraries none of the higher-level applications can function.

[1]: https://github.com/pyca/cryptography

You mean to link against Rust binaries or can you make library files too? Compared to, say, SQLite as a single C file, I thought that Rust projects are not super easy to use as a dependency

Rust can output library files that use the C calling convention, either static or dynamic. Doing this entirely by hand is pretty annoying, because your API surface has to be C-compatible (so can't contain a lot of Rust's useful language features) and because you still have to do the other half of the FFI to use the library from the other language. However, it's possible to develop automated language-specific tooling to make this easier, with PyO3 being a particularly impressive example.

Depends on how you link rust, using PyO3 makes it arguably easier to do link python code to rust than any C construction I could think off. Linking a single C file into python is quite difficult (if not using JIT like cppyy) because you need to make bindings & conversion often on both sides for each exported function.

Except that is the exact reason why I would pick C++ instead of Rust, the Java, .NET and JS ecosystems are written on top of C++, and the libraries I might want to write bindings for, are also written in C++.

Adding another language in the middle will only complicate our toolchain.

Regarding Python, with the pressure from Ruby, PHP, JS and Julia JIT compilers, they will eventually get more serious about JIT adoption, and then there is ctypes of OS APIs.

> If you're building web backends, Rust is not a good choice

This heuristic wouldn't work for my department because we build web backends in C++. I keep telling the most senior devs here that nobody does this and for good reasons (velocity etc), and their response is "who cares what the rest of the world does, they're just bad at C++."

Google developed Go specifically so they didn't have to use C++ in high-volume web backends, which is what they did previously.

These aren't high-volume, they're just web interfaces used internally by hundreds of people. Golang wasn't well-received either in our dept. Java would've saved us a lot of headache, a phrase I never thought I'd say; adjacent teams use it for similar things.

Another (maybe even more) important motivation was to have simple, statically-typed language so that new hires can contribute to the codebase faster and the code itself is more standardized and easier to maintain at large scale.

They basically got there with Java + some frameworks. It's not the best (I'd like NodeJS), but it works and has a huge ecosystem already, and anyone can use it. Some people complain that Golang is designed specifically for its original use case of specialized web backends and isn't great otherwise, or that its main design goal was being "not C++."

Google absolutely uses lots of C++ in high-volume web backends today. Go didn't replace it.

A few people at Google did, as far as I'm aware it didn't start as some officially sanctioned project at the company. golang has its own sets of challenges due to the limitations of the language and its error prone bare bones threading model.

Nope, Google is fine with Java and C++.

Go authors always disliked C++, and got a manager that allowed them to work on their toy language, which eventually became Go.

You're right. I think that it replaces C/C++ for many use cases. I'm a quant, and I use it to write fast algos for research. It won't be long until Rust has good high level SIMD primitives like the faster crate offered. I can't see myself using anything else thereafter for performant code.

You may be underestimating the amount of need there is for performant code though. Its everywhere.

>I've been saying that for a while. If you're building web backends, Rust is not a good choice. Go is so much easier. The green thread system gets rid of the thread/async distinction, garbage collection means you don't have to obsess over memory management, and the libraries for web backend stuff are the same things Google uses internally, so they're well-tested.

The thing here is that most web backends are basic CRUD bullshit, and you fundamentally will not hit the thread/async distinction, nor need to care about whether there's garbage collection or not. Microsoft has used actix-web in production as far as I know, it's not like the Rust web stack isn't battle tested.

>Where do you really need Rust? Heavy-duty multi-threaded programming. Operating systems. Compilers. Routers and network infrastructure. Robotics, maybe. Hard real time.

These are all the things that sit adjacent to a web framework, and once you step outside that CRUD happy path, Rust fits very well - and in this case just "bolts on".

>It's not that useful for phone apps.

This is more tangential but I know of more than a few companies who have written or are writing their cross-platform logic in Rust instead of C++. This is really akin to how some projects back Python modules with Rust: it's easy to have it backing things and it beats the hell out of dealing with C++.

And look, I'm not even saying don't use Go/Python/JS/<insert your preferred language here>. You do you, your startup will live or die by so many other things than choice of programming language.

Exactly. And for phone apps, using Flutter with flutter_rust_bridge is a great choice for FFI.

They are out of the mainstream, but only because "systems people who have exchanged any hope of losing their virginity for the exciting opportunity to think about hex numbers and their relationships with the operating system, the hardware, and ancient blood rituals that Bjarne Stroustrup performed at Stonehenge" "SOLVE THE BEAR MENACE" [0].

[0]: https://www.usenix.org/system/files/1311_05-08_mickens.pdf

There is probably a good space for Rust in writing the databases, caches and all sorts of proxies as well. I agree though, for most of the stuff I need for $DAYJOB the speed is nice but hardly required. It doesn't really matter if I can generate a HTTP response 50 microseconds quicker if the response then has to travel over the internet for 20+ milliseconds.

It does matter if you're using cloud autoscaling FaaS (previously known as CGI) and paying for those HTTP responses by the microsecond (and by RAM usage as well, which is also typically quite low in Rust).

Not really, the connection won't close until you are done sending it all and have received the relevant TCP ACK messages from the other sides. Being on autoscaling FAAS or not does not matter for that.

In any case, if you are trying to optimize microsecond usage in AWS lambda I hope you have a truly gargantuan amount of traffic and/or have incredibly cheap engineers or the money saved will barely match up to the cost of the engineering hours sunk into them.

So here's a real-world case of where this actually does matter:

https://andre.arko.net/2018/10/25/parsing-logs-230x-faster-w...

two minor follow-ups on that as well:

* https://andre.arko.net/2019/01/11/parsing-logs-faster-with-r...

* https://andre.arko.net/2022/03/13/parsing-logs-faster-with-r...

I appreciate that there might be use cases where performance absolutely does matter, and log parsing is indeed one of the sweet spots for that. But offline analytics is something quite different than HTTP request generation, even if you sometimes do both in an AWS lambda.

Additionally for the case mentioned, the log parsing apparently already fit quite comfortably in the free tier of AWS lambda. Rubygems.org seems to get its developer time for free, so Andre can keep tuning this log parser as a hobby experiment (in the best sense of the word, nothing wrong with having fun). But TFA was about building a startup and most of those definitely don't manage to get their devs to work for free.

Rust has been around for so long these domains should have long since been covered. Quite telling they aren’t yet, particularly considering the momentum in publicity. I wonder why.

> Rust has been around for so long

Rust async support was only released in late 2018. Not very long at all, especially if compared to Golang.

I’ve been writing data ETL pipelines in Rust and having a fantastic time.

Most of my data, cost and performance requirements aren’t suited to the likes of FiveTran/etc, and whilst I could theoretically use Python, it’s far too slow, and the propensity to crash unexpectedly (meaning I have to spend extra time debugging) means the development velocity is actually worse than just writing it in Rust. Plus, most of the libs and tooling I’d use from Python are available in Rust.

I’ve also written Rest and GRPC API’s in Rust (mostly for serving up data and being a query layer), and found it a far more pleasant experience than Python/Typescript/C#. Admittedly a somewhat ”smaller” use-case than a lot of what people would consider web-API’s but still.

How much of your ETL is rust vs SQL? I agree pandas for ETL isn’t the fastest but why not isn’t SQL faster still? Or don’t you find yourself in the situation where there is so little logic in the ETL that rust performance/safety isn’t that useful?

> It’s not that useful for phone apps.

If you’re building a large complex app that needs to be shared across multiple platforms, C++ is a common choice. Not talking about games here, think Office, Facebook, Zoom, WebEx etc. It easy to see Rust replacing C++ in that stack.

But as Rust is so much nicer that C++, I could see it becoming popular for smaller projects that want to share common logic, with a native UI on top.

> and the libraries for web backend stuff are the same things Google uses internally, so they're well-tested.

Internally Google uses no web and most of the backends are in C++.

Oooh Rust gaming engines. Hadn’t thought of that. One of my favorite games is coincidentally named “Rust.”