6 ms·

Why Swift's type checker is so slow

74 points by misonic 2y ago

ayhanfuat 2y ago
The Swift compiler is slow due to how types are inferred | 256 points by paraboul | 9 days ago | 216 comments | https://news.ycombinator.com/item?id=40661001 https://news.ycombinator.com/item?id=40661001
noelwelsh 2y ago
> My experience with Swift is we tried to make a really fancy bi-directional Hindley-Milner type checker and it’s really great because you can have very beautiful minimal syntax but the problem is that A) compile times are really bad (particularly if you have complicated expressions) and B) the error messages are awful because now you have a global constraint system and when something goes wrong you have to infer what happened and the user can’t know that something over there made it so something over here can’t type check. In my experience it sounds great but it doesn’t work super well. I feel like B) is very well known in the programming language community. I certainly heard people talking about in at least ~20 years ago. A) should be obvious in the presence of overloading. I guess the type inference algorithm becomes part of the assumed semantics of the language and it's difficult to change after the fact.
- pkkm 2y ago
  Yeah, my impression is that B happened earlier in Haskell. 1. Let's create a super advanced type inference system so that you can write Haskell like a dynamic language but have it be static. 2. Oops, now when you make a mistake, it propagates through your program and causes a type error somewhere completely different. 3. New code style rule: you may omit type signatures on local functions, but always place them on top-level functions so that they serve as a barrier to incorrect type inferences.
  - Jensson 2y ago
    What those people miss is that the productive part about dynamically typed languages isn't that you don't have to write the types, but that the types used by dynamically types languages are extremely ergonomic and can fit in many different contexts so you rarely get type errors. Trying to write untyped dynamic code in a statically typed language thus just results in frustration, those languages were made to work statically and to throw a lot of type errors, they are horrible as dynamic languages.
    - dtech 2y ago
      Could not display comment. Typerror: undefined is not a function
      - kosolam 2y ago
        Lol
    - almostgotcaught 2y ago
      > What those people miss is that the productive part about dynamically typed languages isn't that you don't have to write the types, but that the types used by dynamically types languages are extremely ergonomic and can fit in many different contexts so you rarely get type errors. This isn't true at all. I write a lot of python and I don't think I've ever had a duck-typing happy coincidence that wasn't an error. No it's exactly that I'm only depending on the aspect of the type that I need at the call/use site (so I can update types while maintaining those contracts and I don't need to update any signatures anywhere).
cageface 2y ago
Unfortunately SwiftUI heavily loads the type system in order to achieve its terse view builder syntax. So builds are really slow and the compiler very often just refuses to compile things and offers zero suggestions for fixes. I hate to say it but I think Apple made some fundamental mistakes here that are going to be hard to undo.
- steve1977 2y ago
  > Apple made some fundamental mistakes here that are going to be hard to undo. Thankfully Apple is always open to own their mistakes and correct them. /s
lovasoa 2y ago
let result: Double = -(1 + 1) + -(1 + 1) - 1 Swift 6 takes 6.2 seconds to compile this one line. That's crazy... Swift programmers: do you face this kind of issues often?
- amedvednikov 2y ago
  [flagged]
  - mort96 2y ago
    What the hell is up with HN people's fascination with V? HN is the only place I ever see people who have drank the V kool-aid. Why is the HN crowd seemingly so gullible? It's the same thing with cryptocurrencies and AI and NFTs; if there is a tech-adjacent hype train, you can bet there's constant spam from HN commenters who have bought it hook, line and sinker. Stop. It's boring.
    - maleldil 2y ago
      You replied to the creator of the V language.
      - mort96 2y ago
        Ah. And therein may lie the source of my frustration: HN is full of not only gullible people who fall for these scams, but also the very perpetrators of these scams, using HN as a tool to generate hype.
        amedvednikov 2y ago
        Ironic coming from a gullible person calling a legit open source project a scam.
        videogreg93 2y ago
        Why is v a scam? Genuinely curious, I don't know much about it besides it being a c++ competitor.
mort96 2y ago
My cell carrier (Telenor) has apparently identified this site as malicious and is preventing me from visiting... now I can disable the filter for my account and visit anyway, but the owner of the site may want to check that out
- dhooper 2y ago
  I’m the owner of the site - does telenor provide any info on why the site seems malicious?
  - mort96 2y ago
    Sadly, no. It just says: "You're about to go to an unsafe web site! Nettvern from Telenor has therefore blocked this web site to protect you from digital threats." ("Nettvern" is the name of this "feature", and it's enabled by default)
alexvitkov 2y ago
80/20 rule. The dumbest possible type inference algorithm... let x = value; // typeof(x) is now typeof(value) ... covers 80% of the cases where you'd like type inference. I'd even argue it's way more than 80%. Surprisingly, this is what C++ actually went for, and `auto` works just fine. Same in TypeScript - make a best effort guess from the value, fallback to `any` no value or type is given. Having to write out a type every now and then costs me way less time than waiting for the compiler to finish playing minimax against itself in the latent space of all possible programs or whatever.
TheAceOfHearts 2y ago
Just last night I was watching a video on Jai from Jonathan Blow, and he was showing off how he could compile a game demo of +50k lines from scratch in under 0.5 seconds, with plenty of room left for optimizations. Which really makes me question if language design is going in the correct direction. Are Swift programs less likely to contain bugs or are they easier to debug? I know that many of Swift's creators are incredibly experienced programming languages experts, so how do they justify this insane compilation tax?
- machinekob 2y ago
  Jai is a lot slower atm than at 2018, and feature-wise it is closer to C than to Swift with 2 different purposes. Swift compiler time is spend mostly on LLVM stuff and it isn't much slower than other modern LLVM languages (Rust/Julia etc.) <ofc. this don't count this very specific complex type checks that are super slow>
  - christophilus 2y ago
    Isn’t Jai also LLVM backed? I thought it was, though I haven’t followed it closely. Edit: random forums on the interwebs do seem to suggest it is LLVM backed.
    - machinekob 2y ago
      They have both llvm and custom x64 backend (at least partially, i think they started with only custom x64 backend)
- lovasoa 2y ago
  I think the justification is that outside of pathological cases, it allows writing clean code without too many type annotations, and the compiler just figures out everything for you.
- deleted 2y ago
  [deleted]
patwoz 2y ago
I started using swift after the last wwdc and really fell in love with the language. It's really elegant and powerful at the same time. I just tried the compiler flags, but the slowest expression is only 3 ms in my 1014loc project. Still very helpful to see where my slowest expressions are. I think I will set the threshold to 1ms and avoid slow expressions at all.
grumpyprole 2y ago
> the user can’t know that something over there made it so something over here can’t type check To the Swift developers: just add source positions to your type AST, in addition to the term AST, then you'll know where a type has come from. It lets you give error messages like: expected type A (line X) but got type B (line Y). Hindley-Milner type checkers perform well in Haskell and OCaml. I don't think this type system can be blamed entirely for Swifts problems.
knighthack 2y ago
I almost feel like a discussion about how Go's compiler is crazy fast is warranted in this thread.
deleted 2y ago
[deleted]
seanalltogether 2y ago
So I manage a fairly large ios project and never really took the time to properly validate compile times, so I just started playing around with it and found some nice little surprises. let horizpadding = self.collectionView.frame.width - ((5*50)+(4*25)) Expression took 1299ms to type-check (limit: 500ms) Now obviously this expression could have been simplified long ago as a single constant, but the values themselves were written to help others understand what that constant meant (5 elements that are 50px wide) + (4 gutters that are 25px wide)
- sumuyuda 2y ago
  You can have a comment above the constant explaining the math of how it was calculated.
christophilus 2y ago
Ocaml is really fast to compile when I play with toy projects. It’s a fairly simple type system compared to, say, TypeScript (I’m not familiar enough with Swift to know how it compares to Ocaml in terms of type system complexity). I’d prefer the simpler language if it means faster compilation.
modulovalue 2y ago
That's where Dart and Flutter shine. Sadly, people discussing Swift/SwiftUI, Kotlin/KMP, and Dart/Flutter often only have surface-level comments that do not address potential issues like these. Dart's static type system has been designed to avoid such problems. Not once have I had, or heard of, a performance issue related to the Dart type checker. That's also one of the reasons why hot reload always works as expected.
lovasoa 2y ago
How can it be a good idea to have a time limit for the compilation of expressions in a compiler ? Doesn't that mean that your program can compile fine in the morning, and fail to compile in the afternoon because you have an HD youtube video playing in the background ? Or the same program could compile fine on your computer, and fail to compile on less powerful CI servers ?

74 points by misonic 2y ago

The Swift compiler is slow due to how types are inferred | 256 points by paraboul | 9 days ago | 216 comments | https://news.ycombinator.com/item?id=40661001 https://news.ycombinator.com/item?id=40661001

noelwelsh 2y ago

> My experience with Swift is we tried to make a really fancy bi-directional Hindley-Milner type checker and it’s really great because you can have very beautiful minimal syntax but the problem is that A) compile times are really bad (particularly if you have complicated expressions) and B) the error messages are awful because now you have a global constraint system and when something goes wrong you have to infer what happened and the user can’t know that something over there made it so something over here can’t type check. In my experience it sounds great but it doesn’t work super well. I feel like B) is very well known in the programming language community. I certainly heard people talking about in at least ~20 years ago. A) should be obvious in the presence of overloading. I guess the type inference algorithm becomes part of the assumed semantics of the language and it's difficult to change after the fact.

