7 ms·

I think the pitch is that despite static typing, it offers a lot of multi-paradigm high-level features while remaining elegant with fairly minimal syntax compar

I think the pitch is that despite static typing, it offers a lot of multi-paradigm high-level features while remaining elegant with fairly minimal syntax compared to other native static languages like Rust or C++. It automatically manages memory but without a stop-the-world garbage collector and goes a long way to opening a lot of flexible design options to any developer: it has great support for generic programming, object orientation, and functional programming. The downsides? Well, I find some of its syntax choices a bit odd and inconsistent; I think the pursuit of elegance could have gone much further. And, while I celebrate its pervasive use of closures/lambdas and functional idioms in my many contexts, it lacks true functional data structures that would be necessary to really write in a proper functional style with confidence that the runtime wouldn't suffer. Also, the implementation of its high-level features is somewhat magical and hidden. You can't depend on performance when using them until you really study them. So much so, that WWDC had a big talk about how to choose language features depending on the type of performance you need, and none of it was intuitive. Additionally, at least on the Apple platforms, its Objective-C heritage can be a bit annoying. In particular, you can't mix and match closures with "selectors", which is a real shame and missed opportunity for flexibility and elegance.

deleted 10y ago
[deleted]
Razengan 10y ago
> You can't depend on performance when using them until you really study them. So much so, that WWDC had a big talk about how to choose language features depending on the type of performance you need, and none of it was intuitive. In which language does optimal performance come for free without really studying it? You have to pay attention to your case and context and use features accordingly, no matter what language you're using..
pjmlp 10y ago
> but without a stop-the-world garbage collector a RC is a stop-the-world garbage collector when the reference count reaches 0 in very complex data structures, which trigger a cascade of deletions. Also it has issues with sharing data between threads leading to cache coherency contention and locks.
- hellofunk 10y ago
  Fair enough. The point I was (trying) to make is that Swift doesn't have a traditional GC like Java, or Javascript, etc.
- gpderetta 10y ago
  That's not stop the world. Under RC, when a thread is destroying a complex data structure, other threads are free to keep doing useful work. RC does otherwise have very bad interactions with threads of course. edit: clarify
  - pjmlp 10y ago
    Just like a parallel GC.
    - gpderetta 10y ago
      parallel != stop-the-world
themihai 10y ago
> It automatically manages memory I have to stop you there. You shouldn't compare anything to C/C++ or Rust after that. You are better off comparing Swift with Go(i.e. both have automatic memory management, nice syntax, static typing, dynamic feeling etc) or Java(automatic memory management, well established in the enterprise world). If Apple was to design a language to respond to Go or Java it would be Swift and that's it. So the pitch is that you have a nice language which encourages productivity and you can share the knowledge/code between server and client.
- hellofunk 10y ago
  Well, technically Swift's memory management is the same as what C++ offers via smart pointers, the only difference is that in C++ it is opt-in (and still very popular). Swift is quite unlike Go or Java's memory management; it is not a GC in the sense that they use it.
  - pcwalton 10y ago
    Swift memory management isn't nearly as expressive as C++ when it comes to references (i.e. unmanaged pointers). You can use in/out/inout parameters on functions and that's about it. I agree with the parent that Swift memory management is basically like Go or Java: everything is GC'd (reference counting being a form of GC).
    - hellofunk 10y ago
      You don't need in/out params to get references; in Swift, anything defined with "class" is always passed by reference.
      - pcwalton 10y ago
        Unmanaged references. Regular old class references aren't unmanaged (they adjust reference counts).
  - themihai 10y ago
dcosson 10y ago
One other downside is XCode. No refactoring support, and lots of errors that give you little help. For instance, if you're trying to implement a protocol which is itself a few layers of nested protocols, XCode will just tell you it doesn't conform and not what method you're missing, so you have to dig through and check every signature of every method carefully. The swift 2 to 3 migration was absolutely insane, I'd estimate Xcode did maybe 25% of the work automatically and left me with hundreds of different errors to convert manually (and often they were red herrings where the actual error was not where Xcode said it was). And you have to rebuild all dependency frameworks on swift 3 as well since the binaries are incompatible. If you use Swift make sure you have 2-3 whole developer days per year to devote to just migrating to the next version in a medium sized project.
- coldcode 10y ago
  Swift is amazing, Xcode is crap, and I've been using Xcode and its NeXT version for almost 20 years. I work in Xcode every day and every day I want to hurl it. Apparently Apple either doesn't care or is too overwhelmed with building 4 OSs every year. To be effective for building server side apps we need a new dev environment.
