Citations needed for Rust history, industry context

For my Master's thesis, I need to write a brief introduction to Rust. The primary aim here is to convince my committee members that haven't encountered Rust before that it's worth paying attention to, before I dive into the technical details of my project.

The best way to do this is probably to cite significant Rust deployments and/or surveys that show broad adoption. Does anyone know of any good papers or blog posts along these lines I could work from?


How about this from the Microsoft Security Response Center:
"A proactive approach to more secure code" :

Or, from the same place, this:
"Why Rust for safe systems programming":

"We need a safer systems programming language":

From Amazon:
"Why AWS loves Rust, and how we’d like to help": Why AWS loves Rust, and how we’d like to help | AWS Open Source Blog


I con't help thinking that the best introduction to Rust for an audience of experienced programmers is some actual code that demonstrates its awesome powers of enforcing correctness.

It would only take a few lines of simple C++ to demonstrate the problems of:

Using uninitialised data,
Use after free.
Double free.
Race condition.
Array bound violation.
Type coercion problems.

and the corresponding few lines of Rust to demonstrate how it won't even let that kind of thing compile, and how to do it properly.

Whilst pointing out that performance is comparable to C/C++ and free of garbage collection stalls.

If that does not get them salivating immediately then it's possible you are in the wrong institution.


Here's one success story and here's another one.


I agree, and I've got a much longer section already discussing these problems and Rust's solutions to them. But my project is fundamentally a library that is only useful for Rust programmers. If I don't make at least a pro forma effort to show this is a significant group of people, I haven't shown that the project is actually useful vs. an interesting thought experiment.


These two come to mind:


This will depend on the kind of Master's thesis you are doing, but where I work we emphasise research as part of a more academic thesis. So I wouldn't mind seeing a library that only two people in the world might ever run, so long as there was some property that was novel/interesting.

Perhaps you can cite some academic papers, that illustrate problems that your library overcomes using Rust? A quick look on google scholar shows several recent papers discussing Rust's type system and safety promises in different settings.


I'm doing this also, though the papers are quite old (1970's). The central argument I'm making is that Parnas' paper introducing information hiding and Codd's paper introducing relational algebra were both attempts to solve the same problem in different domains. The largest piece of demonstrating this is writing a relational algebra library for general-purpose programming. I then show that it addresses the same problems that Parnas describes through a small case study.

This bit of literature review is only to help me write the introduction to the chapter that provides a minimal overview of Rust-- Just enough to make the rest of the paper intelligible.

You are in good company. Some have trodden this road before.

Jon Gjengset recently completed his Phd. Years of work all done in Rust. His defence is online here: "Thesis: Partial State in Dataflow-Based Materialized Views": Thesis: Partial State in Dataflow-Based Materialized Views - YouTube. It was novel, to me at least, that he went through his defence presentation on YouTube and solicited feed back prior to the real thing.

There are undergrad CS courses teaching Rust. For example:
CS196 at Illinois

I don't know if any of that helps.

Parsing logs 230x faster with Rust

Good grief! That's certainly an improvement worth casually mentioning at the weekly meeting.


1 Like

I find it somewhat disturbing that there are teams of programmers out there who are surprised to find that a compiled language can be orders of magnitude quicker than an interpreted one.

1 Like


I'm pretty sure that's not the case, i.e. it's not the lack of technical knowledge of being able to tell which one is faster. Rather, it's probably a cultural thing. Nowadays, it's pretty fashionable to write web apps (and more) in dynamic languages, because the industry promotes the fast and loose way of doing things in general. JavaScript, microservices, Agile™, fast prototyping (that inevitably ends up in production), you name it – it's all good intentions, often going haywire.

(And in the workplace, there's the "it's so much easier and faster to write" hammer too, which appeals to higher management so much. But then again, higher management aren't the ones to debug the fast-to-write code after the damage has been done :sweat_smile:)

The rising popularity of IT and programming as a prospective career path also plays an important role in this change. It's easier to teach newcomers using dynamic scripting languages – they don't need to know what a compiler is or why they would need one, they don't need to learn about formal types, only some very basic, unwritten intuition thereof, and they don't need to be introduced to the concept of functions on day 0.

It's a shame, however, that so many courses, programmes, universities, freelancer teachers, etc. in this field don't offer or emphasize follow-up material, with which people could learn at least one statically-typed language. As a part of my doctoral studies, I am required to teach undergrad and graduate courses as well, and my fellow PhD students and I equally feel that such knowledge about basic computer architecture, systems programming, and a formal notion of types is sorely missing from curricula at universities and elsewhere.

(Then, of course, there are the universities at the other extreme, those who mistake IT for pure mathematics, and teach nothing but discrete math and type theory for 6 semesters. That ain't doing any good, either.)



All sounds true to me.

My perspective comes from having been introduced to programming as a young teenager with BASIC. But in that same course we were expected to also learn assembler. Along with gaining some understanding of processor operation and computer architecture, numerical analysis and statistics. Soon after that it was Algol and entering the work place programming in assembler, then Coral, then C then ...

A slightly later generation grew up with BASIC on their C64s and such and if they were serious about programming soon discovered they needed assembler to get any performance. Or even fit the code into the space available.

As such I was at a loss when Java arrived. I could hardly bring myself to believe anyone would use an instruction set emulator and a garbage collected language for anything serious. Why for goodness sake? It's going to be so slow and bloated. I thought. I could not see any reason for Java's existence.

I had to be dragged kicking and screaming to even think about using Javascript a few years ago. For similar reasons. Luckily JS engine performance had improved substantially in recent years and it turn out JS is a nicely different and sophisticated language.

Hence I wonder how people can be so surprised at the performance of a compiled language. What went wrong? How did they miss so much in their studies of CS and or just programming?

Luckily Rust seems to have sparked a lot of interest among those users of interpreted, dynamic languages where the likes of C and C++ never did.

1 Like

For my bachelor theses, I'd mention the survey of stackoverflow and the consecutive years that Rust has won the "The most loved language"

For five years running, Rust has taken the top spot as the most loved programming language

Maybe that is something you could mention, what do you think?

I don't know if one can site a video on YouTube in a masters thesis but here is
Ryan Levick talking about the adoption of Rust at Microsoft and the motivation to do so:

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.