Future of swift types


Would you mind explaining what this is about?

1 Like

It’s interesting to read the first post in that thread if only to realize how much more simply Julia achieves the same functionality as “existential types” (= container for an abstract type, maybe parametrized by a trait) and “reverse generics” (= callee decides on return type). This is not a criticism of the Swift developers, however—statically typed languages are simply much more constrained.


My biggest issue with static PL proponents is that there’s an ongoing collective refusal to acknowledge that static type checking is not all upside. Especially once you get into generics and higher order programming, the design and implementation cost of being required to be able to type check every valid program is simply staggering. One of the worst symptoms of this problem can be seen in the massive difficulties that practical static languages keep having with their collections libraries. In this case it’s Swift, but Scala has famously had major problems in this area (that was some years ago, I’m not sure where they’re at now). Go, even more famously, has simply refused to add generics—if I’m interpreting it correctly, precisely to avoid this whole morass.

Yes, being able to check types for any possible program at compile time is a nice property, but at what cost? If Julia has proved one thing with regard to programming language design, it’s that you can get a huge amount of benefit from a type system without using it for static type checking at all. Maybe that’s not the primary thing type systems should be designed for. Heck, maybe you should be allowed to call something “a type system” even if it’s not primarily intended for static type checking!


I understand your position, but IMO you’re not being entirely fair. Go 2.0 supposedly will add generics, which are practically a necessity for any statically typed language, and Paul Phillips’ issues with Scala development were not really about the impracticality of typing generics. Sure, the cost of getting all of this right and implemented is high, but “It takes a tough man to make a tender chicken”.

That said, yes, it’s obvious that neither static typing and dynamic typing are all upside. I really like the way that Julia took another position in the space, and I hope that in the future some external tooling can be used to get more of the benefits of static typing without compromising Julia’s dynamic nature. I’ve been happily surprised with Julia code that that I wrote that was unexpectedly polymorphic in a useful way.

Another example of this kind of collective refusal to see the other side in PL design s with respect to tracing garbage collection. The pendulum has swung back and forth there quite a bit too.