4 ms·

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 co

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.
- bsaul 3y ago
  just try using state machines modelled with enums and you'll fairly quickly reach those limits.
refulgentis 3y ago
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.
- novok 3y ago
  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.
  - math_dandy 3y ago
    When will “Swift: The Good Parts” be available for preorder?
  - saagarjha 3y ago
    Not really. These are pretty critical features for the language.
    - refulgentis 3y ago
      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.
    - novok 3y ago
      > 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/CompilerPerformance.md https://github.com/apple/swift/blob/main/docs/CompilerPerfor...

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.

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

refulgentis 3y ago

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.

novok 3y ago
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.
- math_dandy 3y ago
  When will “Swift: The Good Parts” be available for preorder?
- saagarjha 3y ago
  Not really. These are pretty critical features for the language.
  - refulgentis 3y ago
    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.
  - novok 3y ago
    > 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/CompilerPerformance.md https://github.com/apple/swift/blob/main/docs/CompilerPerfor...