Final Survey
Here are responses to the final survey, with my comments.
What language do you think should be used to teach this class?
Note: No one selected 'No particular language - allow students to use any language they want and don't provide any starting code or reference solutions'.
Other:
either C, Rust, or D
no language, but teach rust and allow bonus on projects for using rust
Python or C
x86 and C
There is a mixed view on Rust, with lots of extremes (some people love it, others really hate it - see more below). I'm going to try Rust at least one semester, since I think many of the complaints are due to lack of documentation (which will be greatly improved next semester) and immaturity of the language (which is rapidly improving, but obviously has a very long way to go to be fully mature). I discuss this more in my course wrapup notes and several of the comments below.
Now that you have used it for a semester, how do you like Rust?
It was a different way to learn a programming language, and I think it was useful to learn how to learn this way. But I do not think I will choose to program in Rust until it becomes a more widely used language.
I like it conceptually, and its strength for parallelization, but I am still unsatisfied with its syntax, documentation, and error reporting, and I still find its handling of strings and pointers unintuitive.
I was much accepting of Rust after the release of Rust 0.8. I feel that the documentation for 0.8 was more complete than for previous versions. Rust as a language has its virtues. I'm especially fond of the option type. Whether Rust should replace C as the language for Operating systems is a question I don't think I can answer. Rust is certainly safer and it, or a language like it, may become the de facto systems language of the future, but I feel that until its fully developed (version 1.x) the language is difficult to use over a semester.
I really like the language. It's very efficient and functional, it definitely surprised me.
It's slowly growing on me, but I don't expect it to ever be my language of choice. I now prefer it to C, but wouldn't take a job where I had to use it every day.
I like it! Rust has influences of functional elements from Haskell, strong type safety from Java, and pointers from C/C++. I don't think I would be able to so easily implement Map Reduce in any other language.
I enjoy working with rust. I can appreciate the engineering that has gone in to prevent the programmer from doing stupid things in a minimally painful way.
I have enjoyed using rust. It makes thread management safe and easy which opens up new possibilities for splitting programs into concurrent threads. Some of its aspects are non-intuitive which leads to something of a learning curve but I have enjoyed it.
I didn't like it at first, as I still don't like working with undocumented, in development work. However, in retrospect, it was good practice for my expected future as a developer As for Rust itself, I'm enamored with it's goals and projected usefulness. I will definitely be continuing to follow its development. I love the idea of simpler concurrency, and the combination of functional and OO that is so powerful. However, due to its current state, trying to pick up the language and OS ideas simultaneously was especially difficult.
I think that the language itself has some very interesting concepts like smart pointers for easy GC and the task model for concurrency. I feel that the expressiveness and safety of the language have come at the cost of usability. I constantly feel the frustration of knowing exactly what I want to do, but being unable to express this in rust code whether due to confusion about ownership, clones, spawns etc.
Once it matures it has the potential to be a great language. For now, it's a bit awkward and underdocumented.
I really enjoyed using Rust and I think I will use it again in the future.
I think in concept, Rust is great because it handles a lot of safety and concurrence issues that would drive even the most expert coders crazy. However, I never really got a strong understanding of Rust, and I often struggled with the simplest things like dealing with pointers and new threads. I felt like I was spending more time figuring out Rust issues than actually learning about "operating systems". Overall I think it was good, the language is just not for me.
I think that Rust is a powerful and useful language, and I like many aspects of it (such as the memory protections it offers), but I don't think it is the best language to use to teach operating systems. I'm glad I got familiar with the language, though, and I hope it becomes popular down the road.
Until it's more stable in terms of release cycle, I probably won't be using it in personal projects.
I do not think that Rust is inherently bad, and I think it does good things (there are valid improvements it makes over C), but I am still absolutely against using Rust in this course (see 'more comments' below).
I like Rust and think it is a useful language but it was quite difficult to learn at first because of the limited documentation. It required a lot of time but was worthwhile in the end.
I must say, I understand rust more than when I started, and I did come to enjoy many of its features such as pattern matching. But the problems that I encountered in using rust were numerous.
I think it may turn into a great language, but in its current state using it for anything even slightly complicated is a nightmare. The idea of a compiler enforcing safety is appealing at first, but the requirements the compiler enforces restrict the programmers options too much compared to a C++ or Java. Despite the restrictions, it is still possible to get many bugs even after the code compiles, and while working on our project the code still crashed many times while running (and we had no "unsafe" blocks).
It has it's ups and downs. documentation could use work, its a bit inconsistent and frustrating. Some methods that are documented don't work. Other methods that aren't documented do work. I do like the safety of the language and the way somethings are implemented.
I understand how it helps, I like some of the functionality of it, but I really would never want to program more than a simple program in Rust. I can never see myself preferring Rust over another language, as it just doesn't seem ready yet by any means. However, it made me think differently, and I think that's a great goal of the course, and of the language, that was achieved.
I can see the advantages of Rust, but the main problems were the lack of documentation and the ever-changing versions. It could be a very useful language to use in the future once these are fixed. It's ability to do lower level programming does not outweigh the negatives, in my opinion.
I wouldn't say it was my favorite language but I would put it in top five right now.
Rust is actually really awesome! Although learning it is a pain I think as CS students we should be willing and able to learn new technologies. IN addition, it's cool to come in on basically the ground level of a language like this before it becomes popular and wide-spread.
I appreciate many aspects of the Rust language such as pattern matching and I really like what they did to remove the concept of null with the Option type. I think it is a very powerful language in that if you use it correctly, it can "guarantee" that certain types of bugs and vulnerabilities are eliminated. I am very excited to see how the language progresses when it is officially released and think that the way it handles processes and tasks conceptually makes it a great candidate for a language in an OS class.
Rust is an fascinating language. I like it because it challenges me to think about my code in a different way but I dislike how poor the documentation is. On multiple occasions I've had to drop by the IRC to get some esoteric line of code I was missing in order to get the core libraries to work (clone() for instance was a huge problem). It's not that I dislike talking to other people, experts even, but it's simply frustrating to spend 30-45 minutes trying to set one object equal to another. Now, that criticism aside, I think it has some admirable goals. After four semesters of Embedded Systems I have had quite a run around the block with C. Rust solves a lot of the problems I've had with C over time and for that I am absolutely thankful. I think in about a year this is going to be an amazing language. Until then, it's just a liiiittle hard to understand.
I enjoy it; it's familiar but uniquely its own. I found it fun to write in and I think it has a lot of potential.
I had a good impression of it since earlier on and still do. The language mixes imperative and functional programming features together well and learns well from its precedence. Even though I'm not a best judge to what I just said, I use the guideline that if the language makes me think somewhat differently, then it's not too bad.
This is too arcane. (I like the word arcane)
I do not enjoy coding in this language, and I definitely do not suggest teaching this to lower CS level students.
What is your biggest complaint about Rust as a programming language?
There is no documentation on it to help with development and completing the assignments-- I didn't like having to go to the chat room to find help.
Poorly documented, so that commands that are unintuitive are impossible to use.
Documentation/consistency across versions.
Documentation, of course.
There's so much overhead in getting nontrivial code to work. Pointers, lifetimes, and still-extant bugs really limit my expressiveness in the language. Also, the syntax is not pretty.
Instability between versions. Code broke when upgrading.
Better support at the beginning of the course would have been nice; explanations of major differences between versions, resolution of the std::io vs std::rt::io confusion, links to accurate docs, explanation of how to find a specific version of the source code in github. These were all stumbling blocks during the first few problem sets.
Lack of up-to-date example code. The official documentation provides up-to-date methods and fields but very little instruction in proper usage. This made some tasks such as reading from and writing to a file more difficult than they would have been in another language.
As I said above, its current developmental state makes it difficult to work with while trying to understand core OS concepts. Also, the complier is mostly unhelpful in its error messages, unless you know the underlying lingo.
No good string library. Lack of documentation about some of the design decisions made for the language. I feel that programming in rust is a much different paradigm than anything I've been exposed to previously. I wish that there was some sort of primer I had at the beginning that better described the intentions of the language designer and more of the common concurrency patterns in rust.
All the complaints one would have about a language that isn't finished. Lack of documentation Not enough code examples (tutorial didn't have many legal code snippets) Slow speed
I'm not convinced that Rust helped me learn about operating systems. Also the documentation is really sparse, and it was frustrating at times trying to find a solution.
I think it's probably the lack of documentation. There have been so many times when I wanted to do something simple and I assumed that it would be easy to implement, but there was no documentation for it and I had to struggle to find the answer.
The fact that it wasn't fully built out yet, and Rust calls sometimes had to be supplemented by calls to libc.
Documentation was not good enough to be used in a class where the topics are all new.
The syntax can be very confusing (more so than learning other new languages) - which isn't to say that that is the reason I did not like USING Rust for this course.
It's so new that there is not a lot of great documentation right now.
My biggest complaint is the stringency behind lifetimes without a very clear explanation as to how and when to use them for those who are new to the concept of lifetimes. There needs to be better resources and explanations as to when and how lifetimes should be used. I also have the same complaint about the concept of moving variables. This feature has very little explanation or resources available to learn about it. Overall, I would say that my biggest complaint about rust is a lack of a list of features that are unique to rust alongside of an explanation of best practices for each feature. More often than not I felt that the code I was writing was an inefficient mess written simply as an awkward way to get around a compiler error that I was encountering. As helpful as the IRC was, it is difficult to get an idea of the best way to do things using the features available in rust.
Rust falls into a horrible place where it is restrictive enough to be annoying and severely limit programming options, but the compiler isn't advanced enough to detect complicated problems. The result is a language which prevents you from being able to make some simple mistakes, but at the cost of spending more time getting code to compile. Overall I don't think the extra effort in getting things to compile has saved me any time debugging, since the compilation restrictions don't prevent the bugs that are actually hard to find and fix. Documentation
The lack of documentation, tutorials, and support without asking the developers directly in IRC. I know we had the ability to chart our course in Rust and write the documentation ourselves...but I feel like the lack of guides and documentation really hindered a lot of the learning for the assignments.
As a programming language, my biggest complaint is the lack of documentation. In terms of code, my biggest problem was the unexplained use of the colon to define variables and different items.
I felt like I spent too much time learning semantics or grammar, but that comes with the language at this point in its development.
Lack of examples, I actually think the documentation is OK. There just weren't many examples to build off of.
My biggest complaint is that some of the ways that the language is structured make for really terrible syntax and sometimes unreadable code. I mentioned before that I like pattern matching and the option type, however I think the syntax for the match on these types could be cleaner.
See the first question. It's still a little hard to read and use. Some code beautification / documentation is in order.
The module system seems kinda funky and I was never comfortable with how to structure imports (use statements) and mod inclusions.
Without a good understanding of move semantic and lifetime behavior, I feel that I bump into some errors too often and do not know how to fix them.
Just a learning curve
Too many safety features, and not enough documents!
What is your favorite feature of Rust as a programming language?
Ease of task spawning. Also the match {Some,None} syntax was nice
Strict typing and the Option type (I couldn't pick on)
Functionality.
I like the thought of Rust more than the language itself. That said, I think it taught me to think about programming a little differently - with safety as a concern - which I value as much as anything else I learned in the class.
The community. Asking questions on the IRC was such a pleasant experience!
Tasks and streams are great. The approach to genericity with traits is cool too, though I haven't looked too far into it.
The struct and trait system is easy to use and very powerful.
Easy(ish) concurrency. Functional principles (especially closures!).
I think the smart pointers are the most interesting.
The compiler, though extremely slow, had semi-useful feedback. If the clarification is increased further, it would be in the running for most useful compiler I've seen.
I really like the pattern matching syntax
I like the safety of the language a lot, but I'd say my favorite part is actually the IRC channel. The developers on the channel are so helpful and quick to respond, and even though the documentation could use some work, those people make it much more manageable.
Safe memory!
C bindings were excellent and has a great math library
Functional languages (or using the functional components of languages) is new to me, and therefore interesting.
I like how it is safe and much less likely to crash compared to a language like C or C++.
Result objects, Option objects, and pattern matching are my favorite features of rust by far.
Spawning new tasks and passing data into them with ports and chans is much easier in Rust than in other languages I've seen. Tasks are one feature I think the Rust devs got almost exactly right.
I was pretty impressed with the do statements and closures. It took me a while to figure it out, as I hadn't seen it before, but I like it now.
For some reason, the method of spawning new processes made more sense to me in Rust than in other languages. This could have been because the method calls to spawn processes had better syntax and used more descriptive language.
How it forces you to code well because it really hates anything remotely unsafe.
Its security. Not having to worry about buffer overflows, null pointers and the like is really cool. It's kind of a no-brainer to build a language like this.
I think my three favorite features are pattern matching, the option type, and how easy it is to spawn threads safely.
Concurrency is SO EASY. Oh my goodness. I had never really understood how to do it in C but in Rust it's a snap. Getting concurrency in my raytracer was much easier than I thought it would be.
The ease of pattern matching, Option<>, and the functional style present in some of the syntax (ie. do)
Type inference (which many new programming languages seem to have nowadays) and strong type system. The latter makes me want to explore Haskell. Also, this is not a feature, but I feel that adding a semicolon to change an expression to a statement is novel and elegant.
Better pointer than C
It looks a lot like C.
How much did you use the #rust IRC?
Do you expect to use Rust after this class?
Other:
Possibly, I may wait until the release of Rust 1.0 so that I can develop without worrying about deprectated features breaking my code.
I hope to use it eventually, but probably won't be using it immediately
If i must
In the near future, probably not. But I want to play around with it in the future once it's more developed.
maybe
maybe after documentation gets straigtened out
Problem Sets
How many structured problem sets should this course have?
Despite these results, I'm inclined to add a fourth problem set for next semester, that will get at some of the lower-level aspects of implementing an operating system. I believe it will be possible to do this while still leaving sufficient time for interesting open-ended project by slightly compressing the time for the first three problem sets. (There is also more effective time in the Spring semester, because the scheduling is much more conducive to final projects with Spring Break in the middle of the semester compared to the late Thanksgiving holiday in the fall.)
How much starting code and direction should the problem sets include?
What would be a good topic for a problem set?
I think a problem set to do with process synchronization would be interesting. mock scheduling?
http://blog.theincredibleholk.org/blog/2013/11/18/booting-to-rust/
I think that building a very simple operating system ourselves would be interesting.
Anything that requires students to get their hands dirty with the low-level aspects of making a process-- virtual memory and forking.
Classes
How do you think class time should be used?
There's been a tremendous amount of hype about how bad lectures are, to the point where our Dean includes a question on the official course evaluation form that disparages "traditional lectures". The responses here seem to confirm my belief that traditional lectures are still the best use of most class time (although I do have some sympathy for the no class time answer, and believe this should be an option for most students in most classes). The reason traditional lectures have a bad reputation is that it takes a ton of effort to make a good lecture, and faculty are encouraged to not speed enough time preparing lectures to do a semi-decent job, so most lectures are really bad.
Should we have regular (graded) quizzes?
Other:
I wouldnt say quizzes everyday-maybe every other week or every month.
I'm on the fence about this; I think it would help students learn the material but I have a feeling that they would detest the quizzes
It depends on whether the quizzes are on OS topics or Rust topics. OS, yes. Rust, probably not.
Weekly at home quizzes on the recent subject matter.
What was the least interesting lecture this year?
The first few classes
Getting to the First Billion Android Installs
Class 5 on shells
Pointers in Rust
19: Making a Process
Making a Process
I really struggled to absorb the Rust process material.
The classes in which you paged through rust source code to find calls into the kernel. They were difficult to follow and not illuminating. A bottom up approach to leaning about OS kernels would have been preferable.
If I had to choose one it would be Class 22: Putting a Fork in a Fork, only because I enjoyed the lectures more that were broadly focused on computing as a whole.
The multiple class periods on processes were not very interesting because the topic was so hard to follow and keep everything in my head over 2 weeks.
Putting a Fork in Fork
"Putting a Fork in It" was just too much looking at code.
Fork In Depth
Virtual memory, Rust pointers were really confusing for me...and fork
The lectures that walk through codes tend to go too quick for me to follow.
Halloween handshake Trick-or-Treat Protocols 29 October: Trick-or-Treat Protocols Class 17: Protocols I thought they were all quite interesting, my least favorite was probably the guest lecture about Authentication Protocols.
24 October: Access Control
benchmarking I wasn't too enthralled with Benchmarking. I think it could be skipped in order to fit everything else in. Benchmarking Benchmarking Benchmarking lecture
Past, present, and future of operating systems. The December 3 lecture.
Seems very clear that the lectures where I tried to get in depth in the Linux kernel code didn't work very well, and I sensed this was the case also. I had hoped that it would be illuminating to see the actual Linux code and get into some of the complexities in a modern OS, but there was definitely too much gory detail to wade through here to get at the more important concepts.
I think it is still important to look at low-level code like this, but I think will work a lot better in a more bottom-up approach as some of you suggested. (I'm hoping that it will be possible to do this next semester using the Iron Kernel code as an example of a simple OS.)
Some of the others that were mentioned as least interesting here, were mentioned by others as most interesting, so I guess different people find different things interesting.
What was the most interesting lecture this year?
The history-oriented lectures like "Getting to the First Billion Android Installs" were interesting.
Class 7: Pointers in Rust/Memory Management
Multi-tasking was the most interesting.
Scheduling (x3)
Smarter Scheduling (x4)
I think the series on schedulers and super/hypervisors was particularly interesting. They're so fundamental to OS'es and yet I knew nothing about them prior to this course.
10 October: Mutual Exclusion, Trust
I really enjoyed the lecture about server scheduling.
I really liked the Halloween trick-or-treat lecture, it made more sense when taught that way.
I liked filesystems and trick-or-treat protocols.
Karsten's guest lecture, and Getting to the First Billion Android Installs (I love history stuff)
14 November: Fork in Depth
SIM Card, scheduling, authentication protocals
Tom Pickney talking about the ebay infrastructure. I may be biased because I'm very interested in distributed systems.
I enjoyed the guest lecturers by Tom Pinckney and Karsten Nohl a lot. Of yours, I can't say there's a single lecture that stood out on its own, but in general your lectures were well done. Informative slideshows to complement intelligent discussion.
My two favorites were Class 3: Zero to a Billion in 4.86 Years and the last lecture entitled Past, Present, and Future of Operating Systems. Specifically, the last lecture was my favorite as I found it to be very motivating.
I was a big fan of Past, Present, and Future of Operating Systems
What should I do differently to make classes more worthwhile or effective?
Print out notes for every class
You should make it a bit more interactive and hand out a sheet with notes everyday so students will pay more attention and have a better understanding of the overall lecture.
I just think you should keep focusing on what you think is important lecture material, even if that is not what is conventionally taught in an OS class.
Perhaps make the class a little more hands-on? Ask us to look up certain things, make us talk to our neighbors, etc.
More examples during class. Slides can be great, but demonstrations really help me to understand.
More in-class group activities would be useful. I say this simply because it's hard to stay attentive for 1.25 hours. The class where we did "think/pair/share" on the philosophers at dinner problem was great. More of that might be good for ensuring the class stays focused.
I think having more demonstrations of how things work instead of just talking about them would help a lot. After an hour of just sitting and listening its very hard to continue paying attention.
I think that part of taking an operating systems course is being forced to learn. I understand and appreciate your motivation to impart some of your ideas about computing and its history and to provide some context to the things we use. I know that you mention that facts about operating systems we can look up on wikipedia. I feel that part of taking a course like this is the motivation to learn these facts to earn a grade. I do not find virtual memory particularly interesting and I doubt I would read about it in my free time(in fact I have not), but I do recognize that it is an important concept to understand and I wish that the course had forced me to devote more study time on some of these concepts.
Switch from Rust to C. Nearly everything else was great!
Spend more time on the architecture and design philosophy of rust. Give us the high level picture that makes it easier to direct our investigation of the source code and docs. This is the kind of thing which is suited to a lecture format but very difficult to glean from source code.
I kind of wish there was more technical information
If Rust is going to continue to be used, there absolutely needs to be either more lectures that cover the nuances of the language (pointers, references, owned objects, lifetimes, variable moving, etc.) or there needs to be reliable resources that explain these in depth and cover best practices for different situations. Additionally, I think that the project needs to be more strict in what is allowed with regards to how it relates to OS.
I'm hoping we'll definitely have much better documentation for Rust in future semesters, and it was sorely lacking this semester. I don't really understand the last sentence about being more strict about the projects — are you worried that the lack of strictness meant other students got to do things you think they shouldn't have, or that the lack of strictness meant you did something less worthwhile than you would have done if I put more constraints on the project?
If you choose to use Rust again, there should be a few more lectures that teach people the Rust syntax.
If using a new language like rust, more ramp up time on the language to bring everyone up to speed, in lieu of minimal documentation.
If you continue to teach with Rust, it would have been nice to talk more about the intricacies of Rust and language-specific syntax and examples. I felt that the bulk of Rust learning happened while coding the assignments, if at all, and I still probably don't know enough about it to call myself a "strong" rust programmer.
Lecture recordings would be a good idea, and I think more lectures should address challenges/problems that will come up with the problem sets, and how to solve them.
I liked it
Start with more little projects to get more knowledge of the language before jumping into gash or zhtta
Weekly quizzes (graded or not, I just like quizzes as summaries of material).
More, shorter assignments. I would have liked more (forced) reinforcement of concepts after learning them the first time.
Periodic quizzes and more required reading would supplement the material well. I know every student operates differently, but I like to have checkpoints to gauge my progress.
Maybe go slower when explaining/analyzing source code, or focus on less parts of it; sometimes it was just a bit too difficult to follow.
More code examples like the Mac OS fan example.
more in-class live coding
I think that while it's useful to expose students to source codes, the pace of the code walkthroughs done in class has been too quick. Perhaps it would be useful to go through what the codes do in a high-level view before showing them.
I think this is a good suggestion, but I'm not sure lecture is a very good medium for doing code walkthroughs, since what you really want is a way for people to explore code in depth following their own paths and at their own pace.
What was the worst thing about this course?
Nothing I disagreed with. I felt that problem sets were long and challenging, but even though that's less desirable in the moment, retrospectively they were rewarding and informative.
Ramp up time with Rust should've been a little longer
The worst part was having to learn Rust because it was extremely time consuming. I felt like this course was extremely demanding but I did get a lot from it.
The difficulty of the topics covered, and the lack of direct relationship between what our assignments were about and what the topics we were learning were about. Perhaps it would be helpful to do short and numerous problem sets that correspond to each lecture?
Lack of lectures on Rust semantics and particulars.
Updating from 0.7 to 0.8 and getting your code working
The initial Rust learning curve was steep. I eventually came to like the language and intend to continue using it but getting there was not always pleasant.
At times it felt like the course wasn't planned very well
The learning curve of Rust but I think that will ease with time
Rust going to 0.8 in the middle of it
Rust makes everything difficult
I thought that the lack of clear expectations made it difficult to find focus and direction at points in the semester.
Coding the projects in Rust took longer than I believe an equivalent assignment would have taken in C, but that's just a theory.
Problem sets did not always allow us to practice what was learned in the course
Is there anything I did this year that you found offensive?
(15 simple No/Nope answers not shown)
Haha, not really. I like my professors to be on the more eccentric side.
The end of the class approached, and on the last day, you made the very generous gesture of giving us all shirts. I am appreciative of the shirt. But I think the content of the shirt highlights what, rationally or not, I found offensive about this entire semester. The shirt said "rust-class.org", instead of something like "uva-os-class.org" This course didn't just use or highlight Rust, it was centred on it. Your justification for using Rust was that Rust is safe and easy. However, most other classes use C, because it isn't safe and easy. In this way, you learn how to implement these features yourself, and truly understand how they work, rather than just offloading it to a new language. Instead of learning how to work around a problem, we learned how to use a system to solve the problem. This puts me at the distinct disadvantage with my current knowledge of being locked to a single language. Whether it is through my own negligence or the lack of information in the class, I feel as all I know is some theoretical knowledge about OS and some practical knowledge about rust functions, not intimate and practical knowledge about OS. I hope I have this wrong, but it appears that you might have been more interested in our knowledge about Rust than our knowledge about OS. At the very least, quite a bit time was dedicated to Rust, so I have to question what OS topics were shortened or omitted in this course to make enough room on the syllabus. Note that I'm highlighting what I found wrong with the course, and there were definitely great parts. I enjoyed the lectures and guest lecturers. I apologize that my responses here are probably not the most coherent or rational, and I recognized that you have talked about some of them in class. However, I'm under the impression that you'd like honest feedback, so here it is.
This is an important comment and I thank you for making it.
I was worried in getting the rust-class.org domain name that it would make the wrong statement about this being primarily a class on Rust. Unfortunately, os-class.org and similar names were not available and this was the shortest reasonable domain name I could find, and the use of Rust is the most distinguishing thing about this class (for now). On the other hand, I don't view teaching Rust as a main goal of the class, and very little time in lectures was actually spend on Rust specifics, and most of the time that was spent on Rust was focusing on topics that I think are intellectually valuable and important (e.g., how to manage memory safely, how to provide concurrency abstraction) and are not really specific to Rust although looking at how Rust does it was a way to make it concrete.
The decision of whether to focus on actually building an OS or more on systems-level programming is the biggest question in designing an "Operating Systems" course. This doesn't really depend on the language much (people have done build-an-OS courses in C, Java, and ML, and done systems-level programming courses in C). I think there is a lot of value in both types of courses, but for most computing students, a more general "how to build scalable and robust systems" course is more valuable than a "how to build and operating system" course. I discuss this more in my course wrapup notes.
The UVa cs4414 course has been primarily a systems programming course in recent years. For example, the Spring 2013 course had assignments on:
- C tutorial
- Shell 3/4. User-Level Threads
- Programming with Pthreads and semaphores
- File System Reconstruction
(and no open-ended project).
So, I think the decision to use Rust is orthogonal to the decision whether to focus on building-an-OS or systems-level programming more broadly. I don't think we covered less systems-level programming concepts than was done in the C-based course, but using Rust did allow use to cover many more interesting topics (in my view), as well as gain exposure to modern language and systems design issues.
I find Rust to be very offensive (just kidding)
No way. You are one of the coolest lecturers/professors I've had, and I really enjoyed your flexibility, openness, honesty, and pedagogical beliefs.
Heavens no.
I find the Red Sox winning the World Series to be far more important than the USA qualifying for the World Cup.
Hehe (I hope I'm correctly assuming you are joking, and are well aware that there is nothing in more important than the World Cup). Personally, I find it a bit offensive for the Red Sox to claim to be "World" champions for winning a competition that less than 0.1% of the world is invited to compete in! I also like the Red Sox a lot better back when I lived in Boston and they always found creative ways to lose. That was a lot more fun than once they started expecting to win every year.
No, but I think I might have ruptured something laughing when I read your comment about edible printing in conjunction with 3D-printing underwear.
What was the best thing about this course?
On a more serious note, the fact that you're very interested in getting us to want to learn on our own. It's not simple material, and can sometimes be on the boring side, but you care seriously about us learning. Thank you for that."
It has helped me improve as a programmer substantially and has helped me gained more confidence in my ability to create something. It's due to the combination of 1) the course policy (not defining an upper bound on what a problem set or project can do, and letting me have freedom to explore), and 2) the helpful Rust community. If just for the latter, then I think using Rust is a right choice (at the very least, it's beneficial to me in particular).
I learned a lot from your enthusiastic lectures and "real-world" homework assignments. I actually started playing around with Zhtta and tried to get it running on an AWS EC2 instance for fun; no luck getting Rust installed yet, though. Might have to try a different Linux distro...
This was a very cool course! It would be even better as a 4501, though. It was more of a "learn about large scale open source development" course.
I loved the project-- getting to decide on our own problem and then work with a team to accomplish it.
Definitely your attitude towards what you feel is valuable lecture material and how you are able to teach concepts by relating them to real life examples.
Making a web server was a very interesting challenge.
The project was great. Best guest speakers from any course I've ever taken.
Finally learned about how processes and memory are handled - basically, how operating systems work.
The best thing was feeling accomplished when we were able to get a complex Rust function working (like the web server).
Being able to have opened ended final projects, really let us shine on projects we wanted to see in the world.
The project was a lot of fun and I liked how you gave us a lot of freedom to do what interested us.
Being able to observe a language in development and interact directly with the developers of the language.
Finding out that I like Rust
The Good Auld Shell problem set
The freedom to work on projects with your own solutions in mind, without adhering to a strict set of grading criteria
Rust, it was really cool to learn about this language
I felt like I gained a lot from the problem sets and from working in Rust
Lectures were interesting and relevant, and the problem sets applied concepts from lecture to useful applications.
I appreciated the freedom given to us to push the bounds on assignments and create something new.
Much of the lecture material was brand new to me.
Structure of the course placed emphasis on learning material and pursuing topics of interest
The guest lectures and unique test grading.
Exposure to a new language
NO FINALS
In class demo were interesting
Surprise T-shirts at the end. That was awesome. Thanks!
What is the most valuable thing you learned from this course?
Team projects can actually be fun
That Operating Systems are even more complicated than I thought... Seriously though, going into how the kernel organizes memory and does scheduling was a complete eye-opener.
Between this class and my job at Arqball last summer I have become comfortable learning new systems from just docs and source code. I now feel like I can clone any github repo and start figuring out how things work, which is a great feeling.
Procrastination is bad. I needed to get a much earlier start on the Problem Sets.
I value the knowledge I learned about core OS functionality such as scheduling and resource handling.
I learned more about how the operating system works at a low level, which is important to understand why computers behave the way they do and helps in making programs to manipulate them.
How scheduling and memory management work in operating systems.
I really liked learning how a process gets kicked off in an operating system. That sort of low-level knowledge was very interesting.
Scheduling techniques were really interesting and valuable
I think the most valuable thing I learned from this course was just the overall concept of an operating system and how it affects software. I have always been more interested in programming higher level programs, not an operating system, so it was interesting to learn how an OS is programmed and how it affects processes. Also, this course was a great learning experience in that we learned a new language and were able to effectively apply this knowledge on problem sets and our project.
The range of computing fields below the application layer is very confusing and arcane, but it is doable as long as you try for a long time. It is interesting to take this class in the pre-World Cup year!
I think the most valuable thing that I learned was how to work with a rapidly changing codebase and library with little to no documentation which is not unprecedented in industry. It expanded what I think of as possible resources when trying to solve problems in a dynamic environment.
Being able to learn a new language and work for myself instead of depending on documentation
Scheduling, concurrency, deadlocking, processes, all of that sort of thing. After graduation I'm headed out to Seattle to work for Amazon Web Services. Working at scale is so very reliant upon understanding concurrency. =)
Everything about processes and threads, and techniques to prevent conflicts using them
What a process really is
Goals of processes, utilizing system resources, and parallel programming.
The most valuable thing I learned in this course wasn't operating systems at all, but rather the idea that success in the real world of computer science is measured by experience and accomplishments rather than test scores and a feeling of entitlement.
Modern scheduling strategies
Forking and Map Reduce. Finally know what these are!
Read source code and use IRC.
Any other comments you have?
Problem sets and lectures should go together more closely; more hands-on work in lectures that can be applied to problem sets
It was fun being a guinea pig for this class. I wish I had gotten a Rust sticker though...
I find your teaching methods novel and agreeable. Other CS classes I have had so far usually only have a fixed, predetermined sets of things to do. Although the concepts they go over may be interesting, I find the assignments to be frequently lacking. I'm not strong enough to push myself and need someone to push me past my limit. In this respect, I find your class has offered an advantage no other CS class (except for CS2150 to some extent) at UVa has.
I just want to say that you were one of the best lecturers I have had at the university and I really appreciate that you lectured what you felt was important. Your lectures were interesting and even motivating, which is something no other professor has been able to accomplish as well. Thanks for the great semester!
If Rust is featured again next semester, maybe the final project or even the first problem set should be cleaning up some part of the Rust documentation. This would get people more familiar with the documentation and also improve it for anyone else who wants to start using Rust.
Really enjoyed the class overall. Learned a lot of interesting things that I wouldn't likely find in other courses. "This was one of my favorite courses this semester, and I do find that I have filled in some of the 'gaps' in my understanding of how computers work (as seen in that class topic image you made).
However, I feel that using Rust impacted the course - and more importantly, the students' ability to learn Operating Systems - significantly, in a bad way.
-
Employers use more C and I would guess that putting C on our resume or being able to answer C interviewing questions should help us more in getting a job than Rust will (at this point in time, at least)
-
Rust has incomplete/incorrect documentation (as would be expected in a pre 1.0 language) This goes far beyond not being able to Google the right code to copy paste into our problem sets! At this point in our undergraduate careers, my understanding is that we are expected to go beyond simply turning in working code, and instead should be following the true spirit of the assignments - really learning, on a deep level, what is going on. When I Google for Rust help, there are far less resources - I can likely get my code working at some point, but usually I didn't understand it. When I Google, say, how to make a process in C, the important thing is not that I find working code to copy, but explanations. This is where I feel that core learning should come from - diving down into these deep levels ourselves and learning on the fly. I can find information on discussions, tradeoffs, from multiple sources. When it comes to Rust, I spend a long time getting it to work, and very little understanding the details. Repeatedly, me and my partners would be stuck, not on an operating systems concept, but on a simple, unrelated, syntatic or similar error on a trivial function. I know, I know, a programmer is complaining that he has to fight with syntax, and that he hates working with stupid mistakes instead of being able to work on the big picture - but in this class, we found that the learning curve for Rust and the overhead for getting it working was VASTLY disproportionate to how we wanted to spend our time in the class, even compared to learning other languages. In 2150, it was absolutely grueling learning C++ for the first time on the fly, while using it on significant assignments, but I felt that I was learning more of the concepts of the course along with it than with Rust here. When we did have trouble with the language, it was with the concepts it brought along - pointers and references, low level memory access, etc - not a lack of an API or syntax. A bad API is huge - we can't even trust that basic functions will perform as expected. Our complaints at 3 AM during all nighters was NOT that we had to spend so much time, NOR that our code would not output correctly, or not compile. Our complaint was that overcoming a problem afters hours of effort was not cracking a core OS concept, but, say, Rust syntax that we didn't understand, or a function that was incorrectly documented.
-
Rust is changing too fast. With the little documentation there is, it is challenging to move between versions that are not backwards compatible. In this early stage of Rust, I think it was a bad idea to not only change which version of Rust we were using during class, but also using in a language that is so unstable in the first place.
Rebuttals against some possible reasons for Rust:
-
Don't we have IRC with the devs themselves? IRC is wonderful and the Rust devs have given a lot of their time to help us, which I appreciate, but it is no substitute for a current and correct API. Do recommend IRC for other technologies that we use, though - it is excellent as a supplemental (but not reliable) tool, not a substitute for out hard working TAs (we would usually end up at a TA's office hours anyway after IRC was insufficient).
-
Rust is fundamentally better for C for managing operating systems and similar projects, it was designed for modern use. Yes, but all the ways for explaining how those concepts work are still done in C. Compare Google results for 'how do C processes work' to Rust processes.
-
In the real world you are thrown in with technologies you don't understand, and poor documentation, yet you still need to tough it out and get things done. Yes! Throughout my internships and classes, constantly being thrown in to new technologies, servers, and environments that are alien to me, I agree 100%. However, the vast majority of those will have working APIs for the base language (even if not the framework itself). Too much time of this class was spent on syntax (specific to Rust, not some inherent skill in programming that we had yet to learn) instead of learning about operating systems
-
We can't make the course too easy. By all means, increase the requirements on the programming problem sets, and require us to go deeper in the system, just with C. Assign us MORE work, that takes MORE time, on a DEEPER level, in a fundamentally HARDER way, just with C so we are learning operating systems instead of syntax. In other words, I would rather explore the Grand Canyon in the daytime than a pothole in the dark.
-
You just want an easy A. But you are already giving me an A, right? ...I hope? Maybe?
-
You just hate Rust. No! Rust does seem better than C for modern systems, and it may very well grow into a great replacement language! But this is not the time to teach with a pre 1.0 language when so much more literature and learning on the topic has been done with C. Maybe a 1 credit Rust course would be a good idea, like the Haskell one?
Anyway.... This was still one of my favorite classes this semester, and I might even want to TA for next semester!
Thanks much for the very thoughtful comments. I think you make some good points (although, not enough to yet convince me to give up on teaching this couse using Rust!).
On the value of learning C for potential employers, I view this a bit differently. First, I don't think our courses should be designed around the immediate skills you might need for your first job. Different students want different first jobs, and if your goal in attending the University is to gain qualifications you need to get a high-paying CS job there are much easier and cheaper ways to do this (e.g., spend a few weeks learning Ruby or iOS development), and your University education should give you the core foundation to learn whatever skills you need when you need them. Much better to focus University courses on understanding high-level concepts and important ideas (which I think Rust enables much better than C), than on particular skills.
Second, in a long term sense, the reason many employers use C (or Java, or COBOL, etc.) is because they are tied into legacy systems, not because these are the best tools for what they are doing. The strongest legacy inertia is what they know, and what the people they can hire know. So, part of the reason companies use C is because they have programmers who know C and can hire new University graduates who know C relatively inexpensively, whereas hiring programmers with experience in Haskell, OCaml, LISP, or Rust is much more difficult and expensive. We've been in the cycle of Universities teaching C/Java because that's what employers want, and employers using C/Java because that's what the people they can hire easily know, for 40/15 years. Leading universities should be leading this cycle, not following it. Even if it takes a while for ossified companies to move to better tools, graduates who know how to use better tools will have a big advantage in building their own projects or companies.
I do agree with all the complaints about lack of documentation making things much harder than necessary, and it is unfortunate that this meant students spent a lot of time being frustrated with technical issues (and sometimes compiler bugs) rather than learning the things I hope students learn in the class. It was perhaps a few months early to use Rust for this reason, but things are improving fast, and I'm very happy to see efforts from students in this class to improve them further. That said, I've heard from some students that found it very valuable to figure out how to use undocumented APIs by reading the Rust library source code (and this is something nearly everyone who works on a large software project will have to do at some point).
The fast changing state of the language is problematic and it makes things tough when language updates are not maintaining backwards compatibility so break old code. Until Rust gets to version 1.0, not worrying about backwards compatibility is a good thing to avoid too many constraints on language design, but things should get more stable as the language gets more mature. I had intended to use a fixed version for the entire course (which may still have been a good idea), but it seems like the improvements in 0.8 were enough of a value to be worth changing versions.
I think you should consider making teams for students on projects rather than allowing for students to choose their own teams as in the real world you don't typically have a choice over this. This would help prepare students better when they have a job and are working on a team with strangers.
Thank you for your teaching! It was a very challenging, but interesting semester.
I liked the t-shirts we got!
In order to understand the benefits of Rust, students really need to be able to compare a rust implementation to an implementation in another language. I think the biggest help for this course would be for it to take a page from Weimer's Programming Languages and have a few problem sets where students need to implement their solution in two different languages (probably Rust and C). This would allow them to directly see where Rust is beneficial over a more traditional language like C and would give them practice in using Rust. If the class were to take this route, I would expect that this would only be one or two assignments at the beginning of the year, with the rest of the problem sets being in Rust exclusively. Due to the nature of these introductory problem sets, they would need to be smaller in length, but they would need to be designed so that they each illustrate one or more aspects where Rust differs from C and how it can be advantageous. This suggestion comes directly from my own experience in this class where I still have trouble understanding what exactly the benefits of Rust are in some areas. Finally, I would like to repeat my suggestion that D be considered as an alternative to Rust for this class. It is much more complete than Rust is and has a larger support base. While it may not do everything that Rust can, it would be a better fit for an operating systems class in my personal opinion.
Thank you for making this a very valuable course
The class was very well structured this semester and the workload was fair. I would be wary to introduce things like quizzes and extra examinations as they'll turn the class material into a "cram and dump" sort of thing. Instead, keep the assignments focused on real-world problems like you did this semester. Learning by doing is the best way to learn, in my opinion.
I would also say to avoid having the homeworks be reliant upon C. What I didn't like about the shell project, in particular, was that it was Rust doing the high level stuff calling C abstractions for the low-level stuff. My shell worked in the end but I wasn't as excited about the results because it didn't feel like I had actually written the shell.
The course was great. I'm really glad I got to take it when I did. Keep up the great work.
I still do not think I understand much about the design goals of developing an operating system, or what the current problems in operating system design are.
Overall, I greatly enjoyed your lectures
This was one of my favorite classes. I was able to learn AND remember what I learned.
Official Course Evaluation
The University's official course evaluation: PDF
I'll highlight a few of the more interesting responses below (but see the linked PDF for the complete responses).
What should the name of this course be?
"Operating Systems" (10 people)
I think this is actually a really bad name for the course, and a misleading and ill-defined one. But, it is difficult to change official course names, so this will stick for a while.
Learning how to actually code! This operating systems class was taught using a fairly new programming language called Rust. Though sometimes it was a headache trying to find documentation or figuring out the string class, I think learning Rust was a valuable asset. It taught us how to search and figure things our for ourselves. Though I would be strongly opposed to teaching an experimental programming language in an introductory programming class, I thought it worked nicely in an upper level course. Experience with Java, C++, and other languages help me figure out what was going on pretty easily.
Rustic OS
The Z in Zhtta
As currently taught, "Intro to Systems Programming" seems like a better fit.
David Evans and the Masters of the Universe! (In the event that this name isn't available, Operating Systems seems fine to me)
If it is necessary to significantly cut material from the course, what material should definitely be kept?
Process, Scheduling, Synchronization, Virtual Memory, and File Systems
Scheduling, Task handling
Definitely the initial operating systems intro and the initial Rust structures
I think the project should definitely be kept but most of the material is replacable as long as the idea is kept.
All material discussed should be kept.
Scheduling, race conditions,
Processes, Memory Management, Concurrency discussion...
The lectures about processes
Process scheduling, history of computing/Android, predictions about future
Understanding operating systems concepts in practice
I would strongly fight to not cut material. I think material should be added, not cut, with one or two exceptions.
Process, Scheduling, Synchronization, Virtual Memory, and File Systems
Scheduling, Task handling
Definitely the initial operating systems intro and the initial Rust structures
I think the project should definitely be kept but most of the material is replacable as long as the idea is kept.
All material discussed should be kept.
Scheduling, race conditions,
Processes, Memory Management, Concurrency discussion...
The lectures about processes
Process scheduling, history of computing/Android, predictions about future
Understanding operating systems concepts in practice
I would strongly fight to not cut material. I think material should be added, not cut, with one or two exceptions.
What content that was covered this year should be dropped (or reduced) from future versions of this course?
I liked that we learned a new language but perhaps we could learn more of it on our own and drop some lectures on it like the map reduce. I found it helpful nevertheless but if anything needed to be cut for something else then I think giving us more time to learn on our own wouldn't hurt the purpose of that lecture.
too much security materials (can be covered in much more detail in other dedicated classes)
It seems we had a few classes at the end that could have been dropped/replaced.
Looking through the rust source for process spawning
Most of the impossible things should be dropped. It was highly demotivating to work on something for 10 hours to find that I could not do it.
Rust (x4)
Rust syntax, historical context (which was honestly one of my favorite parts, but didn't contribute to my understanding of operating systems)
Nothing immediately comes to mind, but perhaps rust?
Reduce the amount of Rust, want to make sure the class is about OS
Some of the security information, while interesting and relevant to the work of Professor Evans, didn't seem relevant to the class, and could be replaced with more in-depth low level information.
Perhaps Rust?
Benchmarks if absolutely required
Encryption didn't seem to make a ton of sense in the context it was presented. Much of the material (in fact, almost any material in CS) could be tied to the OS, but I think there needs to be a little more discussion about why things are relevant to OS--aka, SIM cards?
Another difficult quesiton. Uh... - Benchmarking? Hopefully some other students step in. I thought all of the material covered was reasonable to cover. Some of it I definitely struggled with on a conceptual level more than others but there wasn't anything in the class that /shouldn't/ have been. I could understand why everything that was taught was.
None
It was hard to fully understand how a process works in Rust.
The guest lectures were sometimes interesting but were rarely connected enough to the course
Final project should involve some low-level OS stuff
Future offerings of this course should use Rust.
Similar to other questions like this, there is a very strong division here, but a slight majority favoring continued use of Rust. This seems like enough support for me to use Rust again next semester, and we'll see if things go better with more experience with this and much better documentation available.
Please make any overall comments or observations about this course:
Great class! Loved the lectures and enjoyed the assignments. One of the best classes in CS that I have had.
I had thought a lot about what to write here, but since the text box gives the feeling that it should be short, I'll summarize. First, I appreciate some qualities of the instructor that have let me enjoy this class: 1) He's more concerned about you learning, exploring, and creating something of value (to yourself or other) and his class has this feeling of "lightheartedness" (though the homeworks are sufficiently serious), 2) He does not define an upper bound on how much you can do in homework, which makes you want to try and impress him, and 3) He's honest and concrete when giving feedback (he'd say whether you have done enough for the assignment, and you could have also done so and so). Traditionally, the OS class as UVa has a dual purpose of making you a better programmer and teaching you OS. I have found Professor Evans's class to succeed wonderfully in the first regard. Due to the sheer number of hours I have put into programming this semester (partly due to Professor's second quality), I have improved more in this semester than any other time period of equal duration. In particular, two important things I have learned are: reading source code is not scary, and ask questions on IRC. In this regard, using Rust for the class was probably the right move. I predict the predominant criticism of this class is that it feels more like an "Introduction to Rust" than "Operating Systems". The first question of this evaluation form suggests the professor is aware of this. To a certain extent, they are right. However, to be fair to Professor Evans, his coverage of OS materials is probably only lacking due to the missing PS4 (and him missing the first two classes due to sickness).
I would space out the projects we had, simple web server, shell, complicated web server out across the semester with the SWS first thing in the semester and CWS as possibly the last thing. In between I would have smaller assignments/problem sets/coding that exposed more things about rust. I guess what Im trying to say is that I think there should be more, smaller, assignments so students have more exposer to rust.
Overall, I enjoyed this class, the homework, and the project. The class is well-organized and the lectures (love the demos and guest lectures) are insightful. I have not missed a single class, but I would like to apologize for not paying attention due to exams/projects. My project is not exactly working out due in part to rust being a new language without much documentation/support. I am hoping that that is okay. MC
He was pretty disrespectful in the office hours. But the course was overall a good experience, and I learned a lot out of the class. We could've had a better experience with the class if the Rust language had been more thoroughly documented and resources reasonably available online.
Very unconventional, very steep learning curve. We'll see when grades come in, but the experience would be better if either we didn't have to freak out about grades the entire semester and accept things would be hard but we'd be okay, or, the hard assignments were a little more guided.
n/a
If Rust ever becomes a fully developed language, I think it will be really useful. I really liked the high "truthiness" aspect. If the code compiled if usually ran how I expected it would. If it didn't compile, the error messages generated by the compiler were quite useful in debugging the code, far better than the segfault disaster of C++. I hope Rust makes it!
I really liked this class and it taught me more than just the technical side of operating systems. I am also thinking about my future differently which is what a university class should do as opposed to just restating some material that could be read on wikipedia.
David Evans is an excellent Professor and I have recommended this class to many of my peers. The decision to use Rust instead of C was definitely a unique one but I think it paid off in the end. Even if Rust doesn't take off it puts you in an exciting new place as a programmer -- thinking about problems in a new, safer, way, especially when dealing with concurrency. I had a great deal of fun working on the deadlock, for instance, trying to make a safe language deadlock was a neat challenge. Professor Evans' take on assignments and exams was refreshing -- the option to change the class goals if I didn't agree with them was appreciated even though I never took it. His goals were reasonable, fair, and attainable with the right amount of effort. I'm glad I took this course when I did, I feel like I've been a part of what should be the way this course is taught into the future.
I liked using Rust but I think the reasons for using Rust weren't adequately incorporated into the subject material. I think it could've been emphasized more the reasoning for using rust over C
I appreciate you letting us do whatever we wanted to do with the project. I also like how you snuck interesting topics pertinent to the real world into the lecture that made it worthwhile to go.
This course was really worthwhile
Your "on track (1)/not on track (0)" grading policy is I think good and necessary for a course of this difficulty level. Your lectures were engaging and enlightening. The giveaway incentives were very fun.
You made yourself approachable and available outside of class and stuck to appointments. Piazza was a good learning tool and the messages were helpful even when I didn't feel prepared enough to contribute
I think most of my opinions can be discerned from the evaluations above. I know this is an experimental course, and it has potential, but I did not particularly enjoy it due to the specific things I worked on.
The course would have been much more effective if we used a programming language that was not currently being developed
I believe Rust may need more documentation and/or stability before it could be effectively used as a programming language for this course.
I'm very torn on Rust. I thought it was a nifty language at first but as time went on, I found that the safety/pointers were very hard to deal with, and I was always coding in Java/C++ mode. I found myself spending way more time looking up what to do in Rust instead of understanding what was actually happening in the program.
Course was great, just not a fan of learning Rust myself.
I learned a lot, but I'm not sure if I learned a lot about Operating Systems
Thanks for reading this far! You may also want to read my wrap-up summary of the course. Please feel free to comment with your identify or anonymously below, or to email me directly to follow-up on any of the comments here.