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.
You can browse the public material for the Spring 2021 version: it looks like it teaches you how to program via Rust. I don't see a lot of history or theory in the slides there, but perhaps the lectures expand on this. There is also a number of repositories on GitHub.