So you are saying this is specifically limited to SwiftUI? This fact does not make it any less absurd, especially with the last part that has been said.
My question stands: why does this happen and how come it is still so primitive that you do not even get to know the location of the issue?
Note that, while this is definitely crazy, it's rare in practice if you avoid gluing a bunch of magic literals together using operators, which I already avoided as a habit. I've never encountered the exploding-compile-time issue once while writing production Swift, which I have done almost every day for a decade.
WITH THE EXCEPTION OF SWIFTUI, which relies entirely on inferring highly nested generic types, and stands out as a uniquely problematic Swift framework for that and other reasons. I don't use SwiftUI.
I was a swift developer for ~5 years before taking a rust job recently. The gap in tooling quality between swift and almost any other contemporary language is immense.
Using Xcode taught me to keep my expectations low for my programming environment. The compiler would straight up crash with shocking regularity. The debugger was utterly useless a huge majority of the time (it would just lose track of symbols and couldn’t inspect anything when you hit a breakpoint, every expression you would type to lldb would fail with an inscrutable error.) I had to keep a script around to blow away all of Xcode’s DerivedData and restart it, and I probably used it a half dozen times a day. It was terrible.
With Rust I’m using RustRover, which IIUC uses rust-analyzer which is part of the vanilla toolchain (ie. vim/neovim or vscode will be just as good as they can use it too), and I’m continually shocked at how well it works. I’ll be typing an expression that has an ambiguous type, and the moment I finish it with something unambiguous, the editor responds by filling in all the types around it within a second. And this is with tons of map/filter/iter expressions where the type inference is insanely complex. There’s no restarting the IDE because it’s out to lunch. There’s no expression that rust-analyzer can’t figure out but the compiler can (unlike swift which seems to have one type checker for editing and a different type checker in swiftc and they disagree constantly.) It’s fast, it’s reliable, and most importantly it’s correct.
Trust me, if you think Swift’s tooling issues are unavoidable reality, you need to see how good other languages have it.
I'm not defending the whole toolchain - I agree Xcode is probably the worst thing in the landscape of mature languages. I just think the infamous exponential-compile-time issue, and the "Swift is too complex now" issue, are sometimes overstated. Again, excepting SwiftUI, which is a huge exception, so I'm not exactly writing a glowing review. I just love Swift itself, and most of Apple's APIs.
Correct. JetBrains is allergic to LSP in general, as it directly commoditizes their core business. For example, they are only now developing a stable Kotlin analysis API that could maybe be used in a future third-party language server, despite the advanced age of both Kotlin and LSP.
> how come it is still so primitive that you do not even get to know the location of the issue?
The link kind of explains why this was a difficult problem, but I think it's worth a moment to consider why this particular difficult problem just wasn't solved. Why was Apple OK with just shrugging, eh, it's hard ?
This is a Quality of Implementation issue. Quality is truly important but because Quality is hard to turn into a metric you'll see management don't like to make it a goal, after all they can't really measure if they succeeded and so when it is competing with other things which are goals it's just abandoned.
Yeah, what I wanted to know is how come that Apple has not solved this issue yet, or how their decision-making goes with regarding to adding X and Y instead of fixing this absurd issue.
I am saying that it's unhelpful to miss the context, and it would be a shame if one was to misread that the Swift compiler can't even provide error locations, which it obviously can in the vast majority of cases.
Swift's compile time performance is obviously well documented. It's not great, and performance is definitely one of the trade-offs. SwiftUI leans heavily on the compiler and is very much at the sharp end of this. Most "normal Swift" code is by and large just fine. Of course discussions tend to spiral outwards, but stripping context and adding largely uninformed, quick judgements rarely adds value to any discussion.
