I had a topic earlier about thinking in composition over inheritance, and though I got a few responses, it still felt like Composition over Inheritance had no real theoretical or academic basis. At university, Object Oriented Design principles are taught in a very thorough manner explaining where they came from, what they mean, and how to think in OO, but it feels like that is not there for Rust.
So, are there any universities that teach Rust or any university level design courses? Or something to that effect? Not just a 1-2h presentation at some conference, but an in-depth multi-week course that dives into some core design principles of Rust or things related to it?
Simply reading "just think in X" is really advice. It's similar to "why aren't you rich when you could just be rich" or "just stop being depressed bro". It would be nice to have something more in-depth. Concrete.
Object oriented programming also doesn't have any "real basis". It's really just a philosophical take on how to think about data structures and algorithms.
It's not because it's taught in university undergraduate courses that it is more "real".
It's all really just woodworking techniques, except it's taught in universities instead of technical schools (professional schools? I don't know the exact term).
Edit: though I know through friends and "connections" that not a few engineering schools in Paris have a Rust course.
Unfortunately. There are many things related to programming good practice which aren't taught at universities. And similarly, there are many pieces of bad and/or obsolete and/or misunderstood and/or misguided practice that they do teach. For example:
Universities widely teach programming via IDEs because that is supposedly "easier" on students. As a result, students will have zero idea about the underlying build systems, how a compiler works and why one is required, etc. Some universities (including one I attended) don't even have a compilers course to clarify things later.
University courses teaching languages with modern versions almost exclusively restrict themselves to ancient editions. The most prominent problem is of course C and C++. The overwhelming majority of teachers of C and C++ are old professors or engineers having been brought up in the 70s or 80s, and they still think that C means K&R C or C89, and C++ didn't have anything new after 2003. This of course results in the teaching of patterns which have been proven by decades of experience to result in bug-ridden, slow, security-wise unacceptable programs, but teachers who have been giving the same lectures to students for the last half century could not care less.
There is a serious lack of materials in more software engineering related curricula when it comes to modern good ideas, and this includes contemporary functional programming languages as well as things like Rust. Most university programming courses, like many technical/SE job interviews, focus on creating algorithms to problems ranging from the realistic to the completely contrived. This is very useful during the first 1 or 2 years, while young people need to form a vision of algorithmic thinking. But "it gives the correct answer therefore it must run in production" is entirely the wrong attitude later, when not-so-academic points such as good design, maintainability, extensibility, security, robustness, performance, and scalability also enter the constraint space. Unfortunately, very little attention is given to these topics. The best thing the say 90th percentile university student ever hears about performance in lecture is about asymptotic complexity, of which lectures usually start with the egregious lie oversimplification that "constant factors don't matter".
As you can see, there is very little correlation between the quality of ideas in programming and whether they are being taught in mainstream academia. Rust is no exception – it's still relatively new (albeit it has been around for 15 years), and the inertia in academic circles is sadly enormous.
Oh, and by the way. "Composition over inheritance" is the least interesting part of Rust. If one really wanted to slap inheritance upon current Rust, I reckon that one could (although it would cause nothing but suffering, because it would break type inference, and the action-at-a-distance nature of subtyping is the mental labyrinth I would never ever want to go back to).
The more interesting parts of Rust all have a solid theoretical basis behind them, although that is not why they are valuable. They are valuable because of the execution – how they have been molded into a coherent, sensible, and guaranteed-safe language that solves many practical problems previously though to be unsolvable. Anyway, here are a couple of core Rust ideas that do have a lot of theory behind them:
The ownership system is based on linear (more precisely, affine) types.
The type-and-trait system forms a lattice, on which inference is performed by something like the famous Algorithm W (aka "Hindley-Milner").
real enums (i.e., fully-fledged sum types, not just typed integers) come from type theory too, they are what is known as sum types in traditional FP parlance.
It's not often I have needed to speed things up in my career. But what I discovered is that sure, it may be possible to find an algorithm that scales as n.log(n) instead of n squared or whatever, but often such algorithms are slower for small n. Well, if you are dealing with processing billions of small data sets the "slower" algorithm will be faster. The trick then is finding the point at which it is actually profitable to use the sophisticated algorithm over the naive algorithm.
It depends on the problem. If I speed up your program by a constant factor of 10, you'll probably be pretty happy. There was a recent thread which came down to making half as many syscalls [1] to double the speed of filesystem crawler, for example.
And yes, you want the more constrained big-O, generally speaking. But if you're comparing a linear algorithm to a O(n log log n) one, say, constant factors can easily dwarf the technically unbounded log log n factor.
I've also only mentioned performance here, but @H2CO3 made a larger point about
good design, maintainability, extensibility, security, robustness, performance, and scalability
Certainly recently I have been really wishing someone had traded some performance for maintainability and robustness at $JOB.
That's exactly why they are valuable. Saying “Rust is OCaml masquerading as C++” is only half-joke. Many of most loved properties of Rust are so nice to use precisely because they have solid foundation. And they require pretty conceptually simple things to implement these.
While LSP, the theoretical base which underpins OOP, not only arrived late (most popular style of OOP today has roots in Simular 67 while LSP which made it theoretically-sound arrived two decades later), but, more importantly, it's something that no modern compiler may automatically verify and which most programmers have trouble with, too.
Do they talk about the fact that OOP had no theoretical foundation for two decades, about how that crisis was resolved and why composition over Inheritance is today recommended even in OOP languages?
I'm genuinely curious, because when I was learning OOP most courses mentioned LSP in passing with minimum amount of fanfare and without even mentioning about critical role it plays in OOP and/or troubles one faces when s/he's trying to apply it in practice.
I'm pretty sure if deep implications were actually mentioned and it would have been shown and explained how hard is it to keep everything coherent in practice then most students would have rejected OOP themselves.
Because that obsession with TDD and unittests and mocks and many other things which are not really needed… they all come down to attempts to detect violations of LSP (which very often still fail, anyway).
Oh, so with the Rust type system, Hindley-Milner actually works? That is pretty cool.
In the Scala community, people were always saying "Unlike in Haskell, type inference in Scala is only local; we can't do Hindley-Milner, because it doesn't work with OOP."
What would you suggest then? Look at this thread. Only a single person actually tried to answer the main question. Everything else is "but you're wrong". Regardless of what they think and who's wrong or right, the question still stands and it looks like the answer is "no". How did context help?
Well, I guess that happens when you make somewhat accusatory comments about the language not being real/serious enough because it's busy solving practical problems instead of trying to sell itself as a theoretically supreme creation to academics. It is indeed probably best to not include this kind of commentary if all you are trying to ask is "send me links to Rust courses".
You chose to interpret it as accusatory. The response could've been "I don't know of an academic course, but X made a multi-video series on the theory behind Y with examples and a guide on how to solve similar problems with rust. Check it out"
Or "I'm not sure I agree with your view, but I found this to be very insightful".
Just breath and remember this is the internet. This group is one of the "nicest" but this is the internet. I do really wish you luck and hope your future questions and interactions here go smoother.
The “main question,” as you put it, is somewhat unclear in your original post. You ask a series of 3 related questions in the middle paragraph of three, the weakest position in an argument. Those are surrounded by praise for the academic basis of object-oriented programming above and preemptive complaints about the sort of answers you expect below.
Overall, it gives the impression that the questions are simply rhetorical and that your real aim is to express frustration with your Rust experiences to date. Most of the replies you got responded to this (perhaps unintentional) subtext in your original post.
Composition over inheritance I think it is a quite old topic, more than twenty years old, but I remember I started taking care after watching several times the Sean Parent's C++ talk "Inheritance is the base class of evil" around ten years ago, what I loved.