2 ms·

For what it's worth, they ship a solid VS Code extension and LSP. Their swift-testing package is the new open source and cross-platform successor to XCTest. The

For what it's worth, they ship a solid VS Code extension and LSP. Their swift-testing package is the new open source and cross-platform successor to XCTest. The same can be said of swift-foundation as compared to Foundation. The path they've chosen is not to open source Xcode, but to move the things Swift needs on all platforms to the Swift language project and common implementations. Personally I think the main problem with the language, besides Apple's earned poor reputation in FOSS circles, is the compile times. In the source-stable era of the language I'm not sure how they can really be fixed to the degree I'd be happy with.

fastball 2y ago
Are there any LLVM langs that have fast compile times? I think that just kinda comes with the territory of having that IR step + all the optimizations that happen at compile time to help runtime performance.
- easeout 2y ago
  That's a good point. I had in mind that there's some regret about the combination of type inference with type-based overloads, due to the search expense it adds to what ought to be straightforward parsing of long expressions.
  - fastball 2y ago
    Yeah, I think there are definitely parts of the language design / language features that are going to contribute, but when you need to parse to IR and then compile that to machine code, it seems any features you add that are nice for the developer are going to doubly hurt compile times. You see the same with ARC in swift (or the borrow checker in Rust).
    - Rohansi 2y ago
      AFAIK those language features are all handled in the frontend before outputting LLVM IR. LLVM optimization, code generation, linking, etc. should all be the same regardless of the source language.
    - easeout 2y ago
      I don't know about that example—when ARC was added to Objective-C back in the day, I don't remember clang feeling any slower as a result.
    - saagarjha 2y ago
      Parsing IR and lowering it is not the reason why compiling Swift is slow.
      - fastball 2y ago
        What is the reason Swift compile times are slow?
        saagarjha 2y ago
        Mostly type checking and name lookup

fastball 2y ago

Are there any LLVM langs that have fast compile times? I think that just kinda comes with the territory of having that IR step + all the optimizations that happen at compile time to help runtime performance.

easeout 2y ago
That's a good point. I had in mind that there's some regret about the combination of type inference with type-based overloads, due to the search expense it adds to what ought to be straightforward parsing of long expressions.
- fastball 2y ago
  Yeah, I think there are definitely parts of the language design / language features that are going to contribute, but when you need to parse to IR and then compile that to machine code, it seems any features you add that are nice for the developer are going to doubly hurt compile times. You see the same with ARC in swift (or the borrow checker in Rust).
  - Rohansi 2y ago
    AFAIK those language features are all handled in the frontend before outputting LLVM IR. LLVM optimization, code generation, linking, etc. should all be the same regardless of the source language.
  - easeout 2y ago
    I don't know about that example—when ARC was added to Objective-C back in the day, I don't remember clang feeling any slower as a result.
  - saagarjha 2y ago
    Parsing IR and lowering it is not the reason why compiling Swift is slow.
    - fastball 2y ago
      What is the reason Swift compile times are slow?
      - saagarjha 2y ago
        Mostly type checking and name lookup