I was at RustConf, and Julia's talk was by far my favorite. It reminded this old, grizzled programmer how to approach programming with excitement and curiosity. I thought how much I'd love to show it to my wife, sister, parents, and every other person who thinks what I do is confusing, technical wizardry. I think it should be required watching in every highschool/college intro programming class.
It's frustrating but unfortunately all-too-common to see the number of posts in this thread subtly (or not-so-subtly) questioning the "seriousness" of the speaker. In my opinion, this talk is doing one of the most important things for Rust in particular and our industry in general: demonstrating that badass technology is not exclusively reserved for the Very Serious People of the world, but that enabling technologies and communities with the right attitude, like Rust, can unlock people's potential and give them opportunities that were otherwise unattainable for them.
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.
Thank you so much for saying this. I agree wholeheartedly and think this is a very important point to make. Really, the whole pattern of Why Don't You Know This Already is nothing but harmful. When someone learns something new and shares it, we shouldn't look down on them or demean them for not knowing it already. We all learn different things at different times, and not every CS program teaches the same things. Some are more math focused, some are more engineering focused, and even within those bounds there's space for a huge degree of variation. Let's not put people down because their degree didn't happen to teach something. Let's appreciate their excitement for learning that thing now.
My intention was not to attack the speaker or question their education. It is very clear that the speaker knows what she is talking about in her presentation.
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.
I can't speak for jvns, but for my degree, "UNIX BASICS" was essentially "Command-line basics" (an intro class), and Assembly was pretty much just the actual language syntax, registers, pointers, and interrupts. The word "syscall" might have been mentioned once or twice, but only in a hand-wavy, "don't worry about this right now" kind of way.
mainly just, "how to deference the address you just got to get the value you want." Might be covered under the "syntax" heading as well, but the concept was still gone over for those that hadn't quite grokked it yet.
I don't think syscalls are strictly part of Computer Science. They're an implementation detail of how we have collectively decided to write operating systems. As such, they're far more relevant to software engineering or computer engineering than computer science.
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?
I as well received a CS degree without ever hearing about syscalls. It's not especially surprising either, considering that computer science is essentially mathematics with some programming sprinkled in. Only one of my classes used C and assembly at all, and we used it to write an assembler, not to interface with an OS. The entire rest of the degree was in Java (with a single notable digression into Scheme).
Your sentiment about the relationship between computer science and math comes up often enough that I wrote a short essay about it. Computer Science is Not Math: https://news.ycombinator.com/item?id=3928276
There is an increasing distinction between computer scientists (math and algorithms) and software developers (implementation - your systems researcher and co).
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.
While I have seen such a distinction (see my sibling comment), I think it has peaked, and is on the decline. Furthermore, it has more often been outspoken members of one group excluding the other rather than systems researchers or theoreticians not calling themselves "computer scientists."
Computer Science often has a different curriculum depending on whether the CS program at the university grew out of its Math or Engineering department. I think this helps explain some of the wide variations in what is considered a "CS" degree.
We may be talking past each other - I am not talking about curriculum's, but the terms that those who do computer science research use to describe themselves. eximius made a claim I have seen no support for. All systems researchers that I know, including myself, consider ourselves computer scientists.
I have seen some schools try move to separate the theoreticians and experimentalists into CS and Software Engineering. I think this is just as stupid as calling physics experimentalists "engineers," but the field is young enough that I may be wrong.
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).
I have also seen some schools offer separate CS and Software Engineering degrees. That may make sense: physics and mechanical engineering are different departments, with different courses. But that is a separate distinction, as most systems researchers I know would tend to remain on the CS side.
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.
It's a little disappointing, really, but perfectly possible in my experience. The uni I'm doing my CS degree at also isn't exactly on top of its game when it comes to practical yet low-level stuff like this.
Its interesting that the more low-level engineering stuff isn't taught everywhere and that some people wish it was. My school was much heavier on the engineering side of CS (3 systems level courses that were required for undergrad and optional OS course, all of which discussed syscalls pretty extensively). A lot of people in my program hated it though and found it to be a serious barrier-to-graduation since it just did not make sense to some people who did OK with more higher level concepts.
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.
In the more theory-oriented departments this is possible.
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.
I don't think that it is. I know that at my university I only encountered anything with the OS in 3 elective classes (OS, UNIX system programming, and networks).
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.
> Lots of lower tier CS programs like mine seem to really just focus on popping out Java programmers that can work on enterprise systems.
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.
I don't think you know what a "shill" is. pcwalton works for Mozilla and is overtly working to advance Rust.
IMO it's probably valuable to learn C prior to rust but just because it's a much simpler language and its concepts seem like a prereq to understanding Rust's.
Golang might be a good hedge strictly because Google's weight may bring it to some great ubiquity in the future.
Sure, we all have only so many cycles to learn new concepts. But thank goodness none of these languages are mutually exclusive with one another.
EDIT: btw your suggestion elsewhere to google "rust sucks" yields many results about the game but few about the language.
Once upon a time C was not even an option for anyone without access to an UNIX workstation, other than dialects like RatC and SmallC.
Parallel to C, one should learn how to do systems programming in a *Pascal/Modula dialect, or Ada for something more modern, and see that systems programming doesn't need to be as painful as the C experience.
Bonus points if the degree makes use of something like mikroPascal or mikroBasic compilers from Mikroelektronika for bare metal programming.
Please do not make baseless accusations of shillage and astroturfing. If there are comments that you feel are being gamed, you can email us at hn@ycombinator.com and we can investigate.
Which is a shame, because a few of them do a pretty good job at visualizing the problem/information at hand. Unfortunately, they get drowned out by the sheer amount of images that serve no real purpose.
No. They almost always say ML or AI. An occasional exception is reinforcement learning but it's always same phrase. Most wont confuse this title with ML.
Thanks Julia!