6 ms·

Overall I like Swift and it's certainly a massive quality of life improvement for Mac/iOS devs. But I don't see as much upside for enterprise development. Serv

Overall I like Swift and it's certainly a massive quality of life improvement for Mac/iOS devs. But I don't see as much upside for enterprise development. Server side tooling and deployment is still TBD, reference counting adds non-negligible cognitive overhead vs GC in an environment where the downsides of GC matter much less. They will have to build a complete ecosystem of server-side libraries from scratch. And unlike on iOS/OSX, there are already a lot of good and much more mature alternatives. I wouldn't be unhappy if Swift became a real contender on the server but it seems unlikely to me that it will.

spotman 10y ago
Can you elaborate on the cognitive overhead vs a GC language like golang or java? (With regards to memory) To me sure there is things you think about but generally memory performance is less of a mental burden. Also, swift 4 is supposed to support a rust like memory model. Not sure if it's opt in or how it will work but my impression is that it's memory model is about to support some new use cases to make it appropriate for more memory critical tasks.
- mikeash 10y ago
  Speaking only for myself, avoiding or breaking retain cycles is a noticeable problem in Swift code that simply isn't there in languages with a proper garbage collector. Among newer iOS programmers, it's a big point of confusion to figure out when a callback closure should use [weak self] versus capturing self strongly, for example. I've seen a lot of people struggle to understand, completely fail, and end up dogmatically using [weak self] everywhere whether it's needed or not (and sometimes where it's actually harmful).
  - pjmlp 10y ago
    It is much easier than in either C++ or Rust.
    - mikeash 10y ago
      Don't C++ and Rust offer the same facilities? C++ has std::weak_ptr and Rust has std::rc::Weak.
      - pjmlp 10y ago
        Yes, but they are library calls without any help from the compiler.
        mikeash 10y ago
        How does that make them any more difficult to use?
        fauigerzigerk 10y ago
        You have to manually optimize away unnecessary reference counting without help from the compiler.
        mikeash 10y ago
        That is true, but a totally different issue from breaking or avoiding retain cycles.
        pcwalton 10y ago
        I have never seen unnecessary reference counting be a problem in Rust. That's because not manipulating the reference count requires an explicit action—.clone()—and borrowing is so expressive that you rarely need to manipulate the counts.
        fauigerzigerk 10y ago
        I guess that's because in Rust you never need defensive reference counting thanks to the borrow checker.
        Rusky 10y ago
  - stepanhruda 10y ago
    With @nonescaping becoming the default, this might become a bit simpler. Not too much, but a bit.
- fauigerzigerk 10y ago
  Reference counting has upsides and downsides. If you look at the lengths that some Java based projects like Spark have to go to in order tame the GC, then you have to question whether tracing GC is the right choice in the age of hundereds of GBs of memory. On the other hand reference counting is extremely slow. So slow that it puts a lot of restrictions on API design and that is definitely a mental burden. Swift's own collection interface changed massively between 2.x and 3 and I believe the main reason for the redesign was that the old design required too much reference counting. (I'm not completely sure this is an accurate reflection of their thinking though)
  - zzzcpan 10y ago
    > On the other hand reference counting is extremely slow. So slow that it puts a lot of restrictions on API design and that is definitely a mental burden. This is very wrong on both points. Reference counting has a lot less mental burden compared to GC, because it's predictable. You can rely on destructors to actually work and be useful. For example, you don't have to keep track of whether you closed your file descriptor or not, but in GCd languages you have to do that manually, sometimes even with the same reference counting, but hand-written and explicit. Reference counting is also very fast, with the exception of concurrent decades old implementations, that are irrelevant today.
    - fauigerzigerk 10y ago
      I don't disagree on the benefits of RAII at all. I love it. It's a much cleaner and more general resource management idea than a tracing GC. But incrementing/decrementing an atomic value in a tight loop apparently creates a performance problem that is severe enough for the Swift team to redesign their API. That wasn't decades ago: "Code that handles indices has to perform atomic reference counting, which has significant overhead and can prevent the optimizer from making other improvements." https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md https://github.com/apple/swift-evolution/blob/master/proposa...
WayneBro 10y ago
I wouldn't use Swift anywhere that I didn't have to until the terribly klunky and overly verbose Strings API is fixed - https://news.ycombinator.com/item?id=10519711 https://news.ycombinator.com/item?id=10519711 This is a typical Apple product to me - they obsessed over their idea of correctness and ended up with something that is difficult to use and completely alien. Meanwhile every other language offers convenience without even stopping you from doing anything else that you might need to do with Unicode...
- nicky0 10y ago
  To me, the Strings API is one of the best things about Swift. Strings are complicated and as Mike Ash says in that very article, "Swift doesn't sugar-coat it, but instead shows you the reality of what's going on. This can be difficult, but it's no more difficult than it needs to be."
  - WayneBro 10y ago
    Assembly is complicated too. I want it sugarcoated most of the time though. There are very few times when I need to drop down into assembly.
    - nicky0 10y ago
      I don't accept assembly as a valid analogy.
      - WayneBro 10y ago
        I don't accept your non-acceptance of assembly as a valid analogy except I'll actually tell you the reason why - you didn't give any reasoning whatsoever. This is a perfectly valid analogy. Visible characters in a strings are to Unicode code points as high-level functions in high-level code are to assembly commands. Furthermore, even without using an analogy I'm quite comfortable in saying, again, that I want Strings sugarcoated because 99.9% of the time I don't give a fuck about some bullshit ivory tower corrected view of things that makes the common scenario more difficult than it needs to be.
