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

211–220 of 229 posts

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

#211

Post by jwells89 »

mike_hearn wrote: post #200
jwells89 wrote: post #42

Earlier quoted context omitted.

I can’t offer much in the way of reasoning or explanation, but having written plenty of both Swift and Kotlin (the latter of which being a lot like a more verbose/explicit Swift in terms of syntax), I have to say that in the day to day I prefer the Swift way. Not that it’s a terrible imposition to have to type out full enum names and such, but it feels notably more clunky and less pleasant to write. So maybe the deci…

Bear in mind that in both Java and Kotlin you can statically import enum entries: import foo.SomeEnum.MIDNIGHT setThreadLevel(MIDNIGHT) In practice, you write out ThreatLevel.MIDNIGHT , let the IDE import it for you, and then use an IDE hotkey to do the static import and eliminate the prefix.

This is true, with the caveat that your imports don’t share member names in common (e.g. you can’t static import two “medium” members, one from SpiceLevel and the other from PizzaSize). Swift doesn’t have this restriction, at least as far as enums are concerned.

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

#212

Post by throwaway894345 »

kaba0 wrote: post #190
DanielHB wrote: post #71

Earlier quoted context omitted.

A fast hot code swap of a module is a more important feature in my opinion, but it is somehow even harder to find these days than a fast compilation speed language. But ideally I want both.

Funnily enough java has both insanely fast compile times, and hot swapping, while being more expressive than Go.

Java's compile times are "insanely fast" because it's not actually compiling to native code, it's compiling to JVM byte code which is actually compiled at runtime. And it is one of the rare languages that manages to be more expressive than Go while also being quite a lot less ergonomic. (:

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

#213

Post by throwaway894345 »

pjmlp wrote: post #171
throwaway894345 wrote: post #62

Earlier quoted context omitted.

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.

I've never understood why people think "more features" is a flex. "Faster compile times" isn't even the primary benefit of fewer features, it's just gravy. More features, even with fast compile times, is a failure (which is probably why most of those "more expressive languages" are no longer with us unless one includes the JIT languages and--disingenuously--only measure the AOT compilation).

EDIT: wow, a downvote within literally 2 seconds of posting!

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

#214

Post by kaba0 »

throwaway894345 wrote: post #212
kaba0 wrote: post #190

Earlier quoted context omitted.

Funnily enough java has both insanely fast compile times, and hot swapping, while being more expressive than Go.

Java's compile times are "insanely fast" because it's not actually compiling to native code, it's compiling to JVM byte code which is actually compiled at runtime. And it is one of the rare languages that manages to be more expressive than Go while also being quite a lot less ergonomic. (:

Go is significantly more verbose and just recently can one implement a goddamn map without hardcoding it in the compiler. Besides all the beautiful if err unreadable “error handling” that makes it all too easy to silently ignore errors, and design mistakes like defer being function scoped, it’s hardly something I would call ergonomic.

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

#215

Post by sigsev_251 »

pjmlp wrote: post #209
sigsev_251 wrote: post #208

Earlier quoted context omitted.

Do you happen to have any source/book on why you can't use anything but a conservative gc on C-like languages? I would really like to know why that's the case.

Basically C semantics are to blame, due to the way C was designed, and the liberties it allows its users, it is like programming in Assembly from a tracing GC point of view. Meaning that without any kind of metadata, the GC has to assume that any kind of value on the stack or global memory segments is a possible pointer, but it cannot be sure about it, it might be just a numeric value that looks like a valid pointer…

Thank you!

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

#216

Post by throwaway894345 »

kaba0 wrote: post #214
throwaway894345 wrote: post #212

Earlier quoted context omitted.

Java's compile times are "insanely fast" because it's not actually compiling to native code, it's compiling to JVM byte code which is actually compiled at runtime. And it is one of the rare languages that manages to be more expressive than Go while also being quite a lot less ergonomic. (:

Go is significantly more verbose and just recently can one implement a goddamn map without hardcoding it in the compiler. Besides all the beautiful if err unreadable “error handling” that makes it all too easy to silently ignore errors, and design mistakes like defer being function scoped, it’s hardly something I would call ergonomic.

I'm not claiming it's ergonomic (I don't think it is especially ergonomic, as I indicated in my previous comment), I'm claiming it's more ergonomic than Java. That said, it's always struck me as silly that people associate ergonomics with character counts. I don't think code golf is especially ergonomic either.

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

#217

Post by pjmlp »

throwaway894345 wrote: post #213
pjmlp wrote: post #171

Earlier quoted context omitted.

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

I've never understood why people think "more features" is a flex. "Faster compile times" isn't even the primary benefit of fewer features, it's just gravy. More features, even with fast compile times, is a failure (which is probably why most of those "more expressive languages" are no longer with us unless one includes the JIT languages and--disingenuously--only measure the AOT compilation). EDIT: wow, a downvote wit…

Those languages are definitely with us,

https://dlang.org/

https://www.embarcadero.com/products/delphi

https://www.mikroe.com/mikropascal-arm

https://www.eiffel.com/

https://www.ptc.com/en/products/developer-tools/objectada

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

#218

Post by pjmlp »

josephg wrote: post #108
estebank wrote: post #96

Earlier quoted context omitted.

> But, we write compilers and linkers as batch programs that redo all the compilation work from scratch every time. I don't think that there are that many production level compilers that don't perform the kind of caching that you're advocating for. Part of them problem is what the language semantics are. https://www.pingcap.com/blog/rust-huge-compilation-units/ gives an example of this. > Surely it’s possible to make…

Yes, rust has an incremental compilation mode that is definitely faster than compiling the whole program from scratch. But linking is still done from scratch every time, and that gets pretty slow with big programs. I agree that it would be a lot of work to retrofit llvm like this. But personally I think that effort would be well worth it. Maybe the place to start is the linker.

Given that VC++ does incremental linking, it seems to be the usual care of having someone caring enough to sort it out.

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

#219

Post by pjmlp »

mike_hearn wrote: post #199
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…

That's called incremental compilation and is fully supported by languages like Java or Kotlin. The JVM also supports this, being able to recompile methods on the fly whilst the program runs. And the IDE plugins for these types of languages are actually "presentation compilers". They do all the work of compiling and type checking, except for code emission, and they run fast enough to run continuously in the background…

Not only, some C++ compilers like VC++, Eiffel, CLR, Common Lisp,...

As addendum.

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

#220

Post by throwaway894345 »

pjmlp wrote: post #217
throwaway894345 wrote: post #213

Earlier quoted context omitted.

I've never understood why people think "more features" is a flex. "Faster compile times" isn't even the primary benefit of fewer features, it's just gravy. More features, even with fast compile times, is a failure (which is probably why most of those "more expressive languages" are no longer with us unless one includes the JIT languages and--disingenuously--only measure the AOT compilation). EDIT: wow, a downvote wit…

Those languages are definitely with us, https://dlang.org/ https://www.embarcadero.com/products/delphi https://www.mikroe.com/mikropascal-arm https://www.eiffel.com/ https://www.ptc.com/en/products/developer-tools/objectada

Do those languages command even a single percentage of marketshare combined?
Post reply on HN