Designing a New Rust Class at Stanford: Safety in Systems Programming • Hacker News Board

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

#41

Post by dataking » Thu, Oct 08, 2020, 3:03 AM UTC

musicale wrote: post #40

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 poo…

Compilers such as clang/LLVM and GCC do support a memory-safe mode (e.g. AddressSanitizer) which is not what you want because they add large overheads and thus are not intended for production use.

There's an ongoing effort to design extensions to C that allows efficient enforcement of memory safety, Checked C from Microsoft Research is an interesting and current effort in this direction.

For all the challenges of getting comfortable with Rust (which I 100% acknowledge), it does provide a very interesting tradeoff between performance, safety, and compatibility with C.

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

#42

Post by divyahansg » Thu, Oct 08, 2020, 3:21 AM UTC

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 work Ryan! Love to see macros get their own lecture.

- your fellow 110 TA (and 240 TA I guess)

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

#43

Post by moonchild » Thu, Oct 08, 2020, 3:38 AM UTC

Rust is nice enough, but I'm not sure it's worth a university-level course on safe systems programming. There's a lot more of interest about ats[1]; f*[2] (specifically its 'low' subset); isabelle[3] (most notably used by the sel4 microkernel); et al.

1. http://www.ats-lang.org/

2. https://fstar-lang.org/

3. http://isabelle.in.tum.de/

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

#44

Post by eska » Thu, Oct 08, 2020, 3:49 AM UTC

musicale wrote: post #40

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 poo…

A couple of weeks of stifled productivity versus years of buggy, insecure, and inefficient software (e.g. because you'll be afraid to use asynchronous IO, threading, etc). I'll choose the former.

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

#45

Post by eska » Thu, Oct 08, 2020, 3:53 AM UTC

abalaji wrote: post #17

google234123 wrote: post #6

I wonder if either of the two teachers have actually worked on a large system before.

just because you have done something doesn't mean you can teach it and vice versa.

Just because somebody is a native speaker of English, doesn't mean they'd be good English teachers, true.

But somebody who only knows English from text books can't possibly teach it properly, no matter what.

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

#46

Post by ksml » Thu, Oct 08, 2020, 4:01 AM UTC

divyahansg wrote: post #42

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 work Ryan! Love to see macros get their own lecture. - your fellow 110 TA (and 240 TA I guess)

Hi Divya! Thanks for reading!!

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

#47

Post by SkyMarshal » Thu, Oct 08, 2020, 5:35 AM UTC

moonchild wrote: post #43

Rust is nice enough, but I'm not sure it's worth a university-level course on safe systems programming. There's a lot more of interest about ats[1]; f*[2] (specifically its 'low' subset); isabelle[3] (most notably used by the sel4 microkernel); et al. 1. http://www.ats-lang.org/ 2. https://fstar-lang.org/ 3. http://isabelle.in.tum.de/

This Rust course is a better intro to these topics for undergrads.

It serves the undergrads who want to learn languages popular in industry so they can get a job and hit the ground running, while teaching them how to make higher quality enterprise/startup apps.

And it's also a good intro to safe systems language design for the ones who want to make a research career in PLT, who will go on to study your list in more depth.

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

#48

Post by rcxdude » Thu, Oct 08, 2020, 10:56 AM UTC

dataking wrote: post #41

musicale wrote: post #40

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 poo…

Compilers such as clang/LLVM and GCC do support a memory-safe mode (e.g. AddressSanitizer) which is not what you want because they add large overheads and thus are not intended for production use. There's an ongoing effort to design extensions to C that allows efficient enforcement of memory safety, Checked C from Microsoft Research is an interesting and current effort in this direction. For all the challenges of get…

Asan and co are not just not intended/recommended for production use because of performance issues. They are designed as debugging aids, not security hardening features. As such they are likely to introduce security vulnerabilities, not prevent them (they effectively expose a larger attack area).

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

#49

Post by avinassh » Thu, Oct 08, 2020, 11:22 AM UTC

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…

Is there any plan of releasing all the videos? Lectures 15-18 do not have videos linked.

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

#50

Post by gregod » Thu, Oct 08, 2020, 1:36 PM UTC

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.

Could you elaborate?

I'm working on a project where the evaluation of a 4th degree polynomial is on the hot path. My micro benchmark (evaluating two polynomials + little bit of addition) shows that using simple Horner's rule is already somewhat faster, and implementing Horner's rule with fused-mul-add is more than twice as fast.