- emdowling 10y ago
  I would agree with this. The biggest issue with Swift right now is Xcode. Multiple times each day, syntax highlighting and code completion will break, even though the code is perfectly valid. The lack of refactor support after three Xcode releases and major versions of Swift is inexcusable. Using storyboards is super frustrating due to the load times. It seems no one at Apple tests with more than one storyboard in a project. I love going back to Ruby dev because VS Code is just such a joy to work in compared with Xcode. Xcode really struggles on my top of the line MBP with 16GB RAM. I still love the language compared to ObjC but the tooling is abysmal. Every year we hold out hope that Xcode will magically get better but its the iTunes of IDEs at this point.
  - dep_b 10y ago
    Well I don't know any experienced developer that would put more than three populated scenes in a Storyboard. I would only add more if it was something like a navigation setup (navcontroller, menu, etc) where I would simply nest a lot of empty screens and link to the real screens with storyboard references. You can always use AppCode if you don't like Xcode.

deleted 10y ago

[deleted]

Razengan 10y ago

> You can't depend on performance when using them until you really study them. So much so, that WWDC had a big talk about how to choose language features depending on the type of performance you need, and none of it was intuitive. In which language does optimal performance come for free without really studying it? You have to pay attention to your case and context and use features accordingly, no matter what language you're using..

pjmlp 10y ago

> but without a stop-the-world garbage collector a RC is a stop-the-world garbage collector when the reference count reaches 0 in very complex data structures, which trigger a cascade of deletions. Also it has issues with sharing data between threads leading to cache coherency contention and locks.

hellofunk 10y ago
Fair enough. The point I was (trying) to make is that Swift doesn't have a traditional GC like Java, or Javascript, etc.
gpderetta 10y ago
That's not stop the world. Under RC, when a thread is destroying a complex data structure, other threads are free to keep doing useful work. RC does otherwise have very bad interactions with threads of course. edit: clarify
- pjmlp 10y ago
  Just like a parallel GC.
  - gpderetta 10y ago
    parallel != stop-the-world

themihai 10y ago

> It automatically manages memory I have to stop you there. You shouldn't compare anything to C/C++ or Rust after that. You are better off comparing Swift with Go(i.e. both have automatic memory management, nice syntax, static typing, dynamic feeling etc) or Java(automatic memory management, well established in the enterprise world). If Apple was to design a language to respond to Go or Java it would be Swift and that's it. So the pitch is that you have a nice language which encourages productivity and you can share the knowledge/code between server and client.

hellofunk 10y ago
Well, technically Swift's memory management is the same as what C++ offers via smart pointers, the only difference is that in C++ it is opt-in (and still very popular). Swift is quite unlike Go or Java's memory management; it is not a GC in the sense that they use it.
- pcwalton 10y ago
  Swift memory management isn't nearly as expressive as C++ when it comes to references (i.e. unmanaged pointers). You can use in/out/inout parameters on functions and that's about it. I agree with the parent that Swift memory management is basically like Go or Java: everything is GC'd (reference counting being a form of GC).
  - hellofunk 10y ago
    You don't need in/out params to get references; in Swift, anything defined with "class" is always passed by reference.
    - pcwalton 10y ago
      Unmanaged references. Regular old class references aren't unmanaged (they adjust reference counts).
- themihai 10y ago

dcosson 10y ago

One other downside is XCode. No refactoring support, and lots of errors that give you little help. For instance, if you're trying to implement a protocol which is itself a few layers of nested protocols, XCode will just tell you it doesn't conform and not what method you're missing, so you have to dig through and check every signature of every method carefully. The swift 2 to 3 migration was absolutely insane, I'd estimate Xcode did maybe 25% of the work automatically and left me with hundreds of different errors to convert manually (and often they were red herrings where the actual error was not where Xcode said it was). And you have to rebuild all dependency frameworks on swift 3 as well since the binaries are incompatible. If you use Swift make sure you have 2-3 whole developer days per year to devote to just migrating to the next version in a medium sized project.

coldcode 10y ago
Swift is amazing, Xcode is crap, and I've been using Xcode and its NeXT version for almost 20 years. I work in Xcode every day and every day I want to hurl it. Apparently Apple either doesn't care or is too overwhelmed with building 4 OSs every year. To be effective for building server side apps we need a new dev environment.
emdowling 10y ago
I would agree with this. The biggest issue with Swift right now is Xcode. Multiple times each day, syntax highlighting and code completion will break, even though the code is perfectly valid. The lack of refactor support after three Xcode releases and major versions of Swift is inexcusable. Using storyboards is super frustrating due to the load times. It seems no one at Apple tests with more than one storyboard in a project. I love going back to Ruby dev because VS Code is just such a joy to work in compared with Xcode. Xcode really struggles on my top of the line MBP with 16GB RAM. I still love the language compared to ObjC but the tooling is abysmal. Every year we hold out hope that Xcode will magically get better but its the iTunes of IDEs at this point.
- dep_b 10y ago
  Well I don't know any experienced developer that would put more than three populated scenes in a Storyboard. I would only add more if it was something like a navigation setup (navcontroller, menu, etc) where I would simply nest a lot of empty screens and link to the real screens with storyboard references. You can always use AppCode if you don't like Xcode.