I could understand going as far as Go, but further than that it just feels not the right trade-off for the productivity lost.
Rust says "a String is a valid Unicode sequence, an OsString is a valid filename according to your OS, and a &[u8] is a sequence of bytes; I'll enforce the validity of these types for you". Go says "a string is a sequence of bytes, make sure you use them correctly."
Rust says "here's an Iterator interface, with hundreds of methods for your convenience". Go says "we didn't have polymorphism when the standard library was developed, so there aren't any fancy iterators; how about you use a for loop?"
Rust says "error handling is important, so there's syntax built into the language for it (the '?' operator)." Go says "just write `res, err = func(); if (err) { handleErr }` over and over again."
Rust says "please think carefully about the difference between shared references, mutable references, and ownership; I'll be checking your work." Go says "you don't need to think about that, I'll keep track of it with GC for you (unless your sharing data between threads in which case you do and you're on your own)".
In the last instance, Rust is lower level than Go. But in the rest, it's higher level.
Rust exposes low level primitives and is efficient, that's nice and all, but you mostly don't actually think about them when programming non-low-level applications.
What it does force you to think about a lot is it's correctness guarantees. Things like only letting you modify data that no one else currently has a reference to, and things like forcing you to check error conditions by wrapping them behind an "enum" (algebraic data type). Rust is making a tradeoff here between friction in writing code, and the the amount of time it takes to understand code as well as the number of bugs you write.
All in all, for most large programming projects there is no language I think I'd be more productive in than rust. For small scripts, the tradeoff can be less worth it (in which case I tend to use python, or for even smaller ones bash), but those scale poorly to giant projects where you want to be able to do things like refactor without introducing bugs in a file you forgot about.
It happens to be the case that rust maps many of it's primitive types directly to low level types that you can reason about in a low level fashion (e.g. ADTs are tagged unions, references are actually just pointers - maybe with a second vtable pointer depending on the type) - but you don't need to do that unless you're worrying about optimizing the constants for performance or doing terrible hacks with unsafe.
Sure, there used to be a tradeoff between performance and expressivity in a language, such that a "low-level" language would just become crufty and kludgy up to the point that someone would decide "screw it, we'll implement a safer but less performant language in this less safe but more performant one".
Today, the hardware is much more powerful, and the theory and practice of software development is more advanced. Thanks to open source, devs have been exposed to good ideas from all corners of the ecosystem, so all that would remain is coming up with sane syntax and semantics - and Rust positively excels in that regard.
I'm fluent in Python and JS, but I put off learning "low-level" languages because of the innumerable footguns. Go looks like it has plenty of those, too, and TypeScript is... just a mess. Rust is next-gen stuff in my opinion, and categorizing it as just a "systems-level" language makes no sense. It's "systems" all the way down, and the more kinds of systems a language can efficiently cover, the more good things can come out of it.
I myself am guilty of this, I wrote a web app recently using Rust, mainly because I wanted to learn Rust. I probably wouldn't reach for Rust next time as implementing my project in it has felt like overkill throughout.
You're moving around strings and talking to a database, and possibly doing some templating. It's not rocket science, and provides the same story as Go with regards to build + deploy.
Yet it has a lot of nice abstractions you usually see in much higher level languages like Scala or Lisp.
So if you already learned C, you can learn Rust and see it as higher level than the usual Java/Go.
If you skipped C and this is your first time learning heap memory management and pointers, then yeah, Rust will feel lower level
This situation is why there is such a big disconnect on people's opinions on rust I think. That and that it's oddly popular among total programming noobs. Not anything wrong with that but I don't recommend it as a first language anymore than C, for the same reasons. Might as well walk before running
Oh so many reasons:
Lemmy is a socialist project. Rust is a project that has it roots in FLOSS movement and Mozilla foundation. Go, otoh, is Google's thingy; a tech/advertising multi-national.
Technically Go is in some ways less low level than Rust. See the null guards everywhere in Go, and the idiomatic abstractions that Rust provides for this in the stdlib. Rust has sum types that allow for really high-level abstractions, was designed with generics in mind.
I personally find it more intellectually rewarding to program in Rust, over Go or say Python. The stack overflow favorite list shows more people like Rust as a language.
You call it "more trouble than it's worth", but that's up to the Lemmy devs to decide. As a FLOSS project, expecting they put in the effort of love there...
Sure Go was a viable alternative; but would the devs enjoy writing it in Go? Also then they would be skilled in Go, maybe that's not what they want.
As in the project itself is socialist? What does this mean?