Wow that `let url` example taking 10 seconds and only down to 6 seconds now is shockingly bad. As someone who recently started getting into iOS/macOS development and has noticed these wildly slow type checking times on my M2 Air, this is enough to make me reconsider if I want to invest in this platform...
No joke, that's just wild. I'd expect an expression like that to type-check literally a million times faster - at the least. Even after reading the article, it's not clear why that particular expression is so egregiously poor.
> The Swift standard library has 17 overloads of + and 9 types adopting the ExpressibleByStringLiteral Protocol. This leads to an exponential combination of types and operators for the constraint solver to try.
I think the ExpressibleBy thing means that a string literal can be interpreted to mean any of those 9 types. Personally I agree with you; I would actually suggest that the compiler error out if there are anywhere near this many interpretations of an expression. Apparently the corrected expression compiles in 0.19s, which is unacceptable to me. I would much rather pay the cost once of adding a few type annotations or intermediate expressions than pay that fifth of a second over and over and over again for every recompile of that file. Since the types a pretty global constraint system, the expression is a landmine as well: you could fiddle with some distant overload which causes it to attempt the permutations in a different order and suddenly start timing out again.
I love the clean syntax of Swift, which allows you to omit a lot of syntactic noise. It's so much nicer to write and read than for example Rust with it's ugly wordiness. But the type checker performance really is inacceptable.
I too appreciate detail-free programs, and I wonder at the value of including all the typedecls and pointer markings, and lifetime markings, and mutability markings interleaved with the logic. Some people I guess believe that the details are "part of the program" and they aid understanding. Do you buy that?
I find that sometimes typedecls aid understanding, but they get in the way if they're the least bit complicated. I'm better off reading the program. I never had problems understanding Lisp programs for some reason.
Slava mentions both bidirectional inferencing and overloading as two of the big culprits.
I've been doing some language work recently, and I'm quite sympathetic to bidirectional inferencing. I think, though, that modern PLs need better solutions for adhoc overloading. It's notorious for its complexity, blowing up algorithmically, and confusing users with surprising results (why oh why did the compiler select this function over the one I intended). That said, I haven't discovered a good alternative (for my purposes) yet.
As someone who started doing SwiftUI recently, it absolutely boggles my mind that (1) this is even a thing and (2) Apple seem ok to treat it as an unsolvable problem.
When you finally solve it is some stupid wrong type passed in somewhere.
I agree with the other poster. This is so pathetic it makes me question the competence of the engineers working on Swift.
Smells like “we made a poor architectural / design choice and ain’t walking it back”.
Type annotate everything. Don’t mix integers and doubles, be explicit.
Most important of all, do not ever make a long chain of nested result building function calls with those stupid trailing untyped dangling {} closures, especially when the closure expects an implicit return of an opaque ‘some’ type.
What I’m saying is, don’t use SwiftUI. It’s a pee filled kiddie pool to attract JavaScript react devs with awful performance and semantics.
About time! Nothing kills productivity like waiting 30s for the compiler to tell you it can't infer a type on line 27437 (who needs to refactor?). The diagnostic improvements alone will be worth it really but...
Wow that `let url` example taking 10 seconds and only down to 6 seconds now is shockingly bad. As someone who recently started getting into iOS/macOS development and has noticed these wildly slow type checking times on my M2 Air, this is enough to make me reconsider if I want to invest in this platform...
No joke, that's just wild. I'd expect an expression like that to type-check literally a million times faster - at the least. Even after reading the article, it's not clear why that particular expression is so egregiously poor.
From the post they link to:
> The Swift standard library has 17 overloads of + and 9 types adopting the ExpressibleByStringLiteral Protocol. This leads to an exponential combination of types and operators for the constraint solver to try.
I think the ExpressibleBy thing means that a string literal can be interpreted to mean any of those 9 types. Personally I agree with you; I would actually suggest that the compiler error out if there are anywhere near this many interpretations of an expression. Apparently the corrected expression compiles in 0.19s, which is unacceptable to me. I would much rather pay the cost once of adding a few type annotations or intermediate expressions than pay that fifth of a second over and over and over again for every recompile of that file. Since the types a pretty global constraint system, the expression is a landmine as well: you could fiddle with some distant overload which causes it to attempt the permutations in a different order and suddenly start timing out again.
> Even after reading the article, it's not clear why that particular expression is so egregiously poor.
I'm glad I'm not the only one wondering why this is not instant to type check.
Plus is heavily overloaded
That Chris Lattner is taking a very different approach to the type checker in Mojo is afaik due to this kind of thing.
I love the clean syntax of Swift, which allows you to omit a lot of syntactic noise. It's so much nicer to write and read than for example Rust with it's ugly wordiness. But the type checker performance really is inacceptable.
I too appreciate detail-free programs, and I wonder at the value of including all the typedecls and pointer markings, and lifetime markings, and mutability markings interleaved with the logic. Some people I guess believe that the details are "part of the program" and they aid understanding. Do you buy that?
I find that sometimes typedecls aid understanding, but they get in the way if they're the least bit complicated. I'm better off reading the program. I never had problems understanding Lisp programs for some reason.
Slava mentions both bidirectional inferencing and overloading as two of the big culprits.
I've been doing some language work recently, and I'm quite sympathetic to bidirectional inferencing. I think, though, that modern PLs need better solutions for adhoc overloading. It's notorious for its complexity, blowing up algorithmically, and confusing users with surprising results (why oh why did the compiler select this function over the one I intended). That said, I haven't discovered a good alternative (for my purposes) yet.
As someone who started doing SwiftUI recently, it absolutely boggles my mind that (1) this is even a thing and (2) Apple seem ok to treat it as an unsolvable problem. When you finally solve it is some stupid wrong type passed in somewhere. I agree with the other poster. This is so pathetic it makes me question the competence of the engineers working on Swift.
Smells like “we made a poor architectural / design choice and ain’t walking it back”.
Follow a couple of rules and this won’t happen.
Type annotate everything. Don’t mix integers and doubles, be explicit. Most important of all, do not ever make a long chain of nested result building function calls with those stupid trailing untyped dangling {} closures, especially when the closure expects an implicit return of an opaque ‘some’ type.
What I’m saying is, don’t use SwiftUI. It’s a pee filled kiddie pool to attract JavaScript react devs with awful performance and semantics.
That is exactly what happened and the competence of the engineers working on the language is not really relevant.
About time! Nothing kills productivity like waiting 30s for the compiler to tell you it can't infer a type on line 27437 (who needs to refactor?). The diagnostic improvements alone will be worth it really but...
Going from 10s down to 6s is not nearly near sufficient to me. This should be instant.