The Rust Foundation's Plan to Grow the Pool of Well-Trained Rust Developers

"The Rust Foundation is dedicated to ensuring a healthy Rust ecosystem," according to a new announcement today, " which depends on a growing pool of well-trained developers to thrive." The latest SlashData Developer Nation survey found Rust to be the fastest-growing programming language, doubling its users over the past two years. As Rust's adoption continues to accelerate, the demand for a multifaceted ecosystem of quality training will too.
Their blog post highlights three examples of the Rust community "creating new pathways for learning Rust" and "addressing the critical need for Rust training in academic settings..." Rust-Edu operates as a non-profit through Portland State University, with funding from Futurewei. Their mission is to "spread Rust use and development through academic curricula and communities throughout the world, making Rust the language of choice for 'systems programming' in its broadest sense through shared efforts of faculty, students and the Rust community." They focus on three main areas: curriculum development, educational tools, and language improvements...

teach-rs, pronounced "teachers," is a modular and reusable university course designed for in-person teaching in Rust. Its mission is to introduce Rust in higher education and ensure that more students enter the job market with considerable Rust experience. The teach-rs project provides ready-to-use Rust teaching materials, including slide decks and exercises that can be adapted to various teaching contexts... As an open source permissively licensed project, teach-rs enables educators to share and improve resources, making introducing Rust instruction into their programs more accessible. Many institutions now use teach-rs in their courses, including the Slovak University of Technology, RustIEC (a collaboration between Vrije Universiteit Brussel and KU Leuven), and the University Politehnica of Bucharest. At the time of this writing, teach-rs has nearly 3000 stars on GitHub...

Under the guidance of The Rust Foundation's Global Rust Coordinator and Rust Nation UK's organizer Ernest Kissiedu, Mordecai Etukudo (Mart) has developed a guide to help educational institutions adopt Rust in their systems. This resource walks organizations through the entire implementation process, from initial assessment to community engagement.

Have they tried the East

[SuperKendall]

The quickest path to a large Rust buildup is to send everything out to eastern cities in the winter.

trained?

[dfghjk]

"...which depends on a growing pool of well-trained developers to thrive."

Since when are programmers "trained"? "Trained" is what dishwashers are, programmers are educated...and experienced.

Classic Freudian slip, shows how modern programmers are viewed (and who the Rust Foundation thinks Rust targets).

Fortunately, AI's can also be trained. Maybe that will be good enough for a "healthy Rust ecosystem".

Re:

[HBI]

This kind of advocacy is actually a deterrent to wanting to use it. If it were so self-evidently good, you wouldn't need all this effort to force-feed it.

Re:trained?

[Local ID10T]

They have never answered the big question. WHY learn Rust?

I started with Basic, because a basic interpreter came with my first computer (Commodore VIC-20). I learned Assembly to move beyond the limitations of basic. I discovered C in the early 80s, and was hooked by how easy it was to actually do things. I felt the same draw to learn Prolog (that was a big dead end...) and R. I wanted to do the things that learning this new language would enable.

Rust has never had that pull. That "learn Rust so you can do X" ...is just not there.

Re:

[ZipNada]

What I see mentioned as advantages is memory-safe code that isn't vulnerable to things like buffer overflows and reuse of neglected memory. The threading implementation is said to be very resistant to race conditions. Nice features to have for sure, but I'm not yet motivated enough to learn and use it.

Re:

[caseih]

What's great is that Rust kind of showed the way, or at least a possible way, and now those safety principles are being adopted by other popular languages, including C++. And I've seen implementations for other languages as well. This is a good thing. So credit where credit is due.

Re:

[Waffle Iron]

Rust has never had that pull. That "learn Rust so you can do X" ...is just not there.

You learn Rust so that you can create high quality production-worthy code, with all the I's dotted and all the T's crossed.

Creating such code is never very fun, so naturally dabblers won't be drawn to it.

Re:

[Local ID10T]

Creating such code is never very fun, so naturally dabblers won't be drawn to it.

Ahh... I'm not good enough to understand your messiah. That will totally convince me your savior is the real one!

Re:trained?

[Waffle Iron]

