Reflections on Rust in the LLM Age
28 points by rrampage
28 points by rrampage
Combining the quadrant of systems from this talk with this James Hague article, "Free Your Technical Aesthetic from the 1970s", I propose a variation on that title: "Free your technical aesthetic from rebellious systems".
I think that a lot of programmers, myself included, have idolized rebellious systems too much. Unix, Rails, even the early microcomputers that we now look back on fondly. (I include the latter in this category because the rebellious streak in the early microcomputer industry is well-known.) But these rebellious systems sometimes throw out things that actually matter and then have to accrete them back. I think as working programmers, often the best we can hope for is a constructed system, and we shouldn't want so badly to follow in the footsteps of the rebellious systems.
Hm I am not sure I see the connection between that Hague article and Unix being a "rebellious system" like Rails? (I'm not sure it's clear that Rails is a rebellious system either, but that's a separate question.)
Referring to only the Hague article:
I'm comfortable pointing out the three reasons Unix makes sense:
- It works.
- It's reliable.
- It stays constant.
But don't--do not--ever, make the mistake of those benefits being a reason to use Unix as a basis for your technical or design aesthetic.
First, the benefits of Unix he points out aren't really "rebellious" -- it's a different dimension.
Second, I see what he's saying about aesthetic, but I think it misses an important point: Unix was ABLE to grow because, like the web, it started out as the minimum thing that does the job. It was contrarian compared to Multics, and that is exactly why Cantrill calls Unix rebellious.
So I think that minimalism is an aesthetic worth thinking about, at least in open source. If you have a lot of money, that does open up things, but it often makes things worse too.
It's true that Linux a big mess in almost all ways now, but you have to choose carefully what you compare it to. Windows?
For a totally different aesthetic, I would randomly throw out say the Darklang project (which has featured on lobste.rs over the years). And I would say coupling in its design fundamentally limited its applicability, and more. So is this a "constructed" system? If so, then I'd say it could be a counterexample
( I didn't watch the linked talk yet, but I hope to ... I did find Cantrill's earlier talk mentioning "rebellious systems" quite good, but I'll have to remind myself of his exact definition. I am not sure I entirely agreed with the dimensions / taxonomy, but I remember the talk being good.
Oh yes it was this one: The Complexity of Simplicity.)
Thinking out loud to myself a bit here, one place where Linux/Unix has obviously "accreted" is containers - both kernel and user space tools.
What we ended up with is obviously worse than what you could have done with a principled design.
But I'm not sure the lesson is "AT&T should have designed OS containers in from the start". I mean the real problem is that the Unix process API isolates memory, but doesn't isolate other things.
But even OCI containers go too far in the other direciton I'd argue -- they compose poorly because of haphazard isolation.
And again look at the alternatives -- did they have containers / virtualization?
So it's easy to see the criticism, but hard to come up with the solution. "Have 20 or 30 years of foresight" doesn't seem like a great answer
When he was talking about M:N threading ("before Rust" slice), I kept thinking about Erlang and Go. Those languages to me are "fine", especially for things like network services.
So while I found the other aspects of his argument there compelling (eg. RPC, ORM, exceptions, dynamic typing).. maybe not that one too much. Or perhaps he was thinking of something else when he was critiquing M:N threading, or more specifically in the realm of "system software" / infrastructure? Maybe he should have thrown async in there too? :P
I think he was referring to the original LWPs from Solaris, so green-threads on the OS level, but that's a super weird example. Yes, on the OS level, that idea died, because adapting the POSIX APIs to this is hard, but in the userspace, the idea is getting more popular every year. We had async runtime extremely popular for decades now and people are now even getting back to real stackful coroutines. These days, if you think M:N threading, you think Go and all the other stackful coroutine runtimes, and there is nothing inherently wrong about them.
Wow excellent talk! I really liked the honesty in the bits about getting copied by SystemTap and so forth. And it's funny to hear a systems person's gut take on someone making a new programming language -- I have heard that before, and it's not totally baseless :-)
This is an amazing talk! I wrote that after watching the first 45 minutes, and I have to say the second 45 minutes is even better.
I'm sad to see that the comments were mostly tangential to some of the key points.
I found myself nodding in agreement the whole time:
This talk didn't get enough attention!