Every time I tinker with languages like Rust or Crystal or Swift, I am amazed by their compilation times. OCaml and Pascal got this right aeons ago. I’m looking forward to a public release of Jai simply because compilation speed is one of its primary motivations. Having a fast feedback loop is crucial to my adhd-like development workflow.
> I am amazed by their compilation times. OCaml and Pascal got this right aeons ago
Pascal doesn’t do type inference at all.
I think OCaml meets both of the non-goals mentioned in the article:
“There are also two non-goals worth mentioning:
Removing overloading from the language. Without disjunction constraints, a constraint system can almost always be solved very quickly. However, this would be such a major change to the language, and break so many existing APIs, that it is not feasible to attempt at this point, even as a new language mode.
Removing bidirectional inference. We can also imagine a language design where expressions are type-checked in a strictly bottom-up fashion, starting from the leaves, like in many other C-family languages. This is another drastic simplification that essentially trivializes the whole problem. However, this would require giving up on language features such as polymorphic literals, leading-dot member syntax, closures with inferred types, and parts of generics. All of these are features that make Swift into the expressive language it is today.”
So, both are fast because they do less. Given that Apple hasn’t managed to make the Swift compiler even somewhat swift (pun intended) I think that partly is the right choice.
Great. Give me that with a modern toolchain and a good stdlib, and I’ll be one happy dev. Swift focused on solving the wrong problem. I don’t need overloading or bidirectional inference. I need fast compilation, good tooling, and a solid stdlib.
On a somewhat related note, Swift has a particularly nifty type erasure system that allows it to avoid monomorphizing everything, and I think some Rust people would appreciate if such a system magically appeared for Rust. As I understand it, implementing it would be a lot of work.
> The invalid expression from above, where + was applied to String and Int, is still rejected, however with the new algorithm, it only takes the compiler 2 seconds to reach the limit.
I think failing is okay, as the expression can then be explicitly typed. But if it would be solved slowly by the type checker, does Xcode show a slow compile warning for the line that this code should be optimized?
> However, an integer literal such as 123 actually has two default types, Int and Double, and the resulting disjunction has three choices. It might be worth considering a language change where floating point literals must be spelled with a decimal point. Today, expressions involving mixed integer and double literals can be particularly tricky to type check, for this reason.
The habit to write 123.0 for floats is second nature. I think this is a good idea, don’t know if other programmers would find that annoying? (aside the annoyance of changing existing code bases).
For your first question, yes, it can be optionally turned on and set to a specific value. In the early days of Swift it was quite useful. I still have it on in one project but it rarely shows up anymore and when it does it is usually a mystery as to why it shows up and there's no clear way to fix it.
For your second point, this is mostly the case for Swift as well. 123 defaults to Int so if you wanted a floating point you'd have to write let x: Double = 123 or let x = 123.0. Most people will default to the latter because it is less typing.
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.
it seems like the clean syntax makes the type checker's life harder and so performance is unacceptable. would you rather have clean syntax or acceptable compile times?
I want both! I strongly believe the computer should relieve the user of all the obvious, tedious, boring tasks. That includes figuring out types, if they can be figured out by inspecting the code. Obviously this isn't an easy problem to solve efficiently, but I think it's worth optimizing this heavily, instead of just giving up and forcing the developer to write "dumb" annotations.
Edit: I'm no expert in this topic, but Prolog interpreters (compilers?) have some fascinating machinery to solve complex constraints. Maybe a similar approach could help here?
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.
So then, another language which has lots of features, but if you are foolish enough to combine feature A, feature B and feature C, bad things will happen? C++ sends its regards...
Well apple themselves are pushing swiftUI and I suspect it will be the main (and only) approach as time goes on, even though its just a wrapper around "older" approach...
Not pulling the "citation needed" thing at all, genuinely curious (from anyone who might know), is that 1/3 number accurate? Is there data published on it anywhere? That feels like monumental news :-D
There are plenty of contradicting data, like the job market for Flutter being close to nil, if it was any relevant 30% of the App Store you would throw a rock and hit five Flutter developers.
Swift is an early example of Apple losing its way. Such a stark contrast to Objective-c -- which was a simple, fast compiling language that hit way above its weight for expressivity and runtime speed. A great language for its day. Swift is "a C++ hacker's first attempt at language design".
I would be fine with a Objective-C 3.0, but the big question would be how to fix the underlying C flaws, which was one of Swift's original goals.
I do agree that the language design has gone overboard in the last couple of years, expecially in the various approaches to parallelism.
However they are not alone, just look at any programming language sponsored by companies, you need features to justify team sizes and naturally old features don't go away.
Taste & trade-offs aside, you've gotta make it compile reasonably fast! I do get that Objective-C is not the pinacle of language development, but you shouldn't give your main language the rough edges of a research project.
(And while the past shouldn't necessarily be a shackle on the future, it is striking that such a radically different set of trade-offs was picked for Swift vs Obj-C.)
I think both Go and C# are pretty nice languages, to give you an idea of where I'm coming from. And Rust is very interesting -- as a user you see software that gets written in it exceed the previous state-of-the-art (e.g., ripgrep).
I don't see that w/ Swift. It seems like the opposite. E.g., the terrible Settings rewrite that rolled out a couple releases ago...
Confession, though, while I did a lot of ojbc back in the day, I've never done more than kick the tires on Swift, so I'm not critiquing from a position of deep knowledge -- more like talking shit from the sidelines. But I do think I'm right. ;-)
C# is starting to get a C++ like feeling, I no longer can keep track of all features that get added every year, especially when not able to work in vLatest in consulting gigs.
Just compare C# 14 with C# 1, laundry list of features, and BCL changes.
Go, has plenty of warts caused by ignoring the history of programming languages.
Rust async/await story isn't that great, as it is kind of half done.
We could also add others to the list, each year get a few more constructs, runtime changes, standard library changes, whatever is the package manager of the year, and so on.
All have issues, then again we can go back to the famous Bjarne Stroustoup quote
"There are only two kinds of languages: the ones people complain about and the ones nobody uses".
Light-weight wrapper over C, so as fast as C when you want it to be. Message passing isn't as fast as, say, vtables, but is still quite snappy and flexible for loosely binding objects together. No generics avoids code bloat.
In practice obj-c apps were snappy, e.g., good perf on extremely limited hardware of original iPhone. SwiftUI (I assume) of MacOS settings app much slower than the old version it replaced -- too much heavy programmer framework magic resulting in slower final code? That's my diagnosis/guess from afar (I might be wrong ofc), a pitfall that objc did not tend to lead developers into.
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 would rather just have a flag to require type annotations to simply not have to worry about this. I find code much harder to read without them anyway.
It is pretty rough but as someone who has been programming in Swift since 1.0 I can say it rarely happens in practice. In the early days it happened all the time where the compiler would trip up on random expressions. I can still get it to happen, especially on complex closure type things, but even if those did compile they're confusing enough where they really shouldn't make it past code review anyway. That url example should never either.
I am very curious as to what you're running into where you're seeing wildly slow type checking times.
Same here. I rarely run into this problem. I write mostly SwiftUI too. I will admit there are some built in SwiftUI views that are problematic: tables, outline groups.
The issue with Swift IS the type theory. Constraint solvers are by definition going to be harder to reason about and have longer execution time than just declaring the type.
Kotlin, which has very similar syntax and language goals as swift, though a different runtime of course, does it also suffer from long compilation times for some expressions due to type checking?
Not much experience with multiplatform Kotlin. But Kotlin in the JVM compiles fairly large project +200k lines without cache in few minutes < 3, incremental compilations in the millisecond range maybe a few seconds if large chances were made
Kotlin has lot of similar type inference as Swift (and is in fact 80% syntax identical, though this is just a point of trivia), so I wonder why Kotlin doesn't get this "type-checker cannot compile this expression" error like Swift does, for longer expressions?
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...
Every time I tinker with languages like Rust or Crystal or Swift, I am amazed by their compilation times. OCaml and Pascal got this right aeons ago. I’m looking forward to a public release of Jai simply because compilation speed is one of its primary motivations. Having a fast feedback loop is crucial to my adhd-like development workflow.
> I am amazed by their compilation times. OCaml and Pascal got this right aeons ago
Pascal doesn’t do type inference at all.
I think OCaml meets both of the non-goals mentioned in the article:
“There are also two non-goals worth mentioning:
Removing overloading from the language. Without disjunction constraints, a constraint system can almost always be solved very quickly. However, this would be such a major change to the language, and break so many existing APIs, that it is not feasible to attempt at this point, even as a new language mode.
Removing bidirectional inference. We can also imagine a language design where expressions are type-checked in a strictly bottom-up fashion, starting from the leaves, like in many other C-family languages. This is another drastic simplification that essentially trivializes the whole problem. However, this would require giving up on language features such as polymorphic literals, leading-dot member syntax, closures with inferred types, and parts of generics. All of these are features that make Swift into the expressive language it is today.”
So, both are fast because they do less. Given that Apple hasn’t managed to make the Swift compiler even somewhat swift (pun intended) I think that partly is the right choice.
> So, both are fast because they do less.
Great. Give me that with a modern toolchain and a good stdlib, and I’ll be one happy dev. Swift focused on solving the wrong problem. I don’t need overloading or bidirectional inference. I need fast compilation, good tooling, and a solid stdlib.
isn't rust's compilation speed slow primarily due to its reference / lifetime checker, rather than the "actual compilation" of the program?
Not even close. Borrow checking takes less time than type checking.
On a somewhat related note, Swift has a particularly nifty type erasure system that allows it to avoid monomorphizing everything, and I think some Rust people would appreciate if such a system magically appeared for Rust. As I understand it, implementing it would be a lot of work.
I have no experience with Swift.
> The invalid expression from above, where + was applied to String and Int, is still rejected, however with the new algorithm, it only takes the compiler 2 seconds to reach the limit.
I think failing is okay, as the expression can then be explicitly typed. But if it would be solved slowly by the type checker, does Xcode show a slow compile warning for the line that this code should be optimized?
> However, an integer literal such as 123 actually has two default types, Int and Double, and the resulting disjunction has three choices. It might be worth considering a language change where floating point literals must be spelled with a decimal point. Today, expressions involving mixed integer and double literals can be particularly tricky to type check, for this reason.
The habit to write 123.0 for floats is second nature. I think this is a good idea, don’t know if other programmers would find that annoying? (aside the annoyance of changing existing code bases).
For your first question, yes, it can be optionally turned on and set to a specific value. In the early days of Swift it was quite useful. I still have it on in one project but it rarely shows up anymore and when it does it is usually a mystery as to why it shows up and there's no clear way to fix it.
For your second point, this is mostly the case for Swift as well. 123 defaults to Int so if you wanted a floating point you'd have to write let x: Double = 123 or let x = 123.0. Most people will default to the latter because it is less typing.
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.
Maybe you could use a "hide type declarations" view as part of a structurally aware (tree-sitter or LSP-based) code editor?
it seems like the clean syntax makes the type checker's life harder and so performance is unacceptable. would you rather have clean syntax or acceptable compile times?
I want both! I strongly believe the computer should relieve the user of all the obvious, tedious, boring tasks. That includes figuring out types, if they can be figured out by inspecting the code. Obviously this isn't an easy problem to solve efficiently, but I think it's worth optimizing this heavily, instead of just giving up and forcing the developer to write "dumb" annotations.
Edit: I'm no expert in this topic, but Prolog interpreters (compilers?) have some fascinating machinery to solve complex constraints. Maybe a similar approach could help here?
Trait instantiation in most languages is already using a Prolog-like approach.
The IDE experience on Linux doesn't make it any better either.
Oh how I wish I could have a working Swift :(.
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.
> I think, though, that modern PLs need better solutions for adhoc overloading.
So, something like "How to make ad-hoc polymorphism less ad hoc"?
Orphanless typeclasses FTW
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.
So then, another language which has lots of features, but if you are foolish enough to combine feature A, feature B and feature C, bad things will happen? C++ sends its regards...
That sucks because I really like the semantics of SwiftUI over UIKit. Declarative, reactive code just makes sense for UI.
Well apple themselves are pushing swiftUI and I suspect it will be the main (and only) approach as time goes on, even though its just a wrapper around "older" approach...
That is exactly what happened and the competence of the engineers working on the language is not really relevant.
There is a reason why 1/3 apps in the Apple App Store are now written in Flutter instead.
Because its easier to write one piece to code to target two platforms, regardless of how good or bad the native language for each platform is?
It’s also just nicer to work with in addition to having all of the multi platform stuff taken care of you for free.
Is Flutter more popular than React Native now?
I think that’s been true for quite some time now
Not pulling the "citation needed" thing at all, genuinely curious (from anyone who might know), is that 1/3 number accurate? Is there data published on it anywhere? That feels like monumental news :-D
https://flutter.dev/multi-platform/ios
It’s actually 28% I just checked but it’s front and centre there if you scroll down.
28% of ”free new apps”, whatever that means, measured by someone who’s not Apple (so lacking the actual numbers).
Don’t get mad about it but a lot of people want to work with Flutter because they think is better for any number of reasons. The data is what it is.
There are plenty of contradicting data, like the job market for Flutter being close to nil, if it was any relevant 30% of the App Store you would throw a rock and hit five Flutter developers.
And nobody’s mad.
many thanks!
Swift is an early example of Apple losing its way. Such a stark contrast to Objective-c -- which was a simple, fast compiling language that hit way above its weight for expressivity and runtime speed. A great language for its day. Swift is "a C++ hacker's first attempt at language design".
I would be fine with a Objective-C 3.0, but the big question would be how to fix the underlying C flaws, which was one of Swift's original goals.
I do agree that the language design has gone overboard in the last couple of years, expecially in the various approaches to parallelism.
However they are not alone, just look at any programming language sponsored by companies, you need features to justify team sizes and naturally old features don't go away.
Taste & trade-offs aside, you've gotta make it compile reasonably fast! I do get that Objective-C is not the pinacle of language development, but you shouldn't give your main language the rough edges of a research project.
(And while the past shouldn't necessarily be a shackle on the future, it is striking that such a radically different set of trade-offs was picked for Swift vs Obj-C.)
I think both Go and C# are pretty nice languages, to give you an idea of where I'm coming from. And Rust is very interesting -- as a user you see software that gets written in it exceed the previous state-of-the-art (e.g., ripgrep).
I don't see that w/ Swift. It seems like the opposite. E.g., the terrible Settings rewrite that rolled out a couple releases ago...
Confession, though, while I did a lot of ojbc back in the day, I've never done more than kick the tires on Swift, so I'm not critiquing from a position of deep knowledge -- more like talking shit from the sidelines. But I do think I'm right. ;-)
C# is starting to get a C++ like feeling, I no longer can keep track of all features that get added every year, especially when not able to work in vLatest in consulting gigs.
Just compare C# 14 with C# 1, laundry list of features, and BCL changes.
Go, has plenty of warts caused by ignoring the history of programming languages.
Rust async/await story isn't that great, as it is kind of half done.
We could also add others to the list, each year get a few more constructs, runtime changes, standard library changes, whatever is the package manager of the year, and so on.
All have issues, then again we can go back to the famous Bjarne Stroustoup quote
"There are only two kinds of languages: the ones people complain about and the ones nobody uses".
I wasn’t aware objc was considered “fast”.
Light-weight wrapper over C, so as fast as C when you want it to be. Message passing isn't as fast as, say, vtables, but is still quite snappy and flexible for loosely binding objects together. No generics avoids code bloat.
In practice obj-c apps were snappy, e.g., good perf on extremely limited hardware of original iPhone. SwiftUI (I assume) of MacOS settings app much slower than the old version it replaced -- too much heavy programmer framework magic resulting in slower final code? That's my diagnosis/guess from afar (I might be wrong ofc), a pitfall that objc did not tend to lead developers into.
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.
I would rather just have a flag to require type annotations to simply not have to worry about this. I find code much harder to read without them anyway.
> 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
It is pretty rough but as someone who has been programming in Swift since 1.0 I can say it rarely happens in practice. In the early days it happened all the time where the compiler would trip up on random expressions. I can still get it to happen, especially on complex closure type things, but even if those did compile they're confusing enough where they really shouldn't make it past code review anyway. That url example should never either.
I am very curious as to what you're running into where you're seeing wildly slow type checking times.
This was the most recent example: https://pastes.io/slow-type-checkingswift
It could have been the library I was using (YoutubeTranscript) but I wasn't getting any type hints on the result from URLComponents either.
I just updated my app from Swift 5 to 6 and it seems a better.
Same here. I rarely run into this problem. I write mostly SwiftUI too. I will admit there are some built in SwiftUI views that are problematic: tables, outline groups.
Most of the time it’s a syntax error or typo.
That Chris Lattner is taking a very different approach to the type checker in Mojo is afaik due to this kind of thing.
Did he get an actual type theorist for that part of the project?
The issue with Swift IS the type theory. Constraint solvers are by definition going to be harder to reason about and have longer execution time than just declaring the type.
Kotlin, which has very similar syntax and language goals as swift, though a different runtime of course, does it also suffer from long compilation times for some expressions due to type checking?
Not much experience with multiplatform Kotlin. But Kotlin in the JVM compiles fairly large project +200k lines without cache in few minutes < 3, incremental compilations in the millisecond range maybe a few seconds if large chances were made
Kotlin has lot of similar type inference as Swift (and is in fact 80% syntax identical, though this is just a point of trivia), so I wonder why Kotlin doesn't get this "type-checker cannot compile this expression" error like Swift does, for longer expressions?
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.
Hyperbole