Aker89 10y ago
Meanwhile, developers are flocking to contribute to the most popular server-side Swift frameworks, like Perfect, Vapor and Kitura. I have followed the development closely, and for such a new language the enthusiasm around these projects are surprisingly big. I think the potential of server-side Swift is underestimated. Of course there's still several features lacking at this point, but that is to be expected of such a new language and will only improve. But yeah, large enterprise deployments are probably too early.

spotman 10y ago

Can you elaborate on the cognitive overhead vs a GC language like golang or java? (With regards to memory) To me sure there is things you think about but generally memory performance is less of a mental burden. Also, swift 4 is supposed to support a rust like memory model. Not sure if it's opt in or how it will work but my impression is that it's memory model is about to support some new use cases to make it appropriate for more memory critical tasks.

mikeash 10y ago
Speaking only for myself, avoiding or breaking retain cycles is a noticeable problem in Swift code that simply isn't there in languages with a proper garbage collector. Among newer iOS programmers, it's a big point of confusion to figure out when a callback closure should use [weak self] versus capturing self strongly, for example. I've seen a lot of people struggle to understand, completely fail, and end up dogmatically using [weak self] everywhere whether it's needed or not (and sometimes where it's actually harmful).
- pjmlp 10y ago
  It is much easier than in either C++ or Rust.
  - mikeash 10y ago
    Don't C++ and Rust offer the same facilities? C++ has std::weak_ptr and Rust has std::rc::Weak.
    - pjmlp 10y ago
      Yes, but they are library calls without any help from the compiler.
      - mikeash 10y ago
        How does that make them any more difficult to use?
        fauigerzigerk 10y ago
        You have to manually optimize away unnecessary reference counting without help from the compiler.
        mikeash 10y ago
        That is true, but a totally different issue from breaking or avoiding retain cycles.
        pcwalton 10y ago
        I have never seen unnecessary reference counting be a problem in Rust. That's because not manipulating the reference count requires an explicit action—.clone()—and borrowing is so expressive that you rarely need to manipulate the counts.
        fauigerzigerk 10y ago
        I guess that's because in Rust you never need defensive reference counting thanks to the borrow checker.
        Rusky 10y ago
- stepanhruda 10y ago
  With @nonescaping becoming the default, this might become a bit simpler. Not too much, but a bit.
fauigerzigerk 10y ago
Reference counting has upsides and downsides. If you look at the lengths that some Java based projects like Spark have to go to in order tame the GC, then you have to question whether tracing GC is the right choice in the age of hundereds of GBs of memory. On the other hand reference counting is extremely slow. So slow that it puts a lot of restrictions on API design and that is definitely a mental burden. Swift's own collection interface changed massively between 2.x and 3 and I believe the main reason for the redesign was that the old design required too much reference counting. (I'm not completely sure this is an accurate reflection of their thinking though)
- zzzcpan 10y ago
  > On the other hand reference counting is extremely slow. So slow that it puts a lot of restrictions on API design and that is definitely a mental burden. This is very wrong on both points. Reference counting has a lot less mental burden compared to GC, because it's predictable. You can rely on destructors to actually work and be useful. For example, you don't have to keep track of whether you closed your file descriptor or not, but in GCd languages you have to do that manually, sometimes even with the same reference counting, but hand-written and explicit. Reference counting is also very fast, with the exception of concurrent decades old implementations, that are irrelevant today.
  - fauigerzigerk 10y ago
    I don't disagree on the benefits of RAII at all. I love it. It's a much cleaner and more general resource management idea than a tracing GC. But incrementing/decrementing an atomic value in a tight loop apparently creates a performance problem that is severe enough for the Swift team to redesign their API. That wasn't decades ago: "Code that handles indices has to perform atomic reference counting, which has significant overhead and can prevent the optimizer from making other improvements." https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md https://github.com/apple/swift-evolution/blob/master/proposa...

WayneBro 10y ago

I wouldn't use Swift anywhere that I didn't have to until the terribly klunky and overly verbose Strings API is fixed - https://news.ycombinator.com/item?id=10519711 https://news.ycombinator.com/item?id=10519711 This is a typical Apple product to me - they obsessed over their idea of correctness and ended up with something that is difficult to use and completely alien. Meanwhile every other language offers convenience without even stopping you from doing anything else that you might need to do with Unicode...

nicky0 10y ago
To me, the Strings API is one of the best things about Swift. Strings are complicated and as Mike Ash says in that very article, "Swift doesn't sugar-coat it, but instead shows you the reality of what's going on. This can be difficult, but it's no more difficult than it needs to be."
- WayneBro 10y ago
  Assembly is complicated too. I want it sugarcoated most of the time though. There are very few times when I need to drop down into assembly.
  - nicky0 10y ago
    I don't accept assembly as a valid analogy.
    - WayneBro 10y ago
      I don't accept your non-acceptance of assembly as a valid analogy except I'll actually tell you the reason why - you didn't give any reasoning whatsoever. This is a perfectly valid analogy. Visible characters in a strings are to Unicode code points as high-level functions in high-level code are to assembly commands. Furthermore, even without using an analogy I'm quite comfortable in saying, again, that I want Strings sugarcoated because 99.9% of the time I don't give a fuck about some bullshit ivory tower corrected view of things that makes the common scenario more difficult than it needs to be.

Aker89 10y ago

Meanwhile, developers are flocking to contribute to the most popular server-side Swift frameworks, like Perfect, Vapor and Kitura. I have followed the development closely, and for such a new language the enthusiasm around these projects are surprisingly big. I think the potential of server-side Swift is underestimated. Of course there's still several features lacking at this point, but that is to be expected of such a new language and will only improve. But yeah, large enterprise deployments are probably too early.