Look, I learned Rust and was impressed by its capabilities. But the tradeoff is that it's a royal PITA to use, and requires you to carefully plan your whole project up front (lest you rewrite all the reference handling if you change how your data structures are organized). So I never use it myself; Go is fast enough for anything I do and 10X easier to write in.

However, if I was getting paid to write secure code that has to be as fast as possible, I would fully support writing it in Rust. For the same reasons, when I'm getting paid I put up with subjecting all my work to code reviews and being forced to watch regulatory compliance training videos. Not fun, but necessary for a production environment.

Re: trained?

[ArmoredDragon]

Look, I learned Rust and was impressed by its capabilities. But the tradeoff is that it's a royal PITA to use, and requires you to carefully plan your whole project up front (lest you rewrite all the reference handling if you change how your data structures are organized). So I never use it myself; Go is fast enough for anything I do and 10X easier to write in.

This is exactly the opposite of my experience. Refactoring stuff without breaking anything tends to be extremely easy in rust. The language is very strictly typed but at the same time is implicitly typed. Sticking to implicit typing whenever possible makes it dead simple to change multiple things from values to pointers, or vice versa.

That, combined with probably the best tooling of any language, makes it so easy to rapidly prototype from scratch. Rust-analyzer in particular tends to make it easy to figure

Re:

[Local ID10T]

OK. That is a real answer. Thank you.

Re:

[UnknowingFool]

The problem is you view Rust advocates as thinking Rust is some sort of savior; it is merely a better tool in certain cases.

Re:

[monkeyxpress]

They have never answered the big question. WHY learn Rust?