pkkm 2y ago
Yeah, my impression is that B happened earlier in Haskell. 1. Let's create a super advanced type inference system so that you can write Haskell like a dynamic language but have it be static. 2. Oops, now when you make a mistake, it propagates through your program and causes a type error somewhere completely different. 3. New code style rule: you may omit type signatures on local functions, but always place them on top-level functions so that they serve as a barrier to incorrect type inferences.
- Jensson 2y ago
  What those people miss is that the productive part about dynamically typed languages isn't that you don't have to write the types, but that the types used by dynamically types languages are extremely ergonomic and can fit in many different contexts so you rarely get type errors. Trying to write untyped dynamic code in a statically typed language thus just results in frustration, those languages were made to work statically and to throw a lot of type errors, they are horrible as dynamic languages.
  - dtech 2y ago
    Could not display comment. Typerror: undefined is not a function
    - kosolam 2y ago
      Lol
  - almostgotcaught 2y ago
    > What those people miss is that the productive part about dynamically typed languages isn't that you don't have to write the types, but that the types used by dynamically types languages are extremely ergonomic and can fit in many different contexts so you rarely get type errors. This isn't true at all. I write a lot of python and I don't think I've ever had a duck-typing happy coincidence that wasn't an error. No it's exactly that I'm only depending on the aspect of the type that I need at the call/use site (so I can update types while maintaining those contracts and I don't need to update any signatures anywhere).

cageface 2y ago

Unfortunately SwiftUI heavily loads the type system in order to achieve its terse view builder syntax. So builds are really slow and the compiler very often just refuses to compile things and offers zero suggestions for fixes. I hate to say it but I think Apple made some fundamental mistakes here that are going to be hard to undo.

steve1977 2y ago
> Apple made some fundamental mistakes here that are going to be hard to undo. Thankfully Apple is always open to own their mistakes and correct them. /s

lovasoa 2y ago

let result: Double = -(1 + 1) + -(1 + 1) - 1 Swift 6 takes 6.2 seconds to compile this one line. That's crazy... Swift programmers: do you face this kind of issues often?

amedvednikov 2y ago
[flagged]
- mort96 2y ago
  What the hell is up with HN people's fascination with V? HN is the only place I ever see people who have drank the V kool-aid. Why is the HN crowd seemingly so gullible? It's the same thing with cryptocurrencies and AI and NFTs; if there is a tech-adjacent hype train, you can bet there's constant spam from HN commenters who have bought it hook, line and sinker. Stop. It's boring.
  - maleldil 2y ago
    You replied to the creator of the V language.
    - mort96 2y ago
      Ah. And therein may lie the source of my frustration: HN is full of not only gullible people who fall for these scams, but also the very perpetrators of these scams, using HN as a tool to generate hype.
      - amedvednikov 2y ago
        Ironic coming from a gullible person calling a legit open source project a scam.
      - videogreg93 2y ago
        Why is v a scam? Genuinely curious, I don't know much about it besides it being a c++ competitor.

mort96 2y ago

My cell carrier (Telenor) has apparently identified this site as malicious and is preventing me from visiting... now I can disable the filter for my account and visit anyway, but the owner of the site may want to check that out

dhooper 2y ago
I’m the owner of the site - does telenor provide any info on why the site seems malicious?
- mort96 2y ago
  Sadly, no. It just says: "You're about to go to an unsafe web site! Nettvern from Telenor has therefore blocked this web site to protect you from digital threats." ("Nettvern" is the name of this "feature", and it's enabled by default)

alexvitkov 2y ago

80/20 rule. The dumbest possible type inference algorithm... let x = value; // typeof(x) is now typeof(value) ... covers 80% of the cases where you'd like type inference. I'd even argue it's way more than 80%. Surprisingly, this is what C++ actually went for, and `auto` works just fine. Same in TypeScript - make a best effort guess from the value, fallback to `any` no value or type is given. Having to write out a type every now and then costs me way less time than waiting for the compiler to finish playing minimax against itself in the latent space of all possible programs or whatever.

TheAceOfHearts 2y ago

Just last night I was watching a video on Jai from Jonathan Blow, and he was showing off how he could compile a game demo of +50k lines from scratch in under 0.5 seconds, with plenty of room left for optimizations. Which really makes me question if language design is going in the correct direction. Are Swift programs less likely to contain bugs or are they easier to debug? I know that many of Swift's creators are incredibly experienced programming languages experts, so how do they justify this insane compilation tax?

machinekob 2y ago
Jai is a lot slower atm than at 2018, and feature-wise it is closer to C than to Swift with 2 different purposes. Swift compiler time is spend mostly on LLVM stuff and it isn't much slower than other modern LLVM languages (Rust/Julia etc.) <ofc. this don't count this very specific complex type checks that are super slow>
- christophilus 2y ago
  Isn’t Jai also LLVM backed? I thought it was, though I haven’t followed it closely. Edit: random forums on the interwebs do seem to suggest it is LLVM backed.
  - machinekob 2y ago
    They have both llvm and custom x64 backend (at least partially, i think they started with only custom x64 backend)
lovasoa 2y ago
I think the justification is that outside of pathological cases, it allows writing clean code without too many type annotations, and the compiler just figures out everything for you.
deleted 2y ago
[deleted]

patwoz 2y ago

I started using swift after the last wwdc and really fell in love with the language. It's really elegant and powerful at the same time. I just tried the compiler flags, but the slowest expression is only 3 ms in my 1014loc project. Still very helpful to see where my slowest expressions are. I think I will set the threshold to 1ms and avoid slow expressions at all.

grumpyprole 2y ago

> the user can’t know that something over there made it so something over here can’t type check To the Swift developers: just add source positions to your type AST, in addition to the term AST, then you'll know where a type has come from. It lets you give error messages like: expected type A (line X) but got type B (line Y). Hindley-Milner type checkers perform well in Haskell and OCaml. I don't think this type system can be blamed entirely for Swifts problems.

knighthack 2y ago

I almost feel like a discussion about how Go's compiler is crazy fast is warranted in this thread.

deleted 2y ago

[deleted]

seanalltogether 2y ago

So I manage a fairly large ios project and never really took the time to properly validate compile times, so I just started playing around with it and found some nice little surprises. let horizpadding = self.collectionView.frame.width - ((5*50)+(4*25)) Expression took 1299ms to type-check (limit: 500ms) Now obviously this expression could have been simplified long ago as a single constant, but the values themselves were written to help others understand what that constant meant (5 elements that are 50px wide) + (4 gutters that are 25px wide)

sumuyuda 2y ago
You can have a comment above the constant explaining the math of how it was calculated.

christophilus 2y ago

Ocaml is really fast to compile when I play with toy projects. It’s a fairly simple type system compared to, say, TypeScript (I’m not familiar enough with Swift to know how it compares to Ocaml in terms of type system complexity). I’d prefer the simpler language if it means faster compilation.

modulovalue 2y ago

That's where Dart and Flutter shine. Sadly, people discussing Swift/SwiftUI, Kotlin/KMP, and Dart/Flutter often only have surface-level comments that do not address potential issues like these. Dart's static type system has been designed to avoid such problems. Not once have I had, or heard of, a performance issue related to the Dart type checker. That's also one of the reasons why hot reload always works as expected.

lovasoa 2y ago

How can it be a good idea to have a time limit for the compilation of expressions in a compiler ? Doesn't that mean that your program can compile fine in the morning, and fail to compile in the afternoon because you have an HD youtube video playing in the background ? Or the same program could compile fine on your computer, and fail to compile on less powerful CI servers ?