> You don't have to teach people about the limits, you could build a discord client on top of a "a method to query messages, and another to render to a framebuffer through software rendering" and show them how much faster it could be how much less memory it could use.
The problem is exactly that this is not that simple. I believe that there is a huge gap between the theory of a chat application, and the way they are implemented now. I do not believe it is about better abstraction layers, personally I have always found explanations using raw sockets and bits the simplest.
If you were to ask a programmer to write a discord client, you would very likely end up with a giant mess that somehow break a few months later at most (if ever). Even though they would be able to flawlessly go through the program flow step by step if you asked.
Discussions about efficient code kind of avoid the topic, I don't believe we are in a situation where multithreading is relevant, the bloat is on another level. The bloat is generally not related to whatever language you use, the O(1) or O(n) algorithm you choose, but more likely the overall control flow of the program which you already understand in your head but cannot figure out how to act on, and the inability to make simple problems simple to solve (like the calculator, text editor, or even games)
Now you are probably right about Casey ultimately doing what he likes, and even if suboptimal make other people aware. Although I would believe that this benefit comes somewhat in spite of himself.
> Have you looked at the Roc language? It has a lot of similarities to what you're describing.
Gave it a look and unfortunately, I don't think I have seen the similarities? It has environment/IO access, call host language functions, and doesn't really strive to be reimplemented by independent people.