[HN Gopher] From Erlang to Lunatic
___________________________________________________________________
From Erlang to Lunatic
Author : bkolobara
Score : 42 points
Date : 2023-02-18 13:02 UTC (10 hours ago)
(HTM) web link (mattpo.pe)
(TXT) w3m dump (mattpo.pe)
| ilovecaching wrote:
| 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.
| vegabook wrote:
| 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.
| Thaxll wrote:
| 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.
| Conscat wrote:
| You could use Nim.
| Scramblejams wrote:
| Yes, there are a lot of options, though it gets less
| mainstream pretty quick. Fortran, Ada/Spark, Ocaml, for a
| few other examples.
| Thaxll wrote:
| 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.
| jerf wrote:
| 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.
| ilovecaching wrote:
| 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.
| vvanders wrote:
| 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.
| ryloric wrote:
| This feels like a nano optimization to me.
| tuetuopay wrote:
| 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...
| ithkuil wrote:
| 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.
| traceroute66 wrote:
| > 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.
| mercurial wrote:
| 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).
| lewantmontreal wrote:
| 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...
| ryloric wrote:
| 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.
| beecafe wrote:
| 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.
| crispinb wrote:
| > 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 (though I'm not entirely sure
| what 'complicated' means in this context).
|
| The denial/disregard of the experience of others (and fury
| that they dare express it) is one driving force of
| fanaticism.
| jayy-lmao wrote:
| 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.
| yellowapple wrote:
| Doesn't Lunatic support anything that compiles to WASM? Why
| insist on using Rust when one's running into pain points with it?
| drpyser22 wrote:
| No language is perfect, thats kind of the point of the author
| going from erlang to gleam to rust.
___________________________________________________________________
(page generated 2023-02-18 23:02 UTC)