4 ms·

They both compile slowly because they have similarly complicated type systems. What do you use in Rust that Swift doesn’t yet provide?

xedrac 3y ago
Catch data races at compile time?
- turdprincess 3y ago
  I don’t know much about Rust, but Swift can prevent data races at compile time by using the Actor type.
  - astrange 3y ago
    It could catch them before that using ownership, at the cost of lower performance. Though Swift concurrency is mostly about "concurrency" not "parallelism", which is the one that has data races.
    - saagarjha 3y ago
      Ownership hasn’t shipped yet.
      - astrange 3y ago
        It has an ABI-level ownership thing already. What's missing is ways to control it.
    - tialaramex 3y ago
      If your concurrency strictly can't involve parallelism then sure, no data races, but also then your performance is miserable on modern hardware. If your concurrency can invoke parallelism, then you need to explicitly protect against data races, or else you need to define what happens (Java does this, nobody else has) or else you shrug and say too bad now the program is nonsense, you lose (C, C++, Go, many modern languages do this, it is easier)
      - astrange 3y ago
        > If your concurrency strictly can't involve parallelism then sure, no data races, but also then your performance is miserable on modern hardware. Often worth it when that hardware is battery-powered though. Using those extra cores isn't free.
ozten 3y ago
There are a very large list of foundational capabilities so that it’s not practical to respond with a concise answer. One example is automatically closing resources on behalf of the caller thanks to lifetimes. Another example is the best compiler feedback of any mainstream language.
wudangmonk 3y ago
You can have a good type system and have fast compile times. In every single language with 'complicated type systems' it always comes down to type inference on polymorphic types which causes these issues, this has been known for over 40 years yet the same issue seems to be rediscovered again and again like it was something new. I sure hope the author learned the right lesson from the failure that is Swift and Mojo turns out to be better. I do not want a language with a complicated type system and long compile times. I want a 'good enough' type system and fast compile times.
- aw1621107 3y ago
  > it always comes down to type inference on polymorphic types which causes these issues Unless I'm thinking of something different, doesn't OCaml have type inference on polymorphic types and fast(ish?) compile times? I was under the impression that the breakdown of causes for Rust projects compiling slowly is very project-dependent as well. From what I can remember common culprits were monomorphization and/or LLVM, though I'm not sure if that has changed recently.
  - octachron 3y ago
    Fast (and principled) inference for not-too-complicated polymorphic types is an explicit design goal for OCaml and Haskell languages. And this design goal constraint quite a lot the type system. Typically, there are many type system features that break this property and where OCaml and Haskell requires type annotations (for instance polymorphic functions that takes polymorphic functions as arguments and use them in a polymorphic way). As a consequence, typechecking for OCaml programs tend to take from 10% to 60% of the whole compilation time for typical programs. However, for OCaml programs that make heavy use of GADTs typechecking can dominate the compilation time (probably due to the exhaustiveness check but I have yet to empirically check that). Infamously, Swift made the choice to introduce a typechecking algorithm with an exponential complexity in the size of expression (to support function overloading and literals) even for simple types.
    - aw1621107 3y ago

xedrac 3y ago

Catch data races at compile time?

turdprincess 3y ago
I don’t know much about Rust, but Swift can prevent data races at compile time by using the Actor type.
- astrange 3y ago
  It could catch them before that using ownership, at the cost of lower performance. Though Swift concurrency is mostly about "concurrency" not "parallelism", which is the one that has data races.
  - saagarjha 3y ago
    Ownership hasn’t shipped yet.
    - astrange 3y ago
      It has an ABI-level ownership thing already. What's missing is ways to control it.
  - tialaramex 3y ago
    If your concurrency strictly can't involve parallelism then sure, no data races, but also then your performance is miserable on modern hardware. If your concurrency can invoke parallelism, then you need to explicitly protect against data races, or else you need to define what happens (Java does this, nobody else has) or else you shrug and say too bad now the program is nonsense, you lose (C, C++, Go, many modern languages do this, it is easier)
    - astrange 3y ago
      > If your concurrency strictly can't involve parallelism then sure, no data races, but also then your performance is miserable on modern hardware. Often worth it when that hardware is battery-powered though. Using those extra cores isn't free.

ozten 3y ago

There are a very large list of foundational capabilities so that it’s not practical to respond with a concise answer. One example is automatically closing resources on behalf of the caller thanks to lifetimes. Another example is the best compiler feedback of any mainstream language.

wudangmonk 3y ago

You can have a good type system and have fast compile times. In every single language with 'complicated type systems' it always comes down to type inference on polymorphic types which causes these issues, this has been known for over 40 years yet the same issue seems to be rediscovered again and again like it was something new. I sure hope the author learned the right lesson from the failure that is Swift and Mojo turns out to be better. I do not want a language with a complicated type system and long compile times. I want a 'good enough' type system and fast compile times.

aw1621107 3y ago
> it always comes down to type inference on polymorphic types which causes these issues Unless I'm thinking of something different, doesn't OCaml have type inference on polymorphic types and fast(ish?) compile times? I was under the impression that the breakdown of causes for Rust projects compiling slowly is very project-dependent as well. From what I can remember common culprits were monomorphization and/or LLVM, though I'm not sure if that has changed recently.
- octachron 3y ago
  Fast (and principled) inference for not-too-complicated polymorphic types is an explicit design goal for OCaml and Haskell languages. And this design goal constraint quite a lot the type system. Typically, there are many type system features that break this property and where OCaml and Haskell requires type annotations (for instance polymorphic functions that takes polymorphic functions as arguments and use them in a polymorphic way). As a consequence, typechecking for OCaml programs tend to take from 10% to 60% of the whole compilation time for typical programs. However, for OCaml programs that make heavy use of GADTs typechecking can dominate the compilation time (probably due to the exhaustiveness check but I have yet to empirically check that). Infamously, Swift made the choice to introduce a typechecking algorithm with an exponential complexity in the size of expression (to support function overloading and literals) even for simple types.
  - aw1621107 3y ago