From Erlang to Lunatic | Hacker News Reader

From Erlang to Lunatic

mattpo.pe

54 pointsbkolobara25 comments

As a "systems" programmer I feel strongly that Rust is the wrong fit for most applications, but is suffering from web and application programmers needing that next fix of rewriting the world in a new shiny toy.

You could have a garbaged collected language with an actor model, implicit yielding, easy runtime inspection, easy to learn, easy to teach, but instead you're picking Rust because it's cool. The author could have just used Elixir, or Go, and they'd spend half of the time they did learning and writing Rust code on the millionth web framework/userspace work stealing scheduler. I mean, they know Erlang, so why not Elixir? Why not Phoenix which they've been working on for like 10 years now. It actually astonishes me how often these very well trodden wheels get reinvented for no reason at all because web frameworks are apparently all developers work on these days.

Systems programming absolutely needs Rust, but this "it's a great fit for everything" has to stop. You don't need manual memory management. You don't need to think about lifetimes. You don't need explicit yielding. If you're choosing Rust because you just want to use a complicated language, learn a new toy, feel like your web app needs to go at light speed, maybe stop and consider that you're doing yourself and whoever your building your software for a disservice when something like Go is way easier and will cover the 95%. I have seen these garbage collected languages scale to incredible loads with good engineering that focused on good architecture rather than magic tools.

If on the other hand you actually need to write software that's going to run on a TPM, or in the kernel, interface with a new hardware protocol, ok, use Rust. C is obviously a huge danger and we've known that for a very long time. That's what Rust is good at, and trying to use it for everything just leads to code bases that are way more complicated than they ever needed to be. And truly, being as simple as possible is almost always the right way to go.

Here in Europe I'm thinking of using more Rust simply for power efficiency. If it's twice as fast as, say, Go, then it's using half the (incremental) power. That's non trivial now that energy is a serious cost consideration of computing.

Then you can't use anything else than C/C++/Rust with that argument.

Also the twice as fast therefore using twice less power is wrong.

You could use Nim.

Yes, there are a lot of options, though it gets less mainstream pretty quick. Fortran, Ada/Spark, Ocaml, for a few other examples.

Those are not mainstream language, they probably lack libraries for most common use case, also most likely not as fast as Rust and probably even Go.

Right, which is why I said “gets less mainstream,” meaning that the examples listed were not mainstream. Apologies if that was unclear.

