The times here seem unreasonably bad even with the bad algorithm. Something else has got to be going on. Maybe kind of hidden factorial complexity when it tries every combination?
The Swift compiler is slow due to how types are inferred
11–20 of 229 posts
Re: The Swift compiler is slow due to how types are inferred
#12Does anyone know why, anecdotally, it seems like the slowness of type inference is more of a pain point in Swift than in Ocaml, Rescript, Purescript, Haskell, etc?
[deleted]
Re: The Swift compiler is slow due to how types are inferred
#13I'm a big fan of the idea of Swift as a cross platform language general purpose langauge, but it just feels bad without Xcode. The Vscode extension is just okay, and all of the tutorials/documentation assumes you are using Xcode.
A lot of the issues that Swift is currently facing are the same issues that C# has, but C# had the benefit of Mono and Xamarin, and in general more time. Plus you have things like JetBrains Rider to fill in for Visual Studio. Maybe in a few years Swift will get there, but I'm just wary because Apple really doesn't have any incentive to support it.
Funnily enough, the biggest proponent of cross platform Swift has been Miguel De Icaza, Gnome creator, and cofounder of Mono the cross platform C# implementation pre .net core. His Swift Godot project even got a shout out recently by Apple
Re: The Swift compiler is slow due to how types are inferred
#14Does anyone know why, anecdotally, it seems like the slowness of type inference is more of a pain point in Swift than in Ocaml, Rescript, Purescript, Haskell, etc?
Is it that Haskell, at least, doesn't support overloading in the same way as Swift? I don't know either of them well enough to be sure.
It seems like there's a combinatorial explosion of possible overloads in Swift, whereas if you implement a function with the same ergonomics in Haskell (e.g. a printf-like function), the only thing the compiler has to do is ask "Does type X have an implementation for typeclass Show? Yes? Done."
Essentially Haskell solved this overload inference problem in the same way that iterators solve the M*N problem for basic algorithms: convert all these disparate types to a single type, and run your algorithm on that.
Re: The Swift compiler is slow due to how types are inferred
#15One of the interesting tradeoffs in programming languages is compile speed vs everything else.
If you've ever worked on a project with a 40 minute build (me) you can appreciate a language like go that puts compilation speed ahead of everything else. Lately I've been blown away by the "uv" package manager for Python which not only seems to be the first correct one but is also so fast I can be left wondering if it really did anything.
On the other hand, there's a less popular argument that the focus on speed is a reason why we can't have nice things and, for people working on smaller systems, languages should be focused on other affordances so we have things like
One area I've thought about a lot is the design of parsers: for instance there is a drumbeat you hear about Lisp being "homoiconic" but if you had composable parsers and your language exposed its own parser, and if every parser also worked as an unparser, you could do magical metaprogramming with ease similar to LISP. Python almost went there with PEG but stopped short of it being a real revolution because of... speed.
As for the kind of problem he's worried about (algorithms that don't scale) one answer is compilation units and careful caching.
Re: The Swift compiler is slow due to how types are inferred
#16One could argue that anything that anything that makes the development process itself more efficient, as opposed to the compiling, is worth it since programmers themselves ain’t getting any faster anytime soon, but timing out after more than 40 seconds on a state-of-the-art CPU because of a handful of lines is just ridiculous.
At the very least it seems like the compiler could math out how many possible states it is about to check and if the value is unreasonable instantly error out instead of trying to chew on it for over half a minute before giving up.
Re: The Swift compiler is slow due to how types are inferred
#17I'm a big fan of the idea of Swift as a cross platform language general purpose langauge, but it just feels bad without Xcode. The Vscode extension is just okay, and all of the tutorials/documentation assumes you are using Xcode. A lot of the issues that Swift is currently facing are the same issues that C# has, but C# had the benefit of Mono and Xamarin, and in general more time. Plus you have things like JetBrains…
The only thing holding it back is Apple not investing into making it happen. Swift is in a weird spot where it has so much potential, but without investment in the tooling for other platforms (which is uncommon for Apple in general) it just wont happen, at least not as quickly as it could.
Re: The Swift compiler is slow due to how types are inferred
#18They never will, since it's also one of Swift's greatest strengths. What they may, eventually, do is dedicate the resources to minimize the negative aspects of the system while documenting clear ways to mitigate the biggest issues. Unfortunately Apple's dev tools org is chronically under resourced, which means improvements to the inference system and its diagnostics come and go as engineers are allowed to work on it.…
I think this is a unfair characterization. Yes Apple's developer ecosystem has a lot of fair complaints, I've personally run into the issues in this article particularly with newer APIs like SwiftData's #Predicate macro. But we just saw two days ago a lot of concerted issues to fix systemic problems like XCode the editor, or with compile times with Explicit Module improvements. I think you're painting with too heavy…
No, this is just the typical Apple cycle I alluded too. Improvements are saved up for WWDC, previewed, then regress over the next year as other work is done, only for the process to repeat. They've demonstrated small improvements practically every year, yet the compiler continues to regress in build performance. Notably, the explicit module build system you mentioned regresses my small project's build time by 50% on an M1 Ultra. And even without it, overall build performance regressed 10 - 12% on the same project.
Re: The Swift compiler is slow due to how types are inferred
#19Does anyone know why, anecdotally, it seems like the slowness of type inference is more of a pain point in Swift than in Ocaml, Rescript, Purescript, Haskell, etc?
I'm not an expert on the theory, but OCaml has a very fast compiler and while it is (almost) capable of fully reconstructing the types from a program with no annotations, it doesn't have to deal with ad-hoc polymorphism and takes some shortcuts like weak polymorphism when it gets too hard: https://www.ocaml.org/manual/5.2/polymorphism.html
Re: The Swift compiler is slow due to how types are inferred
#20I'm a big fan of the idea of Swift as a cross platform language general purpose langauge, but it just feels bad without Xcode. The Vscode extension is just okay, and all of the tutorials/documentation assumes you are using Xcode. A lot of the issues that Swift is currently facing are the same issues that C# has, but C# had the benefit of Mono and Xamarin, and in general more time. Plus you have things like JetBrains…
I use a swift toolchain with JetBrains' CLion (for CLIs) and it's pretty good and quite refreshing when compared to Xcode.