I would be fine with slow, if the Swift compiler could actually compile all valid Swift programs. It’s pretty commonplace for me to have to break a large or complicated function into smaller bite-size pieces because the compiler can’t type check it all at once.

I had several years in the ObjC ecosystem, embraced Swift whole-heartedly immediately at 1.0, and was surprised by people nitpicking like this.

It's been humbling to come back to it over the intervening 7 years and realize they weren't nitpicks that would be resolved shortly, and people would understand if they just read the swift-evolution mailing list. They were fundamental flaws.

If they removed the few small features that are responsible for 80% of the slowness and called it optimized swift I bet many would embrace it fairly quickly, especially considering they are functionally cosmetic features.

When will “Swift: The Good Parts” be available for preorder?

Not really. These are pretty critical features for the language.

Not type inference, rather, whatever is so pathological about the fundamental algorithm for doing Swift type inference that it can become an infinite loop.

This is a Swift-only feature in major languages with type inference.

> Primary-file mode's advantages are that the driver can do incremental compilation by only running frontends for files that it thinks are out of date, as well as running multiple frontend jobs in parallel, making use of multiple cores. Its disadvantage is that each frontend job has to read all the source files in the module before focusing on its primary-files of interest, which means that a portion of the frontend job's work is being done quadratically in the number of jobs. Usually this portion is relatively small and fast, but because it's quadratic, it can easily go wrong. The addition of batch mode was specifically to eliminate this quadratic increase in early work.

One example that would improve the above: replace module imports with file specific imports, including within the module itself. You could also make a case for operator overloading and there are probably a bunch of candidates a swift compiler engineer could tell you that would be small but significant like that.

https://github.com/apple/swift/blob/main/docs/CompilerPerfor...

This used to irritate me, but now that I'm in the habit of breaking functions up I've come to prefer it. It makes for code that's easier for myself to read and follow further down the road, which I think is a reasonable proxy for readability by others.

Writing modular code is good but that's a ridiculous reason to need to do so.

Xcode also trips on simple type errors and sometimes fails to even provide a line number where the error lies. As someone who just wrote a Swift app after no prior exposure, it's oddly immature in some basic ways after nearly a decade from launch.

Yeah I won’t defend it too much, Xcode/SourceKit/etc are clearly written in a way that assumes devs are writing perfectly idiomatic, smell-free code which isn’t very aligned with reality. I’ve more or less got a feel for what makes it grumpy so I don’t trip it up too often any more but it’s annoying on the odd occasion I do.

Yeah this is a major pet peeve. Especially when the compiler crashes. Growing up writing in C, I didn’t even know that was a thing.

If you are writing functions that the current/latest Swift compiler can’t handle on modern hardware then I feel sorry for anyone who has to someday read your code.

just try using state machines modelled with enums and you'll fairly quickly reach those limits.

When discussing compiler speed, Go specifically prioritizes compilation speed over optimization of the resulting code.

Swift and Rust both suffer from slower compilation than Go, primarily because LLVM prioritizes optimization over speed.

There are of course other reasons like complexity of language, size of compilation units etc… but optimization tends to be the biggest hit in my experience.

Hence why Rust is adopting/investigating cranelift as a debug compiler to improve speed.

> There are of course other reasons like complexity of language, size of compilation units etc… but optimization tends to be the biggest hit in my experience.

I guess you don’t have much experience with Swift. LLVM code generation may be slower than alternatives, but that’s more or less by a constant factor.

Swift’s type inference, on the other hand, can lead to a combinatorial explosion.

For example, https://www.hackingwithswift.com/articles/11/how-to-make-swi... claims that

  let sum = [1, 2, 3].map {
    String($0)
  }.flatMap {
    Int($0)
  }.reduce(0, +)

takes over 11 seconds to compile, while

compare this code:

  let sum = [1, 2, 3].map { (num: Int) -> String in
    String(num)
  }.flatMap { (str: String) -> Int? in
    Int(str)
  }.reduce(0, +)

takes about 75ms, and

  let numbers = [1, 2, 3]
  let stringNumbers = numbers.map {
    String($0)
  }
  let intNumbers = stringNumbers.flatMap {
    Int($0)
  }
  let sum = intNumbers.reduce(0, +)

compiles in 71ms.

Of course, all of these use LLVM, and likely even generate highly similar intermediate code.

Also, you’ll see these slowdowns even in debug builds that don’t ask LLVM to optimize code much.

Pretty rude to start your comment with the assumption that I’m not experienced with Swift. The rest of your comment would be more useful without the unnecessary condescension.

But nothing you said contradicts what I said either. Yes it’s easy to get into slow paths with Swift, but it’s also easy not to. Granted it takes a lot of up front knowledge to do so.

But even if you just stick to the LLVM portion, llvms debug mode is slower than cranelift and other toolchains debug modes. Debug doesn’t mean “no optimizations” whatsoever, nor does it mean efficient paths through the toolchain either.