5 ms·

Yea, but you lose C++ interop, your binary will be inflated with those Swift proxy libs and your compilation times will increase 2-3-fold.

LeoNatan25 9y ago
Those are actually temporary problems. Once ABI stability is implemented, those DLLs will not be needed. The compiler is obviously a WIP and will take years to become more mature and optimized. Likewise for C++ interop. There are fundamental issues with Swift, but those are not them.
- saagarjha 9y ago
  I'm much more hopeful for ABI stability than C++ interoperatability. I think will take a long time before we'll be able to seamlessly work with C++ code as we do currently with say Objective-C or C.
  - LeoNatan25 9y ago
    Weren’t some steps taken to start working on preliminary support, or at least building blocks? I might be mistaken.
    - saagarjha 9y ago
      I've been mostly away from the Swift Forums for the last couple weeks, so if they've done something recently I probably missed it. Otherwise, though, AFAIK there's very few user-facing features that we can take advantage of right now. I do know that this is something that is on the roadmap, but so far the only changes related to this feature would be confined to the internals of the compiler, if at all. Here's a relatively recent thread by Doug Gregor where he outlines some of the challenges necessary to surmount if this feature is to ever land: https://forums.swift.org/t/c-objective-c-interop/9989 https://forums.swift.org/t/c-objective-c-interop/9989
      - LeoNatan25 9y ago
        Yes, that's what I meant, some groundwork in the compiler internals. As I said, I could be misremembering. That's an interesting thread, thanks!
