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

161–170 of 229 posts

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

#161

Post by erik_seaberg »

devbent wrote: post #160
PaulHoule wrote: post #15

One of the interesting tradeoffs in programming languages is compile speed vs everything else. If you've ever worked on a project with a 40 minute build (me) you can appreciate a language like go that puts compilation speed ahead of everything else. Lately I've been blown away by the "uv" package manager for Python which not only seems to be the first correct one but is also so fast I can be left wondering if it real…

> If you've ever worked on a project with a 40 minute build I've worked on plenty of C++ code based that had a 2 day build time! If you were lucky, incremental builds only took a few hours.

I remember hearing that Microsoft was excited to get full NT builds below 24 hours.

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

#162

Post by thegeekpirate »

samatman wrote: post #99
josephg wrote: post #84

Earlier quoted context omitted.

I think this is a false choice. It comes from the way we design compilers today. When you recompile your program, usually a tiny portion of the lines of code have actually changed. So almost all the work the compiler does is identical to the previous time it compiled. But, we write compilers and linkers as batch programs that redo all the compilation work from scratch every time. This is quite silly. Surely it’s poss…

Agreed. For example, Julia (which is a compiled language) has a package called Revise, which provides incremental compilation. A cold start on a package / project / script will take awhile, and even when dependencies are precompiled, but the code you're working on is not, REPL startup takes noticeable amounts of time. But once you have your REPL prompt, it's just: edit code, test it. Revise figures out what needs rec…

s/increase/decrease

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

#163

Post by onthelow »

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…

Great posts. Objective-C is still my programming language of choice.

> Now, I'm sure someone will argue that the real goal is for the entire stack to eventually be in Swift, at which point this won't be an issue anymore, but now we're talking about a 20-year plan, where it seems weird to prioritize my Calculator app's code as the critical first step.

It seems like it is the goal for at least some people at Apple. But so many Swift frameworks rely on Objective-C frameworks (SwiftUI wraps lots of UIKit. SwiftData is built on top of CoreData, etc.)

In twenty years Swift will be roughly the same age Objective-C was when Swift was introduced (give or take). By then the Swifties will be getting old and gray. I think it’s reasonable to bet that some young blokes will be pushing a new programming language/UI framework by then. I’m not sure Apple can replace the entire Objective-C stack even if they wanted to. Maybe if they spent the next five years not working on any new features and did nothing but port all the frameworks to pure Swift (we know Apple will never do that).

Unless a new hardware platform takes off and supersedes iOS/macOS and starts Swift only I just don’t think Apple can rid themselves of Objective-C (I personally think that they shouldn’t even want to get rid of Objective-C). But watchOS doesn’t have many developers and visionOS wants all existing iOS and macOS apps to work because they want a large ecosystem.

I sometimes wonder if Objective-C will outlive Swift. Sure it’s the underdog but I always root for the underdog. I hope someone will make an Objective-C 3.0 even if it isn’t Apple.

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

#164

Post by lamontcg »

adamwk wrote: post #141
lamontcg wrote: post #121

Earlier quoted context omitted.

Rust still lets you create your own algorithmic data types so that you can overload traits like Add, Mul, Div and Sub to implement your own e.g. Vector3 class (although I still feel this is too restrictive, but understand why rust chooses not to do that). What Rust blocks in your example there is implicit type conversion/coercion/promotion, and I'm actually okay with that and forcing being much more explicit about ty…

the rust traits are not overloading though (at least not in the same way as swift), that’s just implementing a trait on a type. I think the distinction is that with traits or protocols you get a lot of expressivity, reducing the need for overloading

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

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

#165

Post by ivm »

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# has been decent on Mac since the early 2010s (MonoDevelop, Unity3d), and mobile .NET has been pretty robust on iOS and Android for about a decade, with plenty of NuGet libraries available.

Meanwhile, Swift has a long way to go to reach at least the state of Kotlin Multiplatform, which is still mostly in beta and lacks libraries that can work outside of Android.

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

#166

Post by fauigerzigerk »

lamontcg wrote: post #164
adamwk wrote: post #141

Earlier quoted context omitted.

the rust traits are not overloading though (at least not in the same way as swift), that’s just implementing a trait on a type. I think the distinction is that with traits or protocols you get a lot of expressivity, reducing the need for overloading

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 concrete type vec3 you cannot define both * and * , which makes type inference a lot easier. It also makes Rust operator overloading less expressive.

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

#167

Post by atiedebee »

pacaro wrote: post #46
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…

The author mentioned zig. And zig would get this right you can just write `setThreatLevel(.midnight)` But where zig breaks down is on any more complicated inference. It's common to end up needing code like `@as(f32, 0)` because zig just can't work it out. In awkward cases you can have chains of several @ statements just to keep the compiler in the loop of what type to use in a statement I like zig, but it has its own…

I'm not very in the loop regarding zig at the moment, but coming from C I would think you could just use 0.0 or 0.0f? Is that not the case?

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

#168

Post by aixpert »

devbent wrote: post #160
PaulHoule wrote: post #15

One of the interesting tradeoffs in programming languages is compile speed vs everything else. If you've ever worked on a project with a 40 minute build (me) you can appreciate a language like go that puts compilation speed ahead of everything else. Lately I've been blown away by the "uv" package manager for Python which not only seems to be the first correct one but is also so fast I can be left wondering if it real…

> If you've ever worked on a project with a 40 minute build I've worked on plenty of C++ code based that had a 2 day build time! If you were lucky, incremental builds only took a few hours.

I wander what these projects do wrong. Can't they be split into different dynamically loaded libraries with just the headers exposed?

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

#169

Post by aixpert »

samatman wrote: post #99
josephg wrote: post #84

Earlier quoted context omitted.

I think this is a false choice. It comes from the way we design compilers today. When you recompile your program, usually a tiny portion of the lines of code have actually changed. So almost all the work the compiler does is identical to the previous time it compiled. But, we write compilers and linkers as batch programs that redo all the compilation work from scratch every time. This is quite silly. Surely it’s poss…

Agreed. For example, Julia (which is a compiled language) has a package called Revise, which provides incremental compilation. A cold start on a package / project / script will take awhile, and even when dependencies are precompiled, but the code you're working on is not, REPL startup takes noticeable amounts of time. But once you have your REPL prompt, it's just: edit code, test it. Revise figures out what needs rec…

Is it baked in as the main mode yet? Or as an option to juliac?

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

#170

Post by pjmlp »

PaulHoule wrote: post #15

One of the interesting tradeoffs in programming languages is compile speed vs everything else. If you've ever worked on a project with a 40 minute build (me) you can appreciate a language like go that puts compilation speed ahead of everything else. Lately I've been blown away by the "uv" package manager for Python which not only seems to be the first correct one but is also so fast I can be left wondering if it real…

Having used Turbo Pascal, Delphi, Modula-2, Active Oberon, Eiffel, D, OCaml, I really don't appreciate that Go puts compilation speed ahead of everything else.

Those languages show one can have both, expressive type systems, and fast compilation turnarounds, when the authors aren't into anti-PhD level languages kind of sentiment.

Post reply on HN