Hacker News Reader

Comment by cvwright | Hacker News Reader

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.

View on HN

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.

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

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.

Reply on news.ycombinator.com