4 ms·

But developer experience is a factor that should weigh heavily in evaluating the quality of a programming language. I also fear Swift is going a step too far.

But developer experience is a factor that should weigh heavily in evaluating the quality of a programming language. I also fear Swift is going a step too far. For example, IMO Swift's compilation speed isn’t good enough. If that’s a matter of lack of tooling, I won’t blame the language, but is it, or is its slowness unavoidable for a language that is so flexible? If the latter, I would rather have a bit less flexibility and more compilation speed. Similarly, there’s quality of error messages. Swift has gotten better there, but still has some weird ones. Are they unavoidable for the current language?

dagmx 3y ago
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.
- Someone 3y ago
  > 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-swift-compile-faster 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.
  - dagmx 3y ago
    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.
cvwright 3y ago
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.
- jwells89 3y ago
  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.
  - cachvico 3y ago
    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.
    - jwells89 3y ago
      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.
    - cvwright 3y ago
      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.
- newZWhoDis 3y ago
  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.

dagmx 3y ago

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.

Someone 3y ago
> 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-swift-compile-faster 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.
- dagmx 3y ago
  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.

cvwright 3y ago

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.

jwells89 3y ago
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.
- cachvico 3y ago
  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.
  - jwells89 3y ago
    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.
  - cvwright 3y ago
    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.
newZWhoDis 3y ago
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.