3 ms·

While I appreciate all his work on LLVM, Chris Lattner's Swift didn't work out so well for me, so I'm cautious about this. Swift has some nice features. Howeve

by tomovo 1y ago

While I appreciate all his work on LLVM, Chris Lattner's Swift didn't work out so well for me, so I'm cautious about this. Swift has some nice features. However, the super slow compilation times and cryptic error messages really erase any gains in productivity for me. - "The compiler is unable to type-check this expression in reasonable time?" On an M3 Pro? What the hell!? - To find an error in SwiftUI code I sometimes need to comment everything out block by block to narrow it down and find the culprit. We're getting laughs from Kotlin devs.

melodyogonna 1y ago
I think Swift is really successful in that there are so many new Apple developers who would use Swift now but wouldn't have used ObjC.
davidatbu 1y ago
Fwiw, Chris has mentioned both of those as lessons he took from Swift that he'd like to avoid for Mojo.
elpakal 1y ago
To be fair to Chris, I’ve only seen the message about compiler not being able to type check the expression in swiftui closure hell. I think he left (maybe partly) because of the SwiftUI influence on Swift.
- drivebycomm 1y ago
  Actually, even very basic code can cause it. The type system of Swift has issues. https://www.cocoawithlove.com/blog/2016/07/12/type-checker-issues.html https://www.cocoawithlove.com/blog/2016/07/12/type-checker-i... let a: Double = -(1 + 2) + -(3 + 4) + -(5) Still fails on a very recent version of Swift, Swift 6.1.2, if my test works. Chris Lattner mentions something about him being more of an engineer than a mathematician, but a responsible and competent computer science engineer that is designing programming languages with complex type systems, absolutely has to at least be proficient in university-level mathematics and relevant theory, or delegate out and get computer scientists to find and triple-check any relevant aspects of the budding programing language.
  - chrislattner 1y ago
    Mojo learns a lot from the mistakes in Swift, including this one. Mojo compiles much faster and doesn't have exponential time type checking! :)
    - slavapestov 1y ago
      So what did you decide to give up on? Overloading functions with the same name, or bidirectional constraint solving? :) These days though the type checker is not where compile time is mostly spent in Swift; usually it’s the various SIL and LLVM optimization passes. While the front end could take care to generate less redundant IR upfront, this seems like a generally unavoidable issue with “zero cost abstraction” languages, where the obvious implementation strategy is to spit out a ton of IR, inline everything, and then reduce it to nothing by transforming the IR.
      - chrislattner 1y ago
        Bidirectional constraint solving. It's bad for compile time but even worse for predictable diagnostics. Mojo does contextual resolution, but it works more similar to how C++ resolves initializer lists etc.
        slavapestov 1y ago
        > Bidirectional constraint solving. It's bad for compile time but even worse for predictable diagnostics. That’s really only true if you have overloading though! Without overloading there are no disjunction choices to attempt, and if you also have principal typing it makes the problem of figuring out diagnostics easier, because each expression has a unique most general type in isolation (so your old CSDiag design would actually work in such a language ;-) ) But perhaps a language where you have to rely on generics for everything instead of just overloading a function to take either an Int or a String is a bridge too far for mainstream programmers.
        chrislattner 1y ago

by tomovo 1y ago

melodyogonna 1y ago

I think Swift is really successful in that there are so many new Apple developers who would use Swift now but wouldn't have used ObjC.

davidatbu 1y ago

Fwiw, Chris has mentioned both of those as lessons he took from Swift that he'd like to avoid for Mojo.

elpakal 1y ago

To be fair to Chris, I’ve only seen the message about compiler not being able to type check the expression in swiftui closure hell. I think he left (maybe partly) because of the SwiftUI influence on Swift.

drivebycomm 1y ago
Actually, even very basic code can cause it. The type system of Swift has issues. https://www.cocoawithlove.com/blog/2016/07/12/type-checker-issues.html https://www.cocoawithlove.com/blog/2016/07/12/type-checker-i... let a: Double = -(1 + 2) + -(3 + 4) + -(5) Still fails on a very recent version of Swift, Swift 6.1.2, if my test works. Chris Lattner mentions something about him being more of an engineer than a mathematician, but a responsible and competent computer science engineer that is designing programming languages with complex type systems, absolutely has to at least be proficient in university-level mathematics and relevant theory, or delegate out and get computer scientists to find and triple-check any relevant aspects of the budding programing language.
- chrislattner 1y ago
  Mojo learns a lot from the mistakes in Swift, including this one. Mojo compiles much faster and doesn't have exponential time type checking! :)
  - slavapestov 1y ago
    So what did you decide to give up on? Overloading functions with the same name, or bidirectional constraint solving? :) These days though the type checker is not where compile time is mostly spent in Swift; usually it’s the various SIL and LLVM optimization passes. While the front end could take care to generate less redundant IR upfront, this seems like a generally unavoidable issue with “zero cost abstraction” languages, where the obvious implementation strategy is to spit out a ton of IR, inline everything, and then reduce it to nothing by transforming the IR.
    - chrislattner 1y ago
      Bidirectional constraint solving. It's bad for compile time but even worse for predictable diagnostics. Mojo does contextual resolution, but it works more similar to how C++ resolves initializer lists etc.
      - slavapestov 1y ago
        > Bidirectional constraint solving. It's bad for compile time but even worse for predictable diagnostics. That’s really only true if you have overloading though! Without overloading there are no disjunction choices to attempt, and if you also have principal typing it makes the problem of figuring out diagnostics easier, because each expression has a unique most general type in isolation (so your old CSDiag design would actually work in such a language ;-) ) But perhaps a language where you have to rely on generics for everything instead of just overloading a function to take either an Int or a String is a bridge too far for mainstream programmers.
        chrislattner 1y ago