Rust isn't hard. Programming in general is hard. Rust makes this difficulty explicit.
It's easier to program if I don't have to worry about ownership/lifetimes. -- Garbage Collection allows not needing to worry about lifetimes; and preventing the same value from being mutated from multiple places in the code generally isn't such a significant problem.
With high level programming (in JavaScript), you don't have to pay those costs.
I like to believe that Rust's strict discipline about ownership/lifetimes encourages code that's fast/lightweight, though.
Imagine a person who just started learning about programming. A person who may still be tripped up by the fact that `=` and `==` are completely different things here.
Imagine that person.
And now imagine explaining to that person a language, that even many experienced and skilled software developers say is significantly harder to learn than the average programming language.
Sorry, but when I think about a good teaching language, Rust isn't the first thing that comes to my mind.
Python, go or (a bit less so) typescript are nice beginner languages.
Because C in and of itself, is an incredibly simple language. It is made complex in libs, usually by abusing macros, or by trying to shoehorn it into OOP, FP, or whatever other paradigm is currently being idolized.
> Python, go
Go yes, Python no, and I am saying that as someone who does alot of work in Python and loves both languages.
Because Python isn't simple. It looks simple in trivial code, but hides an enormeous amount of complexity and magic not-so-far beneath the surface. In addition, it completely fails at teaching core concepts of memory, and dances around the topic of types.
Python's hiding of memory is a feature when teaching beginners programming IMHO unless you want to start teaching close to the metal. I prefer to start from the algorithmic CS-y side.
No it really doesn't. Initialize all variables, always check boundaries and free memory when you're done with it. That about covers 90% of it.
Yes, this becomes more difficult the less trivial the codebase becomes. But beginners don't have non-trivial codebases, and teaching these concepts isn't hard.
> Python's hiding of memory is a feature when teaching beginners programming IMHO unless you want to start teaching close to the metal. I prefer to start from the algorithmic CS-y side.
And I prefer to start from the systems-programming, practical side. And in the practical world, memory isn't some abstract thing that may or may not exist, function calls cause overhead, strict typing is a friend, and networks fail.
So yes, teaching a bit closer to the metal has its advantages.
Rust is hard for older programmers because it's hard to FORGET old habits from other languages, which allowed too much.
No, it isn't, by any metric. I personally know people who learned C in a week. I learned all basics of the language in 2 weeks as a teenager, with nothing but K&R as learning materials.
If you disagree, point out by which metrics you consider Rust to be easier to learn than C, and we can have a discussion.
> Rust is hard for older programmers because it's hard to FORGET old habits from other languages, which allowed too much.
No it isn't. First, both newcomers and experienced programmers consider Rust a more complicated language than most of its contemporaries, and if anything a solif experience in multiple programming languages makes it easier to learn the advanced concepts Rust relies on.
Better by what metric?
> more syntax sugar
More features and syntactic concepts don't make a language easier to learn.
Rust is only appropriate for programs that are too expensive to run when they are written in a garbage–collected language. That means operating systems, because small inefficiencies there will add costs for billions of people. It means big server–side services, where small inefficiencies cost you millions in compute time or ram usage or whatever.
Even if you think you’re going to hit that scale one day, writing your prototype in a garbage–collected language can net you a huge advantage in time saved. You can rewrite it in Rust later, after you know exactly what features will be needed and exactly what they cost to run, and exactly how much you’ll save by rewriting it in Rust.
It's been a while since I last did something in Rust, but I remember that the shift to Rust 2018 was a huge step forward in this regard.
The reason is that actual common memory safety mitigation strategies in real life involve using some kind of smart pointers (same with Rust and C++), or using indices with bound checking (same with Rust and C++, it’s just that C++ STL has this off in Release mode by default…). For both languages, trying to avoid these runtime mitigation strategies (which affects performance) will require doing some level of unsafe stuff which the compiler doesn’t help with you (the unsafe semantics of the two languages are actually similar since Rust relies on LLVM which relies on C semantics). So ultimately, the borrow checker doesn’t seem worth it if you actually think about the cognitive overhead and headaches it brings. The only reason Rust has an edge over C++ is that it has sane defaults and a better standard library (ah only if C++ had a sane way of initializing values…)
You quite literally also have to "borrow check" C/C++ in order to have a well formed program, just without any compiler assistance.
For structs that I do not want to heap-allocate, they're usually POD types and in arrays (which you can bound check), so there's not much to think about borrowing. The more concerning issue I usually have is about about initializing the values correctly (which usually Rust doesn't help, when reasoning about performance-sensitive code).
Both situations which also apply to Rust. Whenever the borrow checker complains you can do exactly the same thing.
> The more concerning issue I usually have is about about initializing the values correctly (which usually Rust doesn't help, when reasoning about performance-sensitive code).
You can use a type-state machine, where the only way to construct the final value is by calling all of the appropriate methods that change the type parameters on the Self type. When that gets compiled it ends up as either a single memcopy of values, or you can make the Self type hold a MaybeUninit value to make the partial construction with no copy at the end possible. I actually implemented that for fun and as it turns out already existing crates that held every field in an Option and then built the final value from those ended up being faster. C'est la vie.
> We also found that the rate of new contributors increased overall after switching to Rust, implying that this decrease in vulnerabilities from new contributors does not result from a smaller pool of more skilled developers, and that Rust can in fact facilitate new contributors.
Which seems to imply the opposite of what you're suggesting, i.e. it implies that Rust makes contributing easier and safer than C++.
I also want to point out that your comment isn't accurate about how Rust's unsafe works:
> [T]rying to avoid these runtime mitigation strategies [...] will require doing some level of unsafe stuff which the compiler doesn’t help with you
(Emphasis my own.) This is inaccurate — the borrow checker is not turned off inside of unsafe blocks, but instead you are given a handful of extra APIs to use. Those extra APIs can be used to do things that the borrow checker would not normally allow (e.g. by converting checked pointers into raw pointers, and then inside the unsafe block, dereferencing those raw pointers), but the borrow checker is still active, and still catches all the same errors as before.
Yup I know that the borrow checker does also work inside unsafe blocks. But when what you primarily do as a systems programmer is establishing invariants in your systems so that you can exploit (or circumvent) the UB-ness of the underlying system (OS/driver/hardware/etc.), and when the borrow checker doesn't really help you with verifying these invariants... The Rustonomicon states that whenever you open up an unsafe block, it doesn't pollute only the scope, but the whole module (https://doc.rust-lang.org/nomicon/working-with-unsafe.html). So there can be a correctness issue outside the unsafe block because it disobeys the invariants implicitly set up by the developer inside the unsafe block. And you can't do anything about this other than carefully reasoning about all the various ways your implicit invariants can break inside the whole module. So unsafe is ultimately more of a convention (or a promise) that you have designed and verified your invariants correctly, so that you will not produce undefined behavior no matter how you use the module as an outside user. If you want to verify your invariants any further than that, you need to check UB at runtime using the Miri interpreter (which is really slow and still incomplete), or just use Ada SPARK.
mod name_of_module {
// code goes here
}
This leads to a really nice gentle onboarding flow where inexperienced users can start out contributing to the safe parts of the project, and (optionally) move on to gnarly unsafe bits later when they are already familiar with the project's codebase. It also dramatically reduces review workload for maintainers as they can rely on the compiler enforcing invariants outside of unsafe modules.
This works less well for really low-level code like embedded code or kernel code. But it's still a lot better than nothing.
Maybe there's a reason why game developers have primarily used scripting languages - give out a safe managed GC-backed runtime for the majority of developers, and let only a select few who understand the system to develop the core C++ engine. Maybe Safe Rust can be used this way (as a "fast" scripting language), to separate between these two worlds... but the problems is even Safe Rust is just really difficult to grok for newcomers, and the hoops they go through to circumvent the borrow checker either falls into using Copy/Clone all over the place (slow) or smart pointers (slow) or array indices with bound checking (maybe less slow but more cumbersome, and also prone to logical invalidation errors if you're not careful)
Are smart pointers like Box, Rc and even Arc any slower than any scripting system you'd "hand out" to most developers from your tightly written C++ core engine?
One thing that I see is that 90% of code is simple enough that you don't need to have any ceremony around ownership beyond writing a & in front of a value or type, 5% is harder than that but doable, and 5% requires extensive expertise to avoid allocations, or using Arc. I'd wager that the distribution of code that a GC can optimize during runtime is comparable, if not worse, at higher memory consumption.
I've compared some simple networked applications written in Java and Rust for that purpose, and performance ended up being comparable, but with 100x memory consumption, even when using GraalVM.