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

121–130 of 229 posts

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

#121

Post by lamontcg »

Tuna-Fish wrote: post #97
lamontcg wrote: post #75

Earlier quoted context omitted.

I'd trade type inference for expressibility (function and operator overloading in particular). But this seems to currently be a heretical opinion.

Rust took the other road: error[E0277]: cannot add `i64` to `i32` 1i32 + 2i64; ^ no implementation for `i32 + i64` It bothered me at first, there are a lot of explicit annotations for conversions when dealing with mixed precision stuff. But I now feel that it was the exactly correct choice, and not just because it makes inference easier.

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 type casting.

Go is the language that makes your vector classes required to have syntax like v1.VecMult(v2) and v1.ScalarMult(s) because there's no operator overloading at all (even though there's a largely useless baked-in complex number class).

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

#122

Post by PaulHoule »

pjmlp wrote: post #91
forrestthewoods wrote: post #73

Earlier quoted context omitted.

Python’s real strength is that it has a vast ecosystem of uber powerful libraries written in C/C++.

Shared by any language with FFI capabilities.

In theory. In practice people are very happy with what happens when you

  import pandas
in Python, more so than competitors. I have been hoping though that with the planned Java transition to FFI, you can make Jython pass Python FFI through Java API to get numpy and all that working.

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

#123

Post by pajuc »

refulgentis wrote: post #35
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…

Here's some light to make it appear less stupid: He doesn't claim its not a design failure. He doesn't say they sat down and said "You know what? Lets do beautiful minimal syntax but have awful error messages & really bad compile times" The light here is recursive. As you lay out, it is extremely s̶t̶u̶p̶i̶d̶ unlikely that choice was made, actively. Left with an unlikely scenario, we take a step back and question if…

So they didn't focus actively on good error messages and fast compile times when designing a new language?

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

#124

Post by pjmlp »

PaulHoule wrote: post #122
pjmlp wrote: post #91

Earlier quoted context omitted.

Shared by any language with FFI capabilities.

In theory. In practice people are very happy with what happens when you import pandas in Python, more so than competitors. I have been hoping though that with the planned Java transition to FFI, you can make Jython pass Python FFI through Java API to get numpy and all that working.

More a side effect from teaching materials than anything else, though.

Java still has the issue of the time Valhala is taking.

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

#125

Post by mrkeen »

HM works great for me. Let's try it elsewhere instead of blaming the algorithm!

  {-# LANGUAGE OverloadedStrings #-}          -- Let strings turn into any type defining IsString
  {-# LANGUAGE GeneralizedNewtypeDeriving #-} -- simplify/automate defining IsString 

  import Data.String (IsString)

  main = do

    -- Each of these expressions might be a String or one of the 30 Foo types below
    let address  = "127.0.0.1"
    let username = "steve"
    let password = "1234"
    let channel  = "11"

    let url = "http://"  username 
                         ":"       password 
                         "@"       address 
                         "/api/"   channel 
                         "/picture" 

    print url

  newtype Foo01 = Foo01 String deriving (IsString, Show, Semigroup)
  newtype Foo02 = Foo02 String deriving (IsString, Show, Semigroup)
  -- ... eliding 27 other type definitions for the comment
  newtype Foo30 = Foo30 String deriving (IsString, Show, Semigroup)
Do we think I've captured the combinatorics well enough?

The url expression is 9 adjoining expressions, where each expression (and pair of expressions, and triplet of expressions ...) could be 1 of at least 31 types.

$ ghc --version

  The Glorious Glasgow Haskell Compilation System, version 9.0.2
$ time ghc -fforce-recomp foo.hs

  [1 of 1] Compiling Main             ( foo.hs, foo.o )
  Linking foo ...

  real    0m0.544s
  user    0m0.418s
  sys     0m0.118s
Feels more sluggish than usual, but bad combinatorics shouldn't just make it slightly slower.

I tried compiling the simplest possible program and that took `real 0m0.332s` so who knows what's going on with my setup...

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

#126

Post by plorkyeran »

tmpz22 wrote: post #9
jshier wrote: post #2

They never will, since it's also one of Swift's greatest strengths. What they may, eventually, do is dedicate the resources to minimize the negative aspects of the system while documenting clear ways to mitigate the biggest issues. Unfortunately Apple's dev tools org is chronically under resourced, which means improvements to the inference system and its diagnostics come and go as engineers are allowed to work on it.…

I think this is a unfair characterization. Yes Apple's developer ecosystem has a lot of fair complaints, I've personally run into the issues in this article particularly with newer APIs like SwiftData's #Predicate macro. But we just saw two days ago a lot of concerted issues to fix systemic problems like XCode the editor, or with compile times with Explicit Module improvements. I think you're painting with too heavy…

Explicit modules make build times worse, not better. Yes, this is the exact opposite of what Apple claims they do, and I am genuinely baffled by the disconnect. Usually Apple's marketing is at least directionally true even if they overstate things, but in this case the project appears to have entirely failed to deliver on what it was supposed to do but it's still being sold as if it succeeded.

On top of that, the big thing we didn't see announced this year was anything at all related to addressing the massive hit to compile times that using macros causes.

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

#127

Post by anoncareer0212 »

pajuc wrote: post #123
refulgentis wrote: post #35

Earlier quoted context omitted.

Here's some light to make it appear less stupid: He doesn't claim its not a design failure. He doesn't say they sat down and said "You know what? Lets do beautiful minimal syntax but have awful error messages & really bad compile times" The light here is recursive. As you lay out, it is extremely s̶t̶u̶p̶i̶d̶ unlikely that choice was made, actively. Left with an unlikely scenario, we take a step back and question if…

So they didn't focus actively on good error messages and fast compile times when designing a new language?

If we have to flatten it to "they chose and knew exactly what choice they were making", then there's no light to be shed. Sure. That's stupid.

Its just as stupid to insist on that being the case.

If that's not convincing to you on its merits, consider another aspect, you expressly were inviting conversation on why that wasn't the case

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

#128

Post by extrabajs »

tinganho wrote: post #51

Isn’t the channel variable declared and inferred as an int32? Can’t see why the overload isn’t resolved directly?

The problem isn’t that the type inference can’t figure out that it’s a number (it can). Subtyping makes inference difficult. There may be a function somewhere which takes arguments that could be made to accept a string and an int32 (or whatever other number type that literal could be).

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

#129

Post by pajuc »

jerbear4328 wrote: post #47
jb1991 wrote: post #37

Earlier quoted context omitted.

The world is this even saying.

The designers of the language didn't intend for it to end up this way, it just worked out like it did. GP is pointing out that their parent assumed it was intentionally choosing pretty syntax over speed, when it was more likely for them to start with the syntax without considering speed.

What's the difference between "choosing pretty syntax over speed" and "start with syntax without considering speed"?

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

#130

Post by ash_gti »

mrkeen wrote: post #125

HM works great for me. Let's try it elsewhere instead of blaming the algorithm! {-# LANGUAGE OverloadedStrings #-} -- Let strings turn into any type defining IsString {-# LANGUAGE GeneralizedNewtypeDeriving #-} -- simplify/automate defining IsString import Data.String (IsString) main = do -- Each of these expressions might be a String or one of the 30 Foo types below let address = "127.0.0.1" let username = "steve" l…

Your example is different than the example in the post.

Specifically, `channel = 11`, an integer.

If it was a string then it parses very quickly.

Post reply on HN