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

171–180 of 229 posts

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

#171

Post by pjmlp »

throwaway894345 wrote: post #62
kettlecorn wrote: post #22

Earlier quoted context omitted.

> One of the interesting tradeoffs in programming languages is compile speed vs everything else. In the case of Rust it's more of a cultural choice. Early people involved in the language pragmatically put everything else (correctness, ability to ship, maintainability, etc.) before compilation speed. Eventually the people attracted to contribute to the language weren't the sort that prioritized compilation speed. Many…

I think most people haven't used many languages that prioritize compilation speed (at least for native languages) and maybe don't appreciate how much it can help to have fast feedback loops. At least that's the feeling I get when I watch the debates about whether Go should add a bunch more static analysis or not--people argue like compilation speed doesn't matter at all, while _actually using Go_ has convinced me tha…

While others have, more expressive languages than Go, that compiled blazingly fast in 1990's hardware, with more features than Go will ever get.

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

#172

Post by pjmlp »

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…

C# also has the issue that while the .NET team is making heroic efforts for .NET to be a good cross platform citizen, upper management would rather sell Visual Studio and Windows licenses, alongside "works best in Azure" frameworks.

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

#173

Post by pjmlp »

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…

To add to the GC discussion, something that many that weren't around during the GC project failure for Objective-C, is that ARC was pivot from a failed project, but in good Apple fashion that had to sell the history on their own way.

The GC for Objective-C failed, because of the underlying C semantics, it would never be better than a typical conservative GC, and there were routinely application crashes when mixing code compiled with GC and non-GC options.

Thus they picked up the next best strategy, which was to automate the Cocoa's retain/release message pairs, and sell that as being much better than GC, because performance and such, not because the GC approach failed.

Naturally, as proven by the complex interop layer in .NET with COM, given Objective-C evolution, it would also be much better for Swift to adopt the same approach, than creating a complex layer similar to CCW/RCW.

Now everyone that wasn't around for this, kind of believes and resells the whole "ARC because performance!" story.

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

#174

Post by amomchilov »

floxy wrote: post #153
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…

I found an online Swift Playground, and here is a smaller test case that produces the "unable to type-check this expression in reasonable time" message: print("a" + "b" + "c" + 11 + "d") ...if you reduce it even further to: print("a" + "b" + "c" + 11) ...the error message is: :3:23: error: binary operator '+' cannot be applied to operands of type 'String' and 'Int' print("a" + "b" + "c" + 11) ~~~~~~~~~~~~~~~ ^ ~~ :3:…

`print((a + b + c) as String + n + d + e)`

(I’m not sure of the precedence, that might need another pair of parens)

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

#175

Post by melodyogonna »

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…

I'd say the biggest problem was that they developed the language in isolation. Lattner is not making that mistake with Mojo

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

#176

Post by amomchilov »

Sniffnoy wrote: post #24

Wait, in Swift it's illegal to multiply an int by a double?? So you would have to explicitly cast index to a double? I definitely didn't expect that!

It strikes a balance, by allowing _literals_ to be implicitly converted as needed.

E.g. `someDouble * 1` is valid, without needing to write `1.0` or `1f`.

This is because `Double` conforms to the `ExpressibleByIntegerLiteral` protocol. There's other similar protocols for other literal types, which e.g. you could write:

    let s: Set = [1, 2, 3]
Where it would have defaulted to being an Array without the annotation.

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

#177

Post by amomchilov »

floxy wrote: post #153
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…

I found an online Swift Playground, and here is a smaller test case that produces the "unable to type-check this expression in reasonable time" message: print("a" + "b" + "c" + 11 + "d") ...if you reduce it even further to: print("a" + "b" + "c" + 11) ...the error message is: :3:23: error: binary operator '+' cannot be applied to operands of type 'String' and 'Int' print("a" + "b" + "c" + 11) ~~~~~~~~~~~~~~~ ^ ~~ :3:…

The slow-down here isn't just from picking the correct `+` overloads, but also the various types that `"a"` could be (e.g. `String`, `Substring`, `Character`, or something like a `SQLQuery` type, depending on what libraries you have imported)

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

#178

Post by yorwba »

fauigerzigerk wrote: post #166
lamontcg wrote: post #164

Earlier quoted context omitted.

You can still create your own vec3 though that implements " * " through the Trait... It seems at least superficially equivalent to operator overloading.

It is operator overloading. Traits are just the mechanism to do operator overloading in Rust. But I think what matters in this particular context is that Rust does not support function overloading and this restriction also applies to functions implementing operators. I think this may be why the parent comment claims that it is not really overloading. The meaning of "overloading" is a bit ambiguous here. So for a conc…

You can define multiple implementations for the Mul trait with different right-hand sides, no problem at all.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

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

#179

Post by giancarlostoro »

sunnybeetroot wrote: post #55
refulgentis wrote: post #31

Earlier quoted context omitted.

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…

Im surprised to see Python in that list. Swift being type safe and Python not puts Swift miles ahead.

Python is the new Perl. Heck its the lingua franca of ML / AI and has been for data science for a while. Dynamic types dont mean you cannot compete with a typed language. Python has type hints which gives the benefit people are usually after, catching bugs / issues ahead of time.

Theres a library for just about everything in Python. I dont know that I can say that about Swift.

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

#180

Post by fauigerzigerk »

yorwba wrote: post #178
fauigerzigerk wrote: post #166

Earlier quoted context omitted.

It is operator overloading. Traits are just the mechanism to do operator overloading in Rust. But I think what matters in this particular context is that Rust does not support function overloading and this restriction also applies to functions implementing operators. I think this may be why the parent comment claims that it is not really overloading. The meaning of "overloading" is a bit ambiguous here. So for a conc…

You can define multiple implementations for the Mul trait with different right-hand sides, no problem at all. https://play.rust-lang.org/?version=stable&mode=debug&editio...

Thanks, I didn't know that.

In light of this, would you say that there is any sense in which Rust doesn't support the full extent of what is usually called operater overloading?

Post reply on HN