As I've been giving presentations about the origins of Hylo and its position in the language ecosystem as a descendant of Swift, I've been digging more deeply into the history of Rust, because it inhabits an adjacent niche. It seems as though Swift and Rust are converging substantially these days, which is interesting… but I'm wondering about the early years, when I was involved in the design of Swift. It seems as though the generics systems were very close to one another, even early on, but I don't recall much discussion of Rust in our design meetings. Did the languages evolve entirely in parallel to a similar design point, or was there more discussion of Rust than I'm remembering?
I remember us looking at Rust occasionally, but we also looked at Haskell, SML, and of course concepts in C++. I’d say our generics systems ended up so similar mostly because we made the same basic decisions in what’s ultimately a pretty constrained design space. Formally, we’re talking about predicates over types (+ potentially other type-level entities). We elected to use nominal, declarative, unary predicates, and that pretty much sets everything else in stone.
As someone with at best a very dim understanding of the formal foundations of type systems, I'm curious: what would a type system look like with non-unary predicates?
For what it’s worth, I think Rust’s then-still-experimental existence helped demonstrate the importance and viability of value semantics, that you could win at eliminating races and “spooky action at a distance” with “shared XOR mutable” and not just “immutable”. The leading languages of the 2000s were either OO or functional and didn’t really have that option. I think you (Dave) already had a good sense of this from your C++ work, but while C++ probably counts as the first major language to support value semantics, it doesn’t really help you do it safely. At least not like Rust and Swift and Hylo do.
That said, this might all be personal slant, because I was most familiar with functional and OO languages when I joined the Swift project (and C and C++), and Rust was my first introduction to shared XOR mutable.
Yeah, multi-parameter type classes are the main thing I was thinking of. SML struct signatures can express analogous things but are ultimately a completely different language model because they're not really linked to the types involved (nor need there be types involved).
As an outside Rust observer (and inside Swift observer) I can say the following (personal perspective, but we all live in a bubble):
given the evolution of Swift, and the gradual introduction of sophisticated and safe but approachable and progressively disclosed language constructs, it seems to me that being an "easier Rust" was actually an underlying leitmotif of Swift design;
in the community at large, non–Swift devs that want to look at these things with an open mind and are not prejudiced against Swift are perceiving it more and more as an "easier Rust";
my personal view is that Swift can be already considered close to an "easier Rust" alternative, and it's getting closer and closer.
Due to the mobile development space, many consider Kotlin instead as a similar language, with similar goals, but I couldn't disagree more.
I’m not an expert, but my gut feeling says that if you’re looking at those languages simultaneously—pretty often you’ll end up in similar design choices as in Swift or Rust.
In fact several members of the Rust team have made important contributions to Swift, and of course Swift alumni went on to work on other languages as well, including Rust I’m pretty sure. The world of compiler development is pretty small so a lot of cross-pollination happens just from folks moving around between projects.
It's a small world for sure, but it's not every day you get the creator of one successful, living, breathing language jumping over to work on one of its contemporary "competitors".
This is not to say or imply that Swift copied Rust or anything, it's just a remarkable fact that seemingly few people know.