Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Swift compiler is slow due to how types are inferred

danielchasehooper.com

Post reply on HN
Print view View original

221–229 of 229 posts

Re: The Swift compiler is slow due to how types are inferred

#221

Post by einsteinx2 »

elpakal wrote: post #20
Decabytes wrote: post #13

I'm a big fan of the idea of Swift as a cross platform language general purpose langauge, but it just feels bad without Xcode. The Vscode extension is just okay, and all of the tutorials/documentation assumes you are using Xcode. A lot of the issues that Swift is currently facing are the same issues that C# has, but C# had the benefit of Mono and Xamarin, and in general more time. Plus you have things like JetBrains…

I use a swift toolchain with JetBrains' CLion (for CLIs) and it's pretty good and quite refreshing when compared to Xcode.

Does it properly syntax highlight and autocomplete in CLion?

Re: The Swift compiler is slow due to how types are inferred

#222

Post by imbnwa »

tolmasky wrote: post #155
samatman wrote: post #145

Earlier quoted context omitted.

This is a great comment, you clearly know what you're talking about and I learned a lot. I wanted to push back on this a bit: > The "Objective-C problems" they fixed were things that made Objective-C annoying to optimize, not annoying to write (except if you are a big hater of square brackets I suppose). From an outsider's perspective, this was the point of Swift: Objective C was and is hard to optimize. Optimal code…

Let me preface this by saying performance is complicated, and unfortunately far more... religious than you'd expect. A good example of this is the Objective-C community’s old insistence that good performance was incompatible with garbage collection, despite decades of proof otherwise. This post [1] about Swift getting walloped by node.js is fascinating in seeing how a community responds with results that challenge th…

As someone interested in Apple app dev, would you recommend still starting with ObjC? I notice the dev behind the Swiftcord app (open source Discord client in Swift) has noted at length how much you still need to call into UIKit to get things done as there were a lot of blind alleys in SwiftUI.

Re: The Swift compiler is slow due to how types are inferred

#223

Post by foobar99 »

withoutboats3 wrote: post #65

I'm suspicious about the truth of this claim. I don't think bidirectional typechecking is the problem in itself: the problem trying to do type inference when you have some extremely flexible operator overloading, subtyping, and literal syntax features. It's these "expressive" features which have made type inference in Swift far more computationally complex, not type inference itself. And certainly not bidirectional t…

Bidirectional type checking is what makes Swift type checking exponential. Operators and literals just really jack up the numbers in the exponential function because they quickly lead to deeply nested expression trees with many choices on each nesting. So that's why they're the most commonly cited examples. They look very innocent and simple but aren't in Swift.

But you can absolutely construct slow expressions just with functions that are overloaded on both sides (i.e. parameters and return type). Generics and Closures also drive up the complexity a lot, though.

Re: The Swift compiler is slow due to how types are inferred

#224

Post by rochak »

Decabytes wrote: post #13

I'm a big fan of the idea of Swift as a cross platform language general purpose langauge, but it just feels bad without Xcode. The Vscode extension is just okay, and all of the tutorials/documentation assumes you are using Xcode. A lot of the issues that Swift is currently facing are the same issues that C# has, but C# had the benefit of Mono and Xamarin, and in general more time. Plus you have things like JetBrains…

I can’t be bothered to use a language that doesn’t have a good LSP (need it for Neovim), so Swift is an easy pass.

Re: The Swift compiler is slow due to how types are inferred

#225

Post by cageface »

refulgentis wrote: post #31
giancarlostoro wrote: post #17

Earlier quoted context omitted.

The only thing holding it back is Apple not investing into making it happen. Swift is in a weird spot where it has so much potential, but without investment in the tooling for other platforms (which is uncommon for Apple in general) it just wont happen, at least not as quickly as it could.

I wouldn't describe Swift itself as having so much potential: I loved it and advocated for it, for years. After getting more experience on other platforms and having time to watch how it evolved, or didn't as per TFA, it's...okay to mediocre compared to peers - Kotlin, Dart, Python come to mind. If Foundation was genuinely cross platform and open source, that description becomes more plausible for at least some subse…

Dart doesn't get a lot of respect around here but after working with it every day for the last few months I've come to really appreciate how fast it compiles and reloads. It's a major productivity boost. Other comparably expressive mainstream languages are so much slower to iterate with.

Re: The Swift compiler is slow due to how types are inferred

#226

Post by chrisandchris »

rochak wrote: post #224
Decabytes wrote: post #13

I'm a big fan of the idea of Swift as a cross platform language general purpose langauge, but it just feels bad without Xcode. The Vscode extension is just okay, and all of the tutorials/documentation assumes you are using Xcode. A lot of the issues that Swift is currently facing are the same issues that C# has, but C# had the benefit of Mono and Xamarin, and in general more time. Plus you have things like JetBrains…

I can’t be bothered to use a language that doesn’t have a good LSP (need it for Neovim), so Swift is an easy pass.

LSP?

Re: The Swift compiler is slow due to how types are inferred

#227

Post by lukeh »

tolmasky wrote: post #72
pajuc wrote: post #32

It's really hard for me to read past Lattner's quote. "Beautiful minimal syntax" vs "really bad compile times" and "awful error messages". I know it's not helpful to judge in hindsight, lots of smart people, etc. But why on earth would you make this decision for a language aimed at app developers? How is this not a design failure? If I read this article correctly, it would have been an unacceptable decision to make u…

Honestly it follows the design of the rest of the language. An incomplete list: 1. They wrote it to replace C++ instead of Objective-C. This is obvious from hearing Lattner speak, he always compares it to C++. Which makes sense, he dealt with C++ every day, since he is a compiler writer. This language does not actually address the problems of Objective-C from a user-perspective. They designed it to address the proble…

Some insightful home truths there! I do enjoy programming in Swift more than ObjC but, ironically, it’s mostly on Linux.

Re: The Swift compiler is slow due to how types are inferred

#228

Post by debugnik »

chrisandchris wrote: post #226
rochak wrote: post #224

Earlier quoted context omitted.

I can’t be bothered to use a language that doesn’t have a good LSP (need it for Neovim), so Swift is an easy pass.

LSP?

Language Server Protocol, see https://microsoft.github.io/language-server-protocol/

It isn't a particularly good protocol specification, but at least it got adoption thanks to Microsoft offering a reference client implementation as a library for VS Code extensions, and other editors like Neovim adding support in some form.

Re: The Swift compiler is slow due to how types are inferred

#229

Post by msk-lywenn »

rochak wrote: post #224
Decabytes wrote: post #13

I'm a big fan of the idea of Swift as a cross platform language general purpose langauge, but it just feels bad without Xcode. The Vscode extension is just okay, and all of the tutorials/documentation assumes you are using Xcode. A lot of the issues that Swift is currently facing are the same issues that C# has, but C# had the benefit of Mono and Xamarin, and in general more time. Plus you have things like JetBrains…

I can’t be bothered to use a language that doesn’t have a good LSP (need it for Neovim), so Swift is an easy pass.

What's wrong with Swift's LSP?
Post reply on HN