- mpweiher 9y ago
  Compile times are not a temporary problem, they are fundamental. Yes, they can fix some of the more egregious specific problems, but the model they have chosen is inherently expensive to compile as it leans so much on the compiler. And they no longer have Mr. Moore to bail them out by mere passage of time. In fact, last I checked the compiler has actually gotten slower, overall, in recent versions.
  - aplummer 9y ago
    It’s gotten a decent but faster very recently for many cases, but still slow and throws weird false warnings sometimes.
  - LeoNatan25 9y ago
    Could you provide a documentation on the compiler model of Swift, and why it would be slower? How can that model be compared to clang's c++ compiler model?
    - mpweiher 9y ago
      The model for Swift is for the compiler to do a lot of work. Doing a lot of work takes more time than doing less work. There was an interview/article a while back that explained this for C++/D, I think it might have even been by Walter Bright himself, that explained this really well. Sadly, I can't find it right now. In essence, C++ is predicated on the compiler being able to see through any abstractions you might have provided at compile time, in order to be able to optimize that away. That means you effectively lose separate compilation, because the compiler has to look at the implementation of dependencies, not just at their interfaces. Transitively. So C++ is a lot slower to compile than C/Objective-C, and Swift is very similar, it just doubles down on that model. With this model it doesn't come as a surprise that compiling everything at once is often massively quicker than compiling single source files, the "whole module optimization without optimization" thing. I also think there's at least some polynomial factor involved here, so as your projects get bigger, per-file compile times get significantly slower. C and Objective-C really take separate compilation to heart, so you don't run into nearly the same problems (though: header files :-( ). Go is a more modern take on this, compile times are legendary. In addition to that, Swift leans extremely heavily on the optimizer to get common constructs to execute in reasonable time, rather than 100x or more slower than you'd expect. That also costs. A lot. tcc doesn't really optimize much, it's a good example of how fast a C compile can go. (I clocked it at several hundred thousand lines of code per second or more, for comparison, numbers from a Swift project were 60 lines of code per second). And last not least there's pretty wild forward/backward type inference, which will happily go exponential. For example, let's look at the following code: let a:[Int] = [1] + [2] + [3] + [4] + [5] + [6] This actually used to fail with "expression too complex", nowadays it compiles in 26 seconds on my machine, and adding one more integer array gets it to fail again, after 59 seconds. Hmmm...
- tzahola 9y ago
  Sure, by all means they should keep up the good work. I'll be happy to switch when it's ready. But until then, I'll stick to my trusty Objective-C for serious work.

LeoNatan25 9y ago

Those are actually temporary problems. Once ABI stability is implemented, those DLLs will not be needed. The compiler is obviously a WIP and will take years to become more mature and optimized. Likewise for C++ interop. There are fundamental issues with Swift, but those are not them.

saagarjha 9y ago
I'm much more hopeful for ABI stability than C++ interoperatability. I think will take a long time before we'll be able to seamlessly work with C++ code as we do currently with say Objective-C or C.
- LeoNatan25 9y ago
  Weren’t some steps taken to start working on preliminary support, or at least building blocks? I might be mistaken.
  - saagarjha 9y ago
    I've been mostly away from the Swift Forums for the last couple weeks, so if they've done something recently I probably missed it. Otherwise, though, AFAIK there's very few user-facing features that we can take advantage of right now. I do know that this is something that is on the roadmap, but so far the only changes related to this feature would be confined to the internals of the compiler, if at all. Here's a relatively recent thread by Doug Gregor where he outlines some of the challenges necessary to surmount if this feature is to ever land: https://forums.swift.org/t/c-objective-c-interop/9989 https://forums.swift.org/t/c-objective-c-interop/9989
    - LeoNatan25 9y ago
      Yes, that's what I meant, some groundwork in the compiler internals. As I said, I could be misremembering. That's an interesting thread, thanks!
mpweiher 9y ago
Compile times are not a temporary problem, they are fundamental. Yes, they can fix some of the more egregious specific problems, but the model they have chosen is inherently expensive to compile as it leans so much on the compiler. And they no longer have Mr. Moore to bail them out by mere passage of time. In fact, last I checked the compiler has actually gotten slower, overall, in recent versions.
- aplummer 9y ago
  It’s gotten a decent but faster very recently for many cases, but still slow and throws weird false warnings sometimes.
- LeoNatan25 9y ago
  Could you provide a documentation on the compiler model of Swift, and why it would be slower? How can that model be compared to clang's c++ compiler model?
  - mpweiher 9y ago
    The model for Swift is for the compiler to do a lot of work. Doing a lot of work takes more time than doing less work. There was an interview/article a while back that explained this for C++/D, I think it might have even been by Walter Bright himself, that explained this really well. Sadly, I can't find it right now. In essence, C++ is predicated on the compiler being able to see through any abstractions you might have provided at compile time, in order to be able to optimize that away. That means you effectively lose separate compilation, because the compiler has to look at the implementation of dependencies, not just at their interfaces. Transitively. So C++ is a lot slower to compile than C/Objective-C, and Swift is very similar, it just doubles down on that model. With this model it doesn't come as a surprise that compiling everything at once is often massively quicker than compiling single source files, the "whole module optimization without optimization" thing. I also think there's at least some polynomial factor involved here, so as your projects get bigger, per-file compile times get significantly slower. C and Objective-C really take separate compilation to heart, so you don't run into nearly the same problems (though: header files :-( ). Go is a more modern take on this, compile times are legendary. In addition to that, Swift leans extremely heavily on the optimizer to get common constructs to execute in reasonable time, rather than 100x or more slower than you'd expect. That also costs. A lot. tcc doesn't really optimize much, it's a good example of how fast a C compile can go. (I clocked it at several hundred thousand lines of code per second or more, for comparison, numbers from a Swift project were 60 lines of code per second). And last not least there's pretty wild forward/backward type inference, which will happily go exponential. For example, let's look at the following code: let a:[Int] = [1] + [2] + [3] + [4] + [5] + [6] This actually used to fail with "expression too complex", nowadays it compiles in 26 seconds on my machine, and adding one more integer array gets it to fail again, after 59 seconds. Hmmm...
tzahola 9y ago
Sure, by all means they should keep up the good work. I'll be happy to switch when it's ready. But until then, I'll stick to my trusty Objective-C for serious work.