[jerf]

"What type system feature does Golang have that was invented post 1990?"

Popularity and a set of libraries useful enough to do real work in it unlike anything else I know with structural typing.

What feature does Rust have that wasn't invented in some academic paper by the 1990s if not sooner?

An advance doesn't much matter to people doing real work if it doesn't come coupled to a practical language and a set of libraries that enables real work. This is sad in a way, because "the set of libraries that enables real work" bar is going up every year, which makes new languages harder. See also "Why did Haskell need 15 years to take off?", the answer being "that's when people started putting together practical libraries" among other things.

In 2025, when $PRACTICAL_DEPENDENTLY_TYPED_LANGUAGE is finally taking the Hacker News world by storm, I will not take kindly to suggestions that we could have and should have been using it in 2015 or earlier. No, we couldn't and can't. They're not useful yet, no matter how theoretically beautiful they could be.

[pcwalton]

If you concede that Go didn't do anything new other than getting popular, then I can't find anything to disagree with.

> What feature does Rust have that wasn't invented in some academic paper by the 1990s if not sooner?

Actually, the borrow check is novel (though you can find precursors in Cyclone and fractional permissions work), and I think that is responsible for a lot of Rust's popularity (as it enables memory safety with dynamic allocation and no garbage collection, something that is actually new). But the answer you were looking for is "nothing", and that's precisely my point in regards to Golang. This stuff isn't new. Specific repackagings of it are getting popular, but I think that factors unrelated to the technical details of the type system have been largely responsible for that.

(I also continue to disagree that structural typing as implemented in Go is a useful feature—I think it's a net negative for usability because it saves a few keystrokes at the cost of precluding implementing interfaces for types outside of the package they were defined in without writing annoying wrapper structs—but that's neither here nor there.)

[jerf]

"I think it's a net negative for usability because it saves a few keystrokes at the cost of precluding implementing interfaces for types outside of the package they were defined in without writing annoying wrapper structs"

It's a very pragmatic answer. As someone who generally straddles the pragmatic/theoretical divide, I mean that both fully as praise and fully as condemnation. ("Do I contradict myself? Very well, then I contradict myself, I am large, I contain multitudes." - Walt Whitman)

I never did hear what Rust decided to do about what Haskell called the "orphan instances" problem, I only heard about the problem... what happened there? (Honest question, not critical in any way.)

[pcwalton]

Orphan instances are forbidden in Rust. But you can still implement traits for types that weren't defined in your crate as long as your crate defined the trait, which is an extremely important feature that Rust code uses all the time (and is incompatible with structural typing).