Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Swift compiler is slow due to how types are inferred

danielchasehooper.com

Post reply on HN
Print view View original

31–40 of 229 posts

Re: The Swift compiler is slow due to how types are inferred

#31

Post by refulgentis »

giancarlostoro wrote: post #17
Decabytes wrote: post #13

I'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.

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 subset of engineers. * (for non-Apple devs, Foundation ~= Apple's stdlib, things like dateformatting)

I don't mean to be argumentative, I'm genuinely curious what it looks like through someone else's eyes and the only way to start that conversation is taking an opposing position.

I am familiar with an argument it's better than Rust, but I'd very curious to understand if "better than" is "easier to pick up" or "better at the things people use Rust for": i.e. I bet it is easier to read & write, but AFAIK it's missing a whole lot of what I'll call "necessary footguns for performance" that Rust offers.

* IIRC there is a open source Foundation intended for Linux? but sort of just thrown at the community to build.

Re: The Swift compiler is slow due to how types are inferred

#32

Post by pajuc »

It'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 users write setThreatLevel(ThreatLevel.midnight) in order to have great compile times and error messages.

Can someone shed some light on this to make it appear less stupid? Because I'm sure there must be something less stupid going on.

Re: The Swift compiler is slow due to how types are inferred

#34

Post by shagie »

fooker wrote: post #3

This 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.

> ... it's basically the SAT problem.

I am reminded of this classic CodeGolf.SE challenge of "P = NP" https://codegolf.stackexchange.com/a/24419

The problem was set as:

> Your task is to write a program for SAT that executes in polynomial time, but may not solve all cases.

To which Eric Lippert wrote:

> "Appears" is unnecessary. I can write a program that really does execute in polynomial time to solve SAT problems. This is quite straightforward in fact.

And has a spoiler that starts out as:

> You said polynomial runtime. You said nothing about polynomial compile time. This program forces the C# compiler to try all possible type combinations for x1, x2 and x3, and choose the unique one that exhibits no type errors. The compiler does all the work, so the runtime doesn't have to. ...

Unfortunately the blog post which it was linked to that went into greater detail at https://devblogs.microsoft.com/ericlippert/lambda-expression... is no longer available (even via wayback).

Re: The Swift compiler is slow due to how types are inferred

#35

Post by refulgentis »

pajuc wrote: post #32

It'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 we have any assumptions: and our assumption is they made the choice actively.

Re: The Swift compiler is slow due to how types are inferred

#36

Post by tombert »

steinuil wrote: post #19
temp123789246 wrote: post #7

Does 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

Wait what? In Haskell the types are usually directly inferrable from the arguments they're being used as, and when you put a type annotation it's usually not explicit types (Num a => a -> b -> c).

I almost never bother putting types in Haskell, unless I want to guarantee some constraint, in which case I typically use typeclasses. Maybe I'm just weird but I don't think so. One of the very few things I actually like about Haskell is how good the type inference is.

Re: The Swift compiler is slow due to how types are inferred

#37

Post by jb1991 »

refulgentis wrote: post #35
pajuc wrote: post #32

It'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 world is this even saying.

Re: The Swift compiler is slow due to how types are inferred

#39

Post by jb1991 »

Sniffnoy wrote: post #24

Wait, in Swift it's illegal to multiply an int by a double?? So you would have to explicitly cast index to a double? I definitely didn't expect that!

Implicit conversions in any language are often a source of hard to find bugs. So in general, I find most people agree with the swift design that does not allow such conversions implicitly.

Re: The Swift compiler is slow due to how types are inferred

#40

Post by throwaway894345 »

PaulHoule wrote: post #15

One 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. (⌐▨_▨)
Post reply on HN