Learning systems programming with Rust
jvns.ca
jvns.ca
Thanks Julia!
Nothing makes me more excited about Rust than its enabling potential, and this talk hits on all the most important themes. (In my own small way, I'm trying to help push on this Rust theme by helping the Rust subcommunity of language bridges, to create better on-ramps for programmers in other ecosystems to make use of Rust.)
I think it behooves all of us, particularly those of us who haven't had to deal with being a member of a class of people whose credentials are constantly questioned, to ask ourselves what unconscious biases may be causing us to doubt the validity of a presentation based on signifiers like "too many doodles" or "I happen not to have known <some specific fact>," instead of addressing the actual content.
But again, I just want to say that I am over the moon that this was the closing talk at RustConf. Rust could have no higher calling than to be an instrument of opportunity for new systems programmers.
I wrote this comment on this small detail in the talk as that surprised me. I am involved in teaching CS classes (yes, systems programming) at a university. Every undergrad student has to take these classes here in order get at least basic understanding of how a computer works, both hardware and software. And that does not only include CS students. Even in specialized courses such as Business or Health Informatics, Electrical Engineering, or Mechatronics, all students will have to pass at least one class in systems programming.
As I learned in this thread, my understanding of basic CS knowledge is different from what others learn in their university courses. When others describe in this thread how many math classes they had in their curriculum, this reminds me more of Applied Mathematics. Apparently, US universities also offer separate courses to get a degree in Computer Engineering. No such thing exists here in Germany, everything with computers is just "Informatik", and translated to English as "Computer Science" on the degree.
very roughly: 1. groups & rings, 2. linear algebra, 3. more groups & monoids & rings, 4. galois theory
for the analysis classes, very very roughly:
1. basics of analysis, the derivative, 2. the riemann integral, 3. metric spaces, 4. the lebesgue measure & integration
As Dijkstra once (supposedly) said, Computer Science is no more about computers than astronomy is about telescopes. You can be a computer scientist without ever even touching a computer (although I imagine these days most of us do anyway as a hobby). For example, my Computer Science PhD dissertation involves precisely zero lines of code. Following the astronomy analogy, I would place syscalls firmly within the telescope operating manual.
That said, almost every undergraduate CS program that I've seen contains a dose or two of software engineering. I learned about syscalls in my OS undergrad class, which was an elective to the major. I also learned about how to use version control such as GIT and Subversion in a non-elective CS class... also not CS in the strict sense, but hard to avoid I guess?
Just as originally computer science was 'just math', the very part of it that made it distinct may have become distinct enough to split off on its own.
I have also seen people from the theoretical branch say with a straight face that if you're using a computer, you're not doing computer science, and the field should probably be renamed because it's confusing as-is.
[edit]
The theoreticians who think experimentalism has no place in CS love to wield the quote "Computer science is not about machines, in the same way that astronomy is not about telescopes. There is an essential unity of mathematics and computer science" out-of-context to support this claim (It was in a paper about developing elementary-school CS curriculum).
The degrees we offer, however, are distinct from the research communities. Related of course, but still distinct. In the computer science research communities I pay attention to, I have seen no such trend.
Personally I really liked that stuff, it had a very mechanical aspect to it and even though I'm not a systems programmer I feel like it gave me a much more rounded understanding of a computer as a machine.
It's easy to assume that the parts of CS you understand well are the important parts. It's the converse of the Blub Paradox. Might there be things that other people consider fundamental that you're only passingly familiar with?
At the meta-level: contempt (like that you're expressing) is a bit risky: it can be hard to tell whether it's motivated by a desire to uphold high standards, or the need for a quick bump to the self-esteem from putting someone else down. If it comes too easily or too often, I'd worry it might be the latter.
I was present at the keynote. I've worked on debuggers of one sort or another (GDB, and the JavaScript-level debugging API for Mozilla's SpiderMonkey engine) for two decades now, and I thought the keynote was an awesome hack.
Finally: https://xkcd.com/1053/
Lots of lower tier CS programs like mine seem to really just focus on popping out Java programmers that can work on enterprise systems. Probably 33% of my graduating class fit that bill and went to work on low importance systems at a local bank.
Even in higher-quality ones, OS (and thus syscalls) may not be covered if the curriculum focuses mostly on, say, computational science, or PLT, or formal methods.
Learning systems as in machine learning or the default meaning