[wudangmonk]

What a dumpster fire Swift turned out to be. My first experience with it saw compile times go up more than 10x from the previous objc code base. Everytime more and more of apple's libraries were replaced because all the objc stuff was considered obsolete the compile times got worst and worst.

Its not like I dislike the language either but I think compile times matter so languages should not pretend like that doesn't exist. I can forgive Rust its giving you more than just type checking but Swift does not offer the same things yet it takes just as long or longer to compile.

[KerrAvon]

They both compile slowly because they have similarly complicated type systems. What do you use in Rust that Swift doesn’t yet provide?

[ozten]

There are a very large list of foundational capabilities so that it’s not practical to respond with a concise answer. One example is automatically closing resources on behalf of the caller thanks to lifetimes. Another example is the best compiler feedback of any mainstream language.

[wudangmonk]

You can have a good type system and have fast compile times. In every single language with 'complicated type systems' it always comes down to type inference on polymorphic types which causes these issues, this has been known for over 40 years yet the same issue seems to be rediscovered again and again like it was something new.

I sure hope the author learned the right lesson from the failure that is Swift and Mojo turns out to be better. I do not want a language with a complicated type system and long compile times. I want a 'good enough' type system and fast compile times.

[aw1621107]

> it always comes down to type inference on polymorphic types which causes these issues

Unless I'm thinking of something different, doesn't OCaml have type inference on polymorphic types and fast(ish?) compile times?

I was under the impression that the breakdown of causes for Rust projects compiling slowly is very project-dependent as well. From what I can remember common culprits were monomorphization and/or LLVM, though I'm not sure if that has changed recently.

[octachron]

Fast (and principled) inference for not-too-complicated polymorphic types is an explicit design goal for OCaml and Haskell languages. And this design goal constraint quite a lot the type system.

Typically, there are many type system features that break this property and where OCaml and Haskell requires type annotations (for instance polymorphic functions that takes polymorphic functions as arguments and use them in a polymorphic way).

As a consequence, typechecking for OCaml programs tend to take from 10% to 60% of the whole compilation time for typical programs. However, for OCaml programs that make heavy use of GADTs typechecking can dominate the compilation time (probably due to the exhaustiveness check but I have yet to empirically check that).

Infamously, Swift made the choice to introduce a typechecking algorithm with an exponential complexity in the size of expression (to support function overloading and literals) even for simple types.

[aw1621107]

Fascinating! Thanks for the insight!

Does the up to 60% figure include programs that make heavy use of GADTs, or are those even worse in terms of the proportion of compilation time spent type checking?

I had no idea Swift's type checking algorithm is exponential. How easy is it to run into those conditions?

[octachron]

For GADTs heavy programs, it depends a lot on how much work the exhaustiveness check for pattern matching is doing behind the scene: With GADTs, one can encode a Turing machine in the type system. In that pathological case, analyzing that a pattern match is exhaustive might require to check if the encoded Turing machine stops in n steps. Consequently, it is perfectly possible to write programs where the compiler spends 99% of its time on analyzing pattern matching. But it is also possible to write GADTs heavy programs that don't require such expensive analyses.

I have no first-hand experience with Swift but the previous discussion at https://news.ycombinator.com/item?id=12108876 and the description of the problematic algorithm seems to indicate that numerical or mathematical code can run quite easily into the issue.

However, I must add that type inference algorithms being exponential in the source code size is nothing new: OCaml and Haskell inference are also exponential in the source code size. But that is because the size of types can be exponential in the source code size. Moreover, type inference complexity in OCaml and Haskell is linear in the size of types. And since in practice, no one ever uses exponentially growing types, type inference stays well behaved.

The specific issue with Swift is really more that even for simple result types, the inference may still have to do an exponential amount of guess work.

[xedrac]

Catch data races at compile time?

[turdprincess]

I don’t know much about Rust, but Swift can prevent data races at compile time by using the Actor type.

[astrange]

It could catch them before that using ownership, at the cost of lower performance.

Though Swift concurrency is mostly about "concurrency" not "parallelism", which is the one that has data races.

[saagarjha]

Ownership hasn’t shipped yet.

[astrange]

It has an ABI-level ownership thing already. What's missing is ways to control it.

[kitsunesoba]

While low compile times are nice I don't find them strictly necessary for the day-to-day because I'm not constantly doing full builds. Swift's incremental compiles are more than fast enough for my needs, especially on M1/Ryzen 5000 or better.