Isn’t the channel variable declared and inferred as an int32? Can’t see why the overload isn’t resolved directly?
The Swift compiler is slow due to how types are inferred
51–60 of 229 posts
Re: The Swift compiler is slow due to how types are inferred
#52Does 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?
My guess is different extensions to Hindley–Milner type system, which is EXPTIME-complete in the worst case.
HM isn't bidirectional in the special case, so probably the features they added vs the top level universal quantifier type that has pathological low time complexity.
Re: The Swift compiler is slow due to how types are inferred
#53Does 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?…
"Does type X have an implementation for typeclass Y" isn't always easy to answer.
Re: The Swift compiler is slow due to how types are inferred
#54It's really hard for me to read past Lattner's quote. "Beautiful minimal syntax" vs "really bad compile times" and "awful error messages". I know it's not helpful to judge in hindsight, lots of smart people, etc. But why on earth would you make this decision for a language aimed at app developers? How is this not a design failure? If I read this article correctly, it would have been an unacceptable decision to make u…
> aimed at app developers
I'm a native Swift app developer, for Apple platforms, so I assume that I'm the target audience.
Apps aren't major-league toolsets. My projects tend to be fairly big, for apps, but the compile time is pretty much irrelevant, to me. The linking and deployment times seem to be bigger than the compile times, especially in debug mode, which is where I spend most of my time.
When it comes time to ship, I just do an optimized archive, and get myself a cup of coffee. It doesn't happen that often, and is not unbearable.
If I was writing a full-fat server or toolset, with hundreds of files, and tens of thousands of lines of code, I might have a different outlook, but I really appreciate the language, so it's worth it, for me.
Of course, I'm one of those oldtimers that used to have to start the machine, by clocking in the bootloader, so there's that...
Re: The Swift compiler is slow due to how types are inferred
#55Earlier quoted context omitted.
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.
I wouldn't describe Swift itself as having so much potential: I loved it and advocated for it, for years. After getting more experience on other platforms and having time to watch how it evolved, or didn't as per TFA, it's...okay to mediocre compared to peers - Kotlin, Dart, Python come to mind. If Foundation was genuinely cross platform and open source, that description becomes more plausible for at least some subse…
Im surprised to see Python in that list. Swift being type safe and Python not puts Swift miles ahead.
Re: The Swift compiler is slow due to how types are inferred
#56The combinatorial explosion is intractable but since it only seems to come up in really obscure corner cases, I wonder if the typical inference scenarios can be solved by having the compiler cache the AST across invocations so that inference only needs to be performed on invalidated parts of the AST as it’s being typed instead of waiting for the user to invoke the compiler.
I think it would also be interesting for the compiler to modify the source code (with a flag, presumably, or possibly through the local LSP server) with the solved result as needed. This would also feedback to the programmer what the problem is, what the compiler thought the solution is (and under the circumstances, while it can't be "wrong" there's a decent chance it is suboptimal or not what the programmer expected), and not require future caching.
I kind of feel like that for more advanced languages this sort of back-and-forth between the type checker and the language has some potential to it.
Re: The Swift compiler is slow due to how types are inferred
#57Does 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
Try this:
let f0 = fun x -> (x, x) in
let f1 = fun y -> f0(f0 y) in
let f2 = fun y -> f1(f1 y) in
let f3 = fun y -> f2(f2 y) in
let f4 = fun y -> f3(f3 y) in
let f5 = fun y -> f4(f4 y) in
f5 (fun z -> z)
Re: The Swift compiler is slow due to how types are inferred
#58This is not a fixable flaw. Solving these constraints efficiently can definitely get you a Turing award, it's basically the SAT problem. And without this type system, swift is just Objective C in a prettier syntax, so Apple has to bite the bullet and bear with it.
I know that historically, we were taught that NP-complete problems are unsolvable for interesting problem sizes, but that was already a bit of lie in when I went to university. (TSP was presented as a warning example, but even back then, very efficient approximations existed.) These days, when you have a SAT-like problem, you're often done because you can throw a SAT solver at it, and it will give you an answer in a…
depends what you consider interesting and/or acceptable solution I suppose
Re: The Swift compiler is slow due to how types are inferred
#59One 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 real…
Most languages are forced to choose between tooling speed and runtime speed, but Python has historically dealt with this apparent dichotomy by opting for neither. (⌐▨_▨)
Python real strength is the speed it can be taught, read and written.
Re: The Swift compiler is slow due to how types are inferred
#60It's really hard for me to read past Lattner's quote. "Beautiful minimal syntax" vs "really bad compile times" and "awful error messages". I know it's not helpful to judge in hindsight, lots of smart people, etc. But why on earth would you make this decision for a language aimed at app developers? How is this not a design failure? If I read this article correctly, it would have been an unacceptable decision to make u…
Here's some light to make it appear less stupid: He doesn't claim its not a design failure. He doesn't say they sat down and said "You know what? Lets do beautiful minimal syntax but have awful error messages & really bad compile times" The light here is recursive. As you lay out, it is extremely s̶t̶u̶p̶i̶d̶ unlikely that choice was made, actively. Left with an unlikely scenario, we take a step back and question if…
The alternatives are even less charitable to the Swift creators.
Surely, early in the development someone noticed compile times were very slow for certain simple but realistic examples. (Alternatives: they didn't have users? They didn't provide a way to get their feedback? They didn't measure compile times?)
Then, surely they sat down considered whether they could improve compile times and at what cost, and determined that any improvement would come at the cost of requiring more explicit type annotations. (Alternatives: they couldn't do the analysis the author did? The author is wrong? They found other improvements, but never implemented them?)
Then, surely they made a decision that the philosophy of this project is to prioritize other aspects of the developer experience ahead of compile times, and memorialized that somewhere. (Alternatives: they made the opposite decision, but didn't act on it? They made that decision, but didn't record it and left it to each future developer to infer?)
The only path here that reflects well on the Swift team decision makers is the happy path. I mean, say what you like about the tenets of Swift, dude, at least it's an ethos.