Rust seems harder but it allows for compiler guided development. So there's a bit of an upfront learning cost but the maintenance cost is lower. If you change something in an enum variant, the compiler will basically tell you what to change everywhere in your codebase.
Specifically, Rust code has less assumptions, with lifetimes, mut, etc., Rust code is much easier to read. If I read a function, I need less awareness of other parts of the codebase because so much of the information is just there.
Counter-point: This is clearly not perfectly true, considering that I would still recommend Typescript over Rust for web dev.
More elitist take:
Rust is not hard. If you can pass a college algorithms class (i.e you can understand BFS/DFS/DP/Network Flow), you can understand Rust.
If your developers cannot write Rust code, you will probably pay the price in whatever language they write.
Counter point: This is clearly not 100% true since I would not say the same thing about Haskell even though arguably I could.
> Counter point: This is clearly not 100% true since I would not say the same thing about Haskell even though arguably I could.
This is not really a counter point. Any dev who struggles to write code in any modern programming language (after ramp of course) is arguably not a good programmer. Programming is far far more than code.
As a beginning programmer over 30 years ago, I struggled trying to learn C++, and later found Java literally infuriating (which would later sour me on JavaScript through misplaced guilt-by-association). And then I discovered Python.
What a revelation. Suddenly I was doing backend web development and building custom content management systems.
I would say low level languages, and pure functional languages, and other unusual things are an exception.
I don't see how anyone could use Haskell or Scheme and especially not Forth without lots of experience in that specific paradigm, and lots of programmers don't prioritize learning languages they don't expect to encounter.
They say Haskell makes you a better programmer, but does a lack of it make you a bad programmer?
Weird take: I actually do say the same for Haskell
(disclaimer: I've used Haskell in all my personal stuff for about 5 years now)
A lot of the stuff I used to hear and say about Haskell (about type driven and compiler driven development) is now making the rounds in the rust community, and I'm honestly super happy about it. I'm really happy that this way of programming by having a (not so) friendly chat with the compiler is gaining traction.
For projects that need to have high security and reliability, I'm much more confident adding novice Rust developers to Rust projects than novice C++ developers to C++ projects.
Rust limits severity of the damage an inexperienced programmer can cause. It is hard for a noob to get past the compiler, but once they do, the code already has lots of correctness guarantees. “Bad” Rust code may clone() more than strictly necessary, or waste 10 lines of code for something that has a 1-liner in the standard library, but it won't corrupt memory (noobs will know to stay away from unsafe{}, and that can even be enforced). Rust prefers to be locally explicit, so it’s also easy to review.
From the article:
> These rules may sound complicated, but really, they are about understanding the fundamentals of how a computer works.
... and from the post that the article links to:
> Understanding String vs &str implies an understanding of the ownership system, which implies an understanding of the lifetime system. That probably means that you’ve been exposed to pointers, references and perhaps even aliasing. There’s usually a discussion about mutability intertwined here. Gaining an intuition of data types that represent text benefits from understanding encodings, which benefit from understanding how CPUs operate.
> I’ve yet to find a way through this for complete beginners. Learners with that already know another systems programming language have a distinct advantage here.
This, IMO, is the key to understanding why Rust is hard to learn: it was written as a systems programming language, and we now expect it to be more than that. I nodded my head in agreement as I read the intro to Rust until I reached the explicit use of lifetimes. To me that was where the abstraction got leaky. If your core abstraction of borrowing needed to expose the fact that the compiler uses lifetimes and needs a hint from time to time, you're saying explicitly that your audience are system programmers and they get that no abstraction is clean.
Take that up a few levels of abstraction and application development with Rust is hard. Maybe the rust community should just say: "Yes, its hard in the beginning, but its worth it if you stick with it. Welcome"
PS: I personally found it hard to learn Rust when I was looking for a static single binary generating language for my side project, and went back to C (please don't judge, its just familiarity). But I see what Rust can do.
This fits with my recent experience. I've spent the last 2 months working on a large open-source Rust project, and it's been mostly easy; I make self-contained changes that fit into the existing architecture and I don't have to think too much about lifetimes or the borrow checker. But when I go off-track and work on my own Rust projects, things get a lot harder.
I think the specific scenario the author is talking about, ie a very large codebase providing some important infrastructure (Azure storage) with a relatively stable core is one where the costs of Rusts complexity start to be outweighed by the benefits, and Rust starts to make a lot of sense.
Where Rust’s complexity does matter is in projects that prioritise getting developers on boarded and implementing new features as fast as possible, such as user facing web services. These things probably would not benefit from Rusts correctness guarantees in a meaningful way, but stand to lose by making it harder for developers to get productive.
> Where Rust’s complexity does matter is in projects that prioritise getting developers on boarded and implementing new features as fast as possible
Agreed, and I think unfamiliar developers implementing new features as fast as possible is also much more likely to result in hacky/make it work code than throwing a Java developer at a C# project or similar.
Isn't that exactly where you would need Rust the most, to prevent new devs from doing damage?
Presumably one is going to make mistakes on an unfamiliar codebase, so they would want strong correctness guarantees to help them, especially if the codebase was full of footguns and undocumented nonsense.
if language is hard to read, hard to write, and slow to compile
it creates problems when you need to push fix to prod ASAP, or when you need to train new employees
reason why go is popular and is the cloud native language
there is still the need of a go like language for native world, i personally believe Zig is the answser, another close one is Odin, it's definitely not rust
If you need to push a fix ASAP to production, you definitely want a language with very strong static typing offering confidence that the fix doesn't accidentally break something.
If I had to push a fix to prod ASAP, I'd personally rather it take more time but go in production safely. Especially in a case like that with not enough testing to really be sure if everything's okay or not, the stricter the compiler the better.
And if I had to train employees, I'd rather them fight the compiler more in the beginning but write better code later, than be able to write code quickly but make a horrible mess.
I've seen the "fast and loose" approach fail miserably and turn into a nightmare enough times that I now advocate for strict languages whenever I have a say in things. (which is why, with the state of programming languages right now, I will almost never suggest zig or go for a project). I think developers in generals should trust themselves less, to be honest. I feel like it would avoid a lot of issues down the road.
Nim is closer to become Go killer with it's capability to target both native and JS. There are multiple async implementations offered as packages, since async is not part of the language. SPAs frameworks and bindings of popular libraries like nodejs. Databases and web frameworks, ORMs and migration tools. Multithreaded could obviously be improved in order to have better servers. But it's already looking promising.
To use? No, most modern languages can abstract to a high level. But senior JS developers that don't understand even basic memory management are not going to have a good enough handle on what's going on under the hood to be helpful. I think is more to do with them not being remotely curious, which is a prerequisite to good engineering.
Agreed - for moderately big/moderately complex systems, there are plenty of problems that really need a moderate understanding of what the underlying runtime, operating system, network etc are actually doing.
Rust isn't just any programming language. It's specifically designed to have very low (even zero) overhead on top of what the hardware is capable of, and this by necessity exposes how computers work.
In theory a compiler could figure out all the low-level details for the programmer automagically based only on a high-level abstract program, but in practice such approach has never worked well enough, to the point that a "Sufficiently Smart Compiler" is a trope/joke among programming language designers.
Rust seems harder but it allows for compiler guided development. So there's a bit of an upfront learning cost but the maintenance cost is lower. If you change something in an enum variant, the compiler will basically tell you what to change everywhere in your codebase.
Specifically, Rust code has less assumptions, with lifetimes, mut, etc., Rust code is much easier to read. If I read a function, I need less awareness of other parts of the codebase because so much of the information is just there.
Counter-point: This is clearly not perfectly true, considering that I would still recommend Typescript over Rust for web dev.
More elitist take:
Rust is not hard. If you can pass a college algorithms class (i.e you can understand BFS/DFS/DP/Network Flow), you can understand Rust.
If your developers cannot write Rust code, you will probably pay the price in whatever language they write.
Counter point: This is clearly not 100% true since I would not say the same thing about Haskell even though arguably I could.