11–20 of 53 posts
Hi HN, I spent last spring working on a new class at Stanford that's focused on common pitfalls in systems programming and how to avoid them. You can check out all the lecture materials (including recorded lecture videos) and assignments available here: http://cs110l.stanford.edu/ I'm planning on teaching this class again in the winter or spring and am looking for any feedback to improve it. I would love to hear your…
Hi HN, I spent last spring working on a new class at Stanford that's focused on common pitfalls in systems programming and how to avoid them. You can check out all the lecture materials (including recorded lecture videos) and assignments available here: http://cs110l.stanford.edu/ I'm planning on teaching this class again in the winter or spring and am looking for any feedback to improve it. I would love to hear your…
Hi HN, I spent last spring working on a new class at Stanford that's focused on common pitfalls in systems programming and how to avoid them. You can check out all the lecture materials (including recorded lecture videos) and assignments available here: http://cs110l.stanford.edu/ I'm planning on teaching this class again in the winter or spring and am looking for any feedback to improve it. I would love to hear your…
Looking ahead, new students are going to have to deal in future with huge numbers of CPU cores. So they need to deal with large numbers of threads. That's very hard to do well. This class addresses not just safety, but performance. That's good.
This is so far ahead of what I got from Stanford in 1985.
(I have some arguments with the Rust people, mostly around over-use of "unsafe" and too much language churn, but they're doing great work.)
I wonder if either of the two teachers have actually worked on a large system before.
This comes across as really harsh. Did you mean to come across that way?
I wonder if either of the two teachers have actually worked on a large system before.
Hi HN, I spent last spring working on a new class at Stanford that's focused on common pitfalls in systems programming and how to avoid them. You can check out all the lecture materials (including recorded lecture videos) and assignments available here: http://cs110l.stanford.edu/ I'm planning on teaching this class again in the winter or spring and am looking for any feedback to improve it. I would love to hear your…
This is a step forward. I've been pushing for more language safety for what, decades, and it's good to see Stanford teaching it. It's important that students understand ownership concepts, because they exist in C, but the language doesn't give you any help in dealing with ownership. For years, I've been saying about C that the big questions are "how big is it?", "who deletes it?", and "who locks it?". Rust addresses…
Earlier quoted context omitted.
This comes across as really harsh. Did you mean to come across that way?
I don't think it's harsh. It is a reasonable question to ask. Academia is rife with people who have never worked in the industry, completely disconnected from reality.
> CS 110 [multiprocessing, multithreading, and networking in C++] is not just about how we do things, but also why – why are things designed the way they are, and if we get certain bugs or performance characteristics, why is that?
That's an interesting take, because I don't see Rust as being more abstracted in this way than C++ is. Obviously it's more abstracted than C, but by the time you get to "modern" C++ you're programming in a much higher-level language than C.
> I also think it’s hard for students to appreciate Rust without having first experienced C and C++.
This part does make sense. Explaining the "why can't we just write C really carefully?" piece to people who haven't experienced trying to do that is going to be harder. As we all know, it is possible to write safe C, but it takes a level of discipline and tooling support that is beyond most undergrads.
> that looks at what is often going wrong in systems and how we can improve practices to build better systems.
I'd love to see more research here too. There's some systematic studies of the causes of bugs in systems code, and obviously a lot of well-known bug patterns (see all of C's string handling). On the other hand, there seems to be fairly little research on the causes of more pernicious and subtle problems that become vulnerabilities (and data corruption, crashes, etc) in systems code.