But you'd be wrong about your speed guesses. Ada/Spark and Fortran can be incredibly fast. Much of the world's fastest numerical code is written in Fortran, for example. (OCaml can be super quick too, though it can take a bit of care, and I get the feeling they've fallen behind in compiler tech in recent years.)

Be sure to do the math. A lot of programs use negligible power. If you spend an hour more writing your program, with your computer on during that time, you may find it can take you literally years to recover that. In fact it's not hard for it to take centuries or worse.

Programming spans a lot of orders of magnitude. If you're writing code for a multi-hundred system cluster, then by all means consider energy consumption. But it's also easy to spend hours, days, weeks to save a net total of several milligrams of CO2, because your program won't even spend as long in its total life time executing as you spent writing it, in which case the costs of execution are actually less that the development.

That's not how that works. Rust can actually make power usage worse because it generates larger code sizes which causes more I-cache churn and thus more power usage. Making efficient use of caches, power states, and reducing polling are all things that you don't just get for free because "I'm using Rust and Rust is efficient". Rust lets you write something efficient after you've spent tons of time working on making it efficient and understanding how power is consumed on a particular platform for a particular app.

Once again, you could just use a language where they do this for you in the runtime instead of trying to reinvent (probably poorly) these ideas yourself.

At least on mobile SoCs that's exactly how it works, in fact due to how dynamic frequency scaling works it can be worse than 2x because to run at a higher frequency you need to run at a higher voltage. Your frequency increases(which drive switching costs) and you're paying more per current due P=IV.

You're right in that not running the workload if possible is the best power savings but if you can't do that moving it to more efficient usage is a good way to make large inroads on power usage.

This feels like a nano optimization to me.

The rust compiler has a serious energy cost though.Also due to lack of (proper) standard library, downloading thousands of crates is pretty expensive. If you use CICD, cargo+rustc is gonna burn through your energy budget VERY quickly.

> suffering from web programmers

Agree 110% !

If you said I could only name one use-case for Go, it would be "web stuff".

Go is practically made for it. Whether you are consuming or serving "web stuff", the Go stdlib covers 99.999% of "web stuff" use-cases.

Rust doesn't have ANY stdlib, let alone a "web stuff" friendly stdlib. Which means you have to choose between :

       (a) Re-inventing the wheel, yet again; or
       (b) Choosing between a dozen crates for this that and everything else.

Meanwhile Go comes batteries-included with http, crypto, json and all the other "web stuff" that you'll likely ever need.

Rust has a small(ish) but high quality stdlib. It does not aim to be Python. Like with any language, you have to know the ecosystem in order to be productive.

That said, sure, having a full-featured stdlib can be convenient. It's a matter of trade-offs. Having more content outside of the stdlib allows the ecosystem to evolve organically (and iterate quicker) and select the best approach to a given problem (which... could definitely have been an advantage for Python).

Marginal benefit of manual memory management for the extra effort to write rust code is not worth it for a lot of use cases. Who wants to think about lifetimes and not business logic when writing a web service.

Vast majority of programmers are likely to be users/customers or software written in rust rather than users of the language itself.

Why does it matter what language, framework or library someone works on their weekends? I guess the main point was bad influence from people working on non-systems programming stuff. Rustlang blog itself appears to have general ideas on what they plan to work on, in case people are interested: https://blog.rust-lang.org/inside-rust/2022/04/04/lang-roadm...

Completely incorrect and misses the point of Rust. Tracing through state in imperative languages without ownership systems (aka, anything that isn't Rust) is a complete shitshow. Rust is not a complicated language at all, and allows you to lay out programs in a new and better way. It gives you the benefits of pure functional programming - no sneaky mutation, no state to keep track of - with the simplicity and performance of mutation when it's safe to do so. This is what makes Rust actually good, and miles ahead of basically every other language in widespread use.

> Rust is not a complicated language at all

Yet many find it so, whatever you write. Either they're wrong, or they're too thick for Rust. I certainly find it extremely difficult and complex.

The denial/disregard of the experience of others (and fury that they dare express it) is one driving force of fanaticism.

I’ve got to disagree a little. Revealing my bias: I’m a former TS full stack who now works full time in a company that uses Rust on the backend (not my choice). I’ve done so for over a year now.

I find it’s a bit like C# in some ways, especially it’s ability to scale the codebase. Code navigation is incredibly clear and the libraries have been great. The experience of using async-graphql and sqlx is unbelievably intuitive.

For the bad: the compilation times can still be a little slow (especially in CI). This sometimes makes dev a just slightly awkward. I’ve had to contribute to a couple of libraries we depend on because they are still quite young, and we’ve had to move web framework once. Hiring might also be a slight challenge.

I’m not sure if I’d necessarily pick it again if I was to choose for a small business again - but frankly using it has still been a pleasure and the ecosystem is only feeling better.

use rust distributed cached builds, couple liners on ci. vendor stuff. for example nix crane can be good.

It’s sad to still see comments like this. You don’t necessarily pick Rust for the performance or the memory safety, or whatever rustaceans tout. I think this article summarizes pretty well why I love building apps un Rust: the code you write is robust as hell. It builds? Virtually only logic errors are left (and a null or error test is not a logic error in my book).

And have you ever built non-system things using Rust? Because I do write, among other things, gRPC services professionnaly, and let me tell you lifetime errors are virtually nowhere to be found. Why? The vast majority of apps are request-response things with owned data in, owned data out; no manual memory management either. And on the rare occasions the nitty-gritty parts of the language do surface, it is well worth it due to the peace of mind that the code is robust. Just pattern matching on errors is enough for me to write APIs in Rust and not Go. As an added bonus, we use the same language for our APIs, system agent, low-level network apps, eBPF probes, you name it. It makes work so much more fluid for the whole team.

However I do agree on some parts, esp. the explicit yields, where Go and Zig nailed it. Async is currently somewhat of a pain in Rust, especially since it tends to infect pretty much anything. I don’t remember the last thing I wrote without tokio…

I agree that there could be languages better suited for general purpose programming than Rust.

However eventually most succumb to the ecosystem critical mass. Whether you end up using ocaml, or pony, or elixir or whatnot, you'll soon hit that wall, where you can't hire developers easily enough (or move them between teams), or you can't find that answer on stack overflow easily enough, or have somebody fix that toolchain bug for you, or find a workaround that language or stdlib issue you're blocked on.

Rust, for all its flaws and difficulties, has reached that critical mass, and even people who are not entirely sold on it, may end up choosing it just because overall it makes more sense than many of the alternatives.

elixir is dynamic, go lacks match. author is clear about be likes static match.

go libs years before get generic. and more years it evel will get unions.

Doesn't Lunatic support anything that compiles to WASM? Why insist on using Rust when one's running into pain points with it?

No language is perfect, thats kind of the point of the author going from erlang to gleam to rust.

Reply on news.ycombinator.com