The Rise of Worse Is Better (1991)

That worse-is-better is self-reinforcing and that it's the only stable strategy in an environment with less-than-perfect cooperation (i.e. it's the only Nash equilibrium) may both be true at the same time. In fact, if the latter is true then the former is alsmost certainly true.

The real question is, then, whether doing "the right thing" is a stable and winning strategy at all, i.e. viable and affordable. As you yourself suspect, the answer may well be no. Not only because it takes a few tries to figure out the right foundations, but also because what foundation is right is likely to change over time as conditions change (e.g. hardware architecture changes, programming practices -- such as the use of AI assistants -- change etc.).

Go is an incremental improvement over C#?? I think you’re going to find quite a bit of controversy with that take.

I think Go focusing on certain aspects of tooling and deployment early on might be considered improvements on C#/.NET (some, not all). There are aspects of the Golang standard library that are better designed for purpose than C#/.NET (Again even this has to be nuanced because quite a few 3rd party libraries in .NET were basically “standard”). .NET was hobbled by being effectively Windows only, not because of C#.

> Part of what I mean by "making a big impact" is affecting how we think about programs, which Rust has done and Go has not.

A hallmark of Go is the deprioritization of expressiveness compared to its contemporaries, and I argue this does just as much to affect how one thinks about programs.

A further hallmark of golang is CSP, which of course was nearly a 50 year old concept but not something mainstream at the time (which describes just about everything is Rust but perhaps for a number I can’t read your mind and this is too vague. It’s a matter of perspective but I’m not sure what the big new paradigm in Rust you are referring to. Rust doesn’t really break new ground either, which is partly why it isn’t less obscure, widely used languages are almost never the debut of new features, they have been cooking in research and more obscure PLs for years and years. It is at the end of the day still an imperative/mutable language. It just uses a hell of a lot more PL features than Go.

If we’re talking about the borrow checker, which was plan B (plan A was GC), I challenge the idea that it affects how we think about programs. The concept of ownership, lifetimes, aliasing and move semantics were already thought about heavily in C++ prior to Rust (many things codified in the 2011 standard). You still have to think about these things, it’s just that C++ lacks the ability to enforce it. And of course Rust lifted most of the design from Cyclone. There are few large scale Rust projects that can avoid RC either (or some other dynamic lifetime or surrogate reference copium).

You also haven’t mentioned Swift which in many ways is more clever than Rust. Its adoption is more hobbled by the circumstances surrounding its specific corporate driven ecosystem. Maybe that will change.

Hey, thanks! I had looked for it when writing my previous comment, but I skipped past the ITU links on the assumption that I'd have to sign over my first-born children in order to get a copy. But it turns out that they aren't currently restricting its availability: https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.22...

Clearly "videotex" is wrong. Skimming X.225, though, an awful lot of it does seem to be concerned with ⓐ half-duplex terminals and ⓑ T.62 teletex (not videotex, closer to telex) terminals. So "attaching video terminals to mainframes" does seem like a fair summary. Possibly Graham doesn't know what the word "videotex" means, or thought (as I did, neither of us having lived in Germany) that "teletex" was a kind of videotex.

I agree that it doesn't have the kind of functionality that HTTP cookies provide. That's backwards, I think? HTTP cookies provide session context that persists over multiple TCP-level connections; the reuse of a single transport connection between different X.225 sessions is more like reusing a single TCP-level connection for multiple HTTP requests, or multiple users logging in and out, one after the other, on the same hardwired terminal without resetting it?

I wish it gave examples of usage so I knew what the resynchronization functionality was for. Maybe you know?

Expedited data is a thing that TCP also has, and I've never really understood what it was for there either. Maybe it's for sending a ^C over a remote terminal login session when the keyboard buffer is full because the application you're talking to is hung? The "activity interrupt" stuff seems like it would be a better fit for that, but maybe the expedited data facility was an older design that was retained for backward-compatibility?

Having just skimmed X.225 thanks to OhMeadhbh (https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.22...) I think Graham is correct that we don't have anything similar to the OSI "session" layer in the stack you're talking about; although the ARPANET TELNET protocol does have a lot of the same functionality, there's nothing analogous in SSL+https+JSON+RPC. I'm guessing the same is true of the "presentation" layer, but I'm certainly open to hearing why you think otherwise, if you do.

Also, if you happen to be familiar with X.225 (or read it following my prompt above), I have some questions in https://news.ycombinator.com/item?id=41789004!

Graham makes a good argument that, although there are some promising analogies between the physical/data-link/network/transport layers and the PHY/MAC/IP/TCP layers of TCP/IP over Ethernet, the model is overall a very poor fit even at those layers; it's better to not try to decompose network stacks into a predetermined set of layers, because the actual set of layers used is variable depending on the application and the environment.

I think naming quality isn't really a difference between OSI and TCP/IP. I'm sending this message in URL-encoded UTF-8 in MIME over HTTP over TLS and TCP, IP, MPLS, DOCSIS, and an 802.11g CSMA/CA MAC in a CIDR IP block allocated by ARIN via LACNIC to an AS that belongs to a CLEC; ultimately you'll use an URL to read it in HTML, and if your UA is like mine, you'll use ECDHE ECDSA with AES-256-GCM and SHA-384, verified through a CA chain through E5 (which supports OCSP) and ISRG. But nobody bats an eye at that because that alphabet soup has been familiar for decades.