Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Designing a New Rust Class at Stanford: Safety in Systems Programming

reberhardt.com

Post reply on HN
Print view View original

31–40 of 53 posts

Re: Designing a New Rust Class at Stanford: Safety in Systems Programming

#31

Post by ksml »

mjb wrote: post #20

Teaching a class about safety in systems code seems like a great idea, and at first glance the class content here seems useful and interesting. I do a lot of OS-level stuff at work (especially around virtualization and Firecracker), and while safety (and security) are obviously a critical topic for industrial systems, they don't tend to be things that new grads have thought about at all. Great to see that changing (e…

> 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 agree, but C++ doesn't force you to write good, modern code, and so in lecture, we are better able to show examples of bad code that well-intentioned people might write and discuss the consequences. Also, you can't directly make syscalls in Rust without using "unsafe" or a library, and it's harder for students to see how programs interact with the kernel when that extra stuff is in the way.

I'm checking out Firecracker right now, and it looks like a really neat project! I'd love to talk more about virtualization in the class, especially since I feel that our current curriculum doesn't spend as much time preparing students for the modern cloud computing architectures they are bound to work with. Curious: can you think of any safety issues you've encountered in Rust or bizarre bugs that Rust's type system didn't save you from? Those often make great lecture examples, and while we always remind students that Rust is not a panacea, I don't think we had any good concrete examples.

Re: Designing a New Rust Class at Stanford: Safety in Systems Programming

#32

Post by driest »

ksml wrote: post #2

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…

Great class, thanks for sharing the materials. Would you consider also making the code for the exercises available? I'm working through the slides but the exercises are hard to follow without the provided source code.

Re: Designing a New Rust Class at Stanford: Safety in Systems Programming

#35

Post by ksml »

driest wrote: post #32
ksml wrote: post #2

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…

Great class, thanks for sharing the materials. Would you consider also making the code for the exercises available? I'm working through the slides but the exercises are hard to follow without the provided source code.

Yes! It's now available here: https://github.com/reberhardt7/cs110l-spr-2020-starter-code

Re: Designing a New Rust Class at Stanford: Safety in Systems Programming

#36

Post by ksml »

vikiomega9 wrote: post #34

I don't see a focus on testing in this course. Was that by design? I feel like a lot of design out there forgets this important implementation detail.

No, it wasn't by design, but we just didn't have time to talk about it. I talked about testing extremely briefly in one lecture, but I think we will spend more time on this next time we teach the class.

Designing this class was hard because there's just so much stuff out there to talk about, and not enough time... Did you see any topic we covered that you think we could do without and talk about testing instead?

Re: Designing a New Rust Class at Stanford: Safety in Systems Programming

#37

Post by spr93 »

ksml wrote: post #28
renox wrote: post #23

There's more to safety in system programming than "use Rust".. What about Ada/Spark ? Fuzzing?

That's true, but we only have 10 weeks in a quarter, and this class isn't many units so there isn't much time in every week. In the blog post, I explain our rationale for focusing on Rust even though I'm aware there are many other things we could talk about. Primarily, I think Rust encourages good programming practices, and, by working through practical assignments, students are able to develop better habits and have…

That's excellent, and Rust makes perfect sense here. But consider that OP has an important point (though not said very diplomatically): Ada/SPARK has decades of experience and research in safety, especially type safety, which has not received the same level of focus in Rust as memory safety has. In addition, Ada was the vehicle for many years (and still is in some places) for teaching systems safety and mission-critical programming.

You should consider familiarizing yourself with some of that Ada/SPARK research, experience, and pedagogy. The issues you're teaching aren't new, and there's a huge body of knowledge, experience, and anecdotes you may find useful or inspiration.

A couple ideas to get you started-- - "Safe and Secure Software" - https://www.adacore.com/uploads_gems/Ada_Safe_and_Secure_Boo...

- "Safe Dynamic Memory Management in Ada and SPARK." Quote from its first page: "As our main contribution, we show how to adapt the ideas underlying the safe pointers from permission-based languages like Rust or ParaSail, to safely restrict the use of pointers in more traditional imperative languages like Ada." - https://www.adacore.com/uploads/techPapers/Safe-Dynamic-Memo...

- The Ada Information Clearinghouse - https://www.adaic.org/advantages/

Rust is new and important and it's great that it's the focus of your course. But I also think you would do your students a service to show them that they can stand on the shoulders of giants in comp sci just as much as any other discipline. Much as the industry has moved back to what was fundamentally the IBM mainframe remote-system-and-virtual-machines service and licensing model [now we call them clouds, containers, and SaaS subscriptions], Rust is a relatively recent response to the same problems Ada/SPARK have decades of experience in handling. The lessons the industry and comp sci researchers learned 30 or 40 years ago do matter, and they can show us what kinds of solutions work and what may have have unforeseen effects.

The Ada Reference Manual and SPARK are under-appreciated tomes of the world's experience in these issues.

Re: Designing a New Rust Class at Stanford: Safety in Systems Programming

#38

Post by ksml »

spr93 wrote: post #37
ksml wrote: post #28

Earlier quoted context omitted.

That's true, but we only have 10 weeks in a quarter, and this class isn't many units so there isn't much time in every week. In the blog post, I explain our rationale for focusing on Rust even though I'm aware there are many other things we could talk about. Primarily, I think Rust encourages good programming practices, and, by working through practical assignments, students are able to develop better habits and have…

That's excellent, and Rust makes perfect sense here. But consider that OP has an important point (though not said very diplomatically): Ada/SPARK has decades of experience and research in safety, especially type safety, which has not received the same level of focus in Rust as memory safety has. In addition, Ada was the vehicle for many years (and still is in some places) for teaching systems safety and mission-criti…

Thanks a lot for these helpful links! don't know much about Ada/SPARK but will spend some time going through these resources.

Re: Designing a New Rust Class at Stanford: Safety in Systems Programming

#39

Post by vladf »

eska wrote: post #24
andy99 wrote: post #19

Earlier quoted context omitted.

From what I understand reading the course outline, this is an introductory class. Foundational material in a subject is often "completely disconnected" from the reality of the discipline. If I was an engineer taking a first course in integral calculus, should I worry that my teacher may not be a seasoned practitioner, or should I worry that they are good at getting me to understand the fundamentals? I can definitely…

I think you should worry. One of my math professors taught us how factoring to a (x+b (x+c*(...))) is a great optimization in an introductory class, because he had no idea about CPU pipelines for example.

Horner’s method for polynomial evaluation is used because of numerical stability, not speed.

Re: Designing a New Rust Class at Stanford: Safety in Systems Programming

#40

Post by musicale »

These comments struck me as particularly damning:

> As people usually say, Rust has a steep learning curve, and it’s really hard to get productive with it in a short amount of time. This is reflected in the 2019 Rust language survey, and it’s also reflected in the student frustration in the first few weeks of our weekly survey responses

> While I think Rust would be poorly motivated in CS 107, I think it is extra poorly suited for CS 110.

I have essentially no experience with Rust, and I want to like it. But I get the feeling that it isn't very user-friendly and that I would enjoy it much less than other memory safe languages like Swift, Go or Java or even sharper-edged languages like C++ with smart pointers or Objective-C with ARC.

Also given the large body of legacy C/C++ code still in use and development, I'm disappointed that clang still doesn't seem to support a memory-safe mode/ABI, as it could eliminate a large class of errors.

Maybe Unix made a critical error by adopting and promoting unsafe C; its predecessor Multics, written in PL/I, had essentially zero buffer, heap, or stack overflows over its entire lifetime (though it probably still had race conditions and concurrency errors.) ;-)

Post reply on HN