IMHO, it's yet another attempt at 'one language to rule them all'. After 20+ years of programming everything from 8-bit micros in assembler to webapps, I just think you can't really cover the entire problem-space easily with a single language. C++ is our best attempt, and most of the criticisms it has are precisely because it is trying to do so much (and I actually think it does this pretty well - it's just so unwieldy that you need exceptional programers to be able to work with it).

C is unparalleled when y

Re:

[UnknowingFool]

IMHO, it's yet another attempt at 'one language to rule them all'.

And that’s where you went wrong. Rust was designed to be a replacement for C with enhancements to things like memory safety. It was not an attempt to replace Python, Javascript, Java, .etc to "rule them all." In some cases it can replace C++.

Re:

[UnknowingFool]

Many have already answered that question; people still refuse to acknowledge that C has major flaws that Rust was designed to overcome. Memory safety and performance are major advantages. Whether those are worth it to switch existing code to Rust is an opinion, pretending those are not advantages is denialism.

Re:

[UnknowingFool]

So are you saying that no one should advocate for something that they like? By your logic, I should stop advocating AMD desktop CPUs over Intel to people who have little experience with computer infrastructure. Most of the general public knows about Intel CPUs; everyone has time to do all the their own research.

Re:

[HBI]

No, i'm saying I am personally deterred from looking at something because someone is hopping up and down advocating it.

I presume there's a reason why and it isn't for my benefit, its for the advocate's benefit. There's a downside to advocacy and I just encapsulated it.

This is why in recovery you learn to answer questions only when asked and to stop volunteering shit. People don't want to hear it which is why they generally hate advertising.

Re:

[UnknowingFool]

No, i'm saying I am personally deterred from looking at something because someone is hopping up and down advocating it.

And that is your perspective on what is happening. I rarely see developers hopping up and down on Rust. They are recommending it. They are using it. It solves problems just any new tool. Because it solves problems, Linux (after years of consideration) included it an option in the kernel. They are not mandating that everyone switch to Rust.

I presume there's a reason why and it isn't for my benefit, its for the advocate's benefit. There's a downside to advocacy and I just encapsulated it.

So you don't have any need for something yet are advocating against something because you do not have a benefit? Is that rather not selfish and arrogant? That's like sayin

Re:

[quonset]

Trained" is what dishwashers are, programmers are educated...and experienced.

What do you think training means [merriam-webster.com]?

a : the act, process, or method of one that trains
b : the skill, knowledge, or experience acquired by one that trains

And what does train mean [merriam-webster.com]?

1
a : to teach so as to make fit, qualified, or proficient
b : to form by instruction, discipline, or drill

Apparently in your world programmers create their crap through breathing and not by any sort of training.

Re:

[jythie]

They don't want educated, experienced developers. They want to grow rust with a little deviation from their way of doing things as possible. Rust programmers are a tool, not tool makers.

Re:

[UnknowingFool]

Since when are programmers "trained"? "Trained" is what dishwashers are, programmers are educated...and experienced.

[sarcasm] Because no fresh of out college programmer ever needs training. Those kids know everything and can solve any problem created by years of institutional complexity or obsolete hardware. Heck no one ever needs training in any profession. Teachers enter schools with everything they need. Firefighters have seen every kind of fire there is in their time at the academy.[/sarcasm]

Re:

[UnknowingFool]

Have any of these people ever had to maintain a Rust project? I have and it's a nightmare reminiscent of Scala or OCaml.

Perhaps you should ask Mozilla, Google, Amazon, Microsoft, Meta, Dropbox, etc. It seems that large corporations have used it in their projects.

I will refuse to learn Rust

[jrnvk]

Just like the rust aficionados refused to learn safe C coding principles.

Re:

[swillden]

Just like the rust aficionados refused to learn safe C coding principles.

The Rust afficionados are well aware of safe C coding principles... and we have decades of evidence that relying on programmers to follow them is a great way to have lots of memory safety bugs. And, no, it doesn't matter how much you pay said programmers, or how experienced they are. More experience, more expensive programmers write fewer memory safety bugs, they (we!) still write bugs.

I've been writing C and C++ since 1988. Since its inception in 2001 I've been a big fan of Modern C++, because its heav

Re: I will refuse to learn Rust

[fluffernutter]

Just use smart pointers and all the problems go away.

Re:

[jythie]

Or any number of static code analysis packages... which is all rust really is.... except users can not decide which rules it is configured with or override it... which is the dream of a certain kind of programmer, one who does not want users to deviate from their perfect plan. Not surprising it is coming out of the same communities who built web pages and apps that slowly removed options and functionality because 'then users would use it wrong!'

Re:

[swillden]

Or any number of static code analysis packages... which is all rust really is.... except users can not decide which rules it is configured with or override it... which is the dream of a certain kind of programmer, one who does not want users to deviate from their perfect plan. Not surprising it is coming out of the same communities who built web pages and apps that slowly removed options and functionality because 'then users would use it wrong!'

Tell me you haven't actually used Rust without telling me...

Re:

[swillden]

Just use smart pointers and all the problems go away.

That's the Modern C++ theory. But it really doesn't work, and there is mountains of evidence that it does not.

Re:

[phantomfive]

Why doesn't it work? Do developers use smart pointers in different ways? Is it because libraries don't always use smart pointers? Is it a deficiency in the smart pointer standard library? (Or is it because some companies invented their own type of smart pointer?)

Re: I will refuse to learn Rust

[Waffle Iron]

You don't even need pointers to crash C++:

#include <stdio.h>
#include <vector>
 
int main() {
    std::vector<int> v = {1, 2, 3, 4, 5, 6, 7, 8, 9};
    for (auto i : v) {
        if (i % 2 == 0) {
            v.push_back(i + 10);
        }
        printf("%d\n", i);
    }
 
    return 0;
}
 
$ g++ -Wall -pedantic t.cpp && ./a.out
1
2
418206662
-3296083
5
6
7
8
9

Re:

[phantomfive]

I don't understand what is going on there, but it looks cool. Pedantically, any language can crash.

Re:

[Waffle Iron]

The problem is, too many C++ developers also don't understand that example. It spotlights just one of the scores of byzantine rules that you must always follow, even if the container and iterator live in different areas of the code and interact indirectly through layers of abstraction.

Rust doesn't allow this bug because its PITA borrow checker rules won't let you mutate a container while an iterator is alive anywhere. There are hundreds of other types of undefined behavior and corner cases that C++ smart po

Re:

[loonycyborg]

C++ adding safety features is like building a submarine out of a frame of old pallets and chicken wire, then trying to make it watertight by wrapping on more and more masking tape. You're never going to plug all the leaks.

This is your personal fantasy. I'm skipping Rust exactly because of obnoxious rants like this. I'd sooner do memory safe C++ or any other language that is "memory safe" according to some definition. Such as various functional ones.

Re:

[Waffle Iron]

I'd sooner do memory safe C++

As I pointed out and just demonstrated with a concrete example, that's an oxymoron

or any other language that is "memory safe" according to some definition. Such as various functional ones.

That's actually what I do. The tradeoff, however, is almost always at least 50% speed penalty. Functional languages are usually even slower. But very few problems actually need maximum possible speed, especially over more than one critical hotspot.

Re:

[loonycyborg]

I see no reason to learn rust. I only like two things about C++: having C subset for easily using C libs and template metaprogramming. Rust has neither. I accepted lack of memory safety to be inherent property of system programming and the fact that chasing memory safety would make me give up things I like about C++ proves this from my pov. If safe C++ would be good enough then it would disprove it.

Re:

[Waffle Iron]

Fine. You're happy writing shoddy code. Let's just hope they don't let you work on anything important.

Re:

[loonycyborg]

I don't buy it that not using Rust automatically makes my code shoddy. Using such poor argumentation gives Rust a bad name. Good way to make it die a horrible death like thousands of other languages before. I bet COBOL will outlive it.

Re:

[bill_mcgonigle]

Thanks for the technical explanation. Very helpful for a compiler nerd.

One long-time C++ contributor who recently gave a presentation on a C++ undefined behavior just got banned from that community for life for his paper.

It tells me all I need to know about the odds of C++ being the future for anything but maintenance code or where Rust bindings are not available in very simple projects.

Also the angry posters here who've never tried out the language - all the comments from actual users are pleasantly worded

Re:

[phantomfive]

Thanks

Re:

[caseih]

Surely every programmer is taught that changing an object while iterating over it is a no no. That's one of the first things I learned when exposed to container types in a whole bunch of different languages. Nice that rust detects that at compile time.

Re:

[Waffle Iron]

But it's not always a no no. In this case, it would be just fine for std::list and std::map. The developer has to mentally keep track of all these implicit rules at all times.

Unfortunately, the standard library was intentionally designed so that you can easily swap out the container type without changing other code. Thus, somebody can introduce this bug unwittingly after the fact.

Re: I will refuse to learn Rust

[Entrope]

It's UB to modify a vector while iterating over it with a for-range loop. Depending on the intended behavior, either iterate by index (so modifications are encountered during the loop) or build a helper array and append that after the loop (so modifications are not encountered during the loop).

Re:

[swillden]

It's UB to modify a vector while iterating over it with a for-range loop. Depending on the intended behavior, either iterate by index (so modifications are encountered during the loop) or build a helper array and append that after the loop (so modifications are not encountered during the loop).

Indeed, and the C and C++ specifications are chock full of undefined behavior corner cases, many of which only language lawyers understand.

Safe Rust code is not allowed to execute undefined behavior. The compiler will give you an error. Note that "panic!" is not UB, it's a very well-defined crash :)

Re:

[phantomfive]

Words have meanings.

ML is fully defined as a programming language. Every corner case.
C++ and C are mostly defined.
Rust is not defined, it has an implementation. Literally every part of Rust is undefined behavior.

Also, Rust can crash, try this program [pastebin.com].

Compiles fine, crashes quickly. Rust ensures memory correctness, not program correctness.

Re:

[swillden]

Rust is not defined, it has an implementation. Literally every part of Rust is undefined behavior.

LOL. Yes, the formal specification is still being written. The reference is an adequate substitute for the time being.

C++ and C are mostly defined.

They have specifications, yes... specs that are chock full of undefined behavior caveats that most users of the languages don't know exist. On balance, the informal specification of Rust is far easier and safer to work with than the well-defined piles of razor blades that are C and C++.

Also, Rust can crash, try this program

That doesn't crash, it panics. Safely, cleanly. As I said: 'Note that "panic!" is not UB'.

Also, what a w

Re:

[swillden]

Also, Rust can crash, try this program [pastebin.com].

While on the topic, I should point out that this one [rust-lang.org] also panics, and it's marvelous that it does... we'd have far fewer security bugs if C and C++ specified that similar programs invoked undefined behavior like they do for division by zero (even better if they were defined to abort safely rather than resorting to "undefined behavior").

Re:

[swillden]

I don't understand what is going on there, but it looks cool. Pedantically, any language can crash.

Rust can't, unless you call "panic!" or something that calls "panic!", or use unsafe code. Or unless the compiler has a bug.

Re:

[fluffernutter]

How could anyone think that is a good thing to do? Since we are using obviously bad things to do as an example, I could probably use 'unsafe' in Rust and break it too. Using unsafe in Rust is just as obviously a bad idea as that is.

Re:

[Waffle Iron]

It's not obvious at all. It's not even bad if you use std::list as the container instead of std::vector. And as I pointed out in response to another reply, the iterator and container may not even be in the same part of the code, but separated by layers of abstraction. The coder(s) could be totally unaware of the risks.

Re:

[fluffernutter]

You clearly weren't trained properly. Do you have a degree in Comp Sci?

Re:

[ZipNada]

I don't know much about Rust use cases. It sounds like a mainly back-end language like Java? What sorts of things is it good for?

Re:

[phantomfive]

The Rust use case is to replace C++ everywhere it is found.

Re:

[SoftwareArtist]

The main use cases for Rust are the same as the ones for C++.

1. When you want the absolute fastest performance possible, and you're willing to do extra work to get it.
2. When you need low level access, like for writing device drivers.

In those cases, Rust is a much better choice than C++. Also like C++, it isn't limited to just those cases. You can use it for any kind of program. But if you want a general purpose language that sacrifices a little speed for easier development, something like Kotlin or Swif

Re:

[phantomfive]

Don't worry. 10 years after they 'train' all these Rust developers, you'll hear plenty of complaints about Rust programmers who refuse to learn safe Rust coding principles.

Re:

[UnknowingFool]

And how would they do that when it is baked into the language?

Re:

[phantomfive]

Rust only has guarantees about memory safety. It doesn't guarantee program correctness.

Re:

[UnknowingFool]

Except that's not what you said. You said "you'll hear plenty of complaints about Rust programmers who refuse to learn safe Rust coding principles." Now you are changing it to "program correctness" when pointed out that you are wrong.

Re:

[phantomfive]

Yeah, you said "safe coding principles are baked into the language." But they aren't. Memory safety is baked into the language.

Do you think that memory safety is the only safe coding principle? Even if we are just talking about security, do you think that they only security bugs are memory bugs?

Re:

[UnknowingFool]

But they aren't. Memory safety is baked into the language. Do you think that memory safety is the only safe coding principle?

You basically contradicted yourself by saying safe coding principles are not baked into Rust while acknowledging memory safety IS a safe coding principle baked into Rust. You realize we can scroll up and read what you wrote, right? No one said memory safety is the only safe coding principle in Rust except you. Among other safe coding principles in Rust: strict static type system, ownership and borrowing rules, sandboxing, minimal runtime, etc. But I suspect you knew that and prefer to deny they exist.

Re:

[phantomfive]

Here's what I wrote:

"10 years after they 'train' all these Rust developers, you'll hear plenty of complaints about Rust programmers who refuse to learn safe Rust coding principles."

Are you going to disagree with that?

Re:

[UnknowingFool]

Are you going to disagree with that?

Are you going to ignore you keep changing what you are talking about with every post every time you are proven wrong? You first wrote about "safe coding principles" but when pointed out those are baked into the language, then you talk about "program correctness". When pointed out that is not what you said, then you contradicted yourself by saying Rust does not have any baked in safety while admitting memory safety is baked in safety . Now you are going back to your original point? What IS your point?

Re:

[UnknowingFool]

The reason for Rust is not the aficionados did not learn safe C principles. The reason is most C "aficionados" do not use safe C principles.

A healthy Rust ecosystem :o

[Mirnotoriety]

How about winTEL designing a decent MMU. That would not suffer from: Meltdown, Spectre, Foreshadow (L1TF), side-channel attacks, ASLR weaknesses and successfully isolate processes.