8 ms·

So... what's the "elevator pitch" for Swift? It has anything interesting over Elixir or Go (well, go's feature is "lack of feature" but you know what I mean) o

by nnq 10y ago

So... what's the "elevator pitch" for Swift? It has anything interesting over Elixir or Go (well, go's feature is "lack of feature" but you know what I mean) or Scala or Kotlin? I know that iOS and MacOS desperately needed a modern language, and great for them that they have it now, but does the rest of the world need it?

qaq 10y ago
It's fairly decent as far as OOP languages go, but I'd say it's appeal as server side language is limited to iOS devs though :).
- eyelidlessness 10y ago
  I don't think it's fair to call Swift an OOP language. It is certainly multi-paradigm, but provides a lot of facilities for functional programming as well. If you are not working directly with Cocoa, you can do a lot of interesting stuff with structs and protocols. It appeals to me as a server-side language, and I've never done any iOS work. The reasons it appeals: - Static types - Good type system - Lots of good support for immutability - Apple is heavily invested in Swift, and very responsive to the community It has some downsides. I'd evaluate Swift against Clojure and Elixir (which both have good, though quite different, concurrency stories), and maybe Haskell (but that would be tough from a buy-in perspective). But evaluating it against Python (which my team currently uses), it's hard to see a downside; we chose Python for Django and DRF, but we're increasingly not in love with that choice.
- Aker89 10y ago
  Okey, so what is appealing to you then? (just curious)
  - qaq 10y ago
    Elixir
hellofunk 10y ago
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.
geodel 10y ago
It is backed by Apple and will be main language to develop for iOS/macOS/tvOS/watchOS systems.
supster 10y ago
1. Inferred static nominal typing with generics 2. 1st class support for Optionals 3. Support for Structs and Classes 4. Native binary & scripting mode 5. Automatic reference counting (instead of garbage collection) 6. Large standard library 7. Large corporate backer (Apple) 8. Open source 9. Good C, C++, & Obj-C interoperability 10. Decently fast (https://medium.com/@qutheory/server-side-swift-vs-the-other-guys-2-speed-ca65b2f79505#.1fj3tnmxa https://medium.com/@qutheory/server-side-swift-vs-the-other-...)
- stepanhruda 10y ago
  Non C++ interop yet
  - supster 10y ago
    You're right, I believe it's on the road map
    - 0xCMP 10y ago
      But good Objective-C interop for working with old app code and libraries (Which comes from the C support, but with all the special stuff done to talk to Obj-C done for you)
  - pjmlp 10y ago
    No, but one can make use of Objective-C++ as a way to create Swift wrappers.
Dancing_Mad 10y ago
It allows enterprises to use their current iOS and macOS developers to do Web Application and server side applications. For developers it gives them additional ecosystems to use their skills on without having to learn a new language from scratch.
- toomanybeersies 10y ago
  I would suspect that most companies have more non-iOS developers than iOS developers.
- softawre 10y ago
  Heh, deja-vu man. That's what we said about ASP.net/windows years ago.
- Un1corn 10y ago
  >It allows enterprises to use their current iOS and macOS developers to do Web Application and server side applications. That's what they said about front-end web developers and now we have nodeJS.
aikah 10y ago
Swift is statically typed (Elixir isn't) with a good type system (Go hasn't) and doesn't run in a VM (like Scala or Kotlin). I don't know how good its concurrency is and on how many platforms it is available though. It also looks like the language itself is still not that stable which is in my opinion a no go.
- pjmlp 10y ago
  Scala and Kotlin both have projects for AOT compilation to native code. You can also get it today with any commercial JDK like Excelsior JET.
  - iheartmemcache 10y ago
    Yep, and as a result of this, the JDK ecosystem is healthy as ever. N.b to those who have only written web or phone apps for a living -- GC latency isn't 'bad' in most cases - unpredictable latency is what's bad. Having a deterministic upper-bound is what is important in the enterprise, on your aviation component regulating cabin pressure, on your SWIFT bank transfer. Also, see the top comment here: https://news.ycombinator.com/item?id=11759762 https://news.ycombinator.com/item?id=11759762 for a JDK discussion against ref-counting, along with this [now incredibly old] paper https://www.cs.purdue.edu/homes/hosking/690M/urc-oopsla-2003.pdf https://www.cs.purdue.edu/homes/hosking/690M/urc-oopsla-2003... (N.b. around the time that paper was published, I was in HFT. We used Azul C4 and it just fine to crush even with management taking their typical 30/3 fees. Though to be fair, this was when the easy pickin's were still there to be plucked. Don't underestimate how well good-ol' free Hotspot is now; we're not talking 1996 Jakarta days with Swing)
    - pjmlp 10y ago
      One of the reasons I always argue for GC is that I used Native Oberon, and also collect papers related to Xerox PARC and DEC research. Modern hardware would be a dream to any of those researchers doing systems programming in GC enabled languages. I only consider the biggest flaws of Java not adopting AOT from the beginning and the lack of value types. Now the JDK ecosystem needs to wait until Java 10, probably around 2020 or later, to get them.
TurboHaskal 10y ago
It is backed by Apple and will become the de facto language for writing iOS (macOS too?) applications, potentially attracting a healthy pool of developers and thus reducing costs which in the end is all that matters in non high integrity software. Features don't matter much I'm afraid.
coldtea 10y ago
>It has anything interesting over Elixir or Go Compared to Go it's a whole other level of interesting... Think of Highway 50 (NV) vs Highway 1 (CA).
- cozzyd 10y ago
  70 mph vs. 15 mph?
mdasen 10y ago
It does have some interesting bits. 1. It doesn't have a GC. While the JVM's GC is decent, it can definitely cause latency spikes. 2. It has value types. Go has this, but Scala and Kotlin mean running on the JVM which means leaving memory locality behind. In fact, Swift allows you to select whether you want an object that contains pointers to things or a struct. Go gives you structs and Scala and Kotlin give you pointer-based objects. If all you care about is syntax, Swift might not be that interesting to you. However, you get options in terms of how the program runs that the other languages you've mentioned don't give you. You can't decide that you want to create an object in Scala or Kotlin that is contiguous in memory. You can't decide you'd rather not have GC pauses in Go. In many ways, Swift brought together the kind of niceties that have been available before. Generics aren't something new, value types aren't new, objects aren't new, first-class functions aren't new, ARC isn't new, non-nullable variables aren't new, closures aren't new, type inference isn't new. . . But none of those languages have all of those. Go took a hard stance against generics (I'm not going to go into why). The JVM doesn't really do value types. GC has been the standard for most new languages for a while. Swift definitely offers new things.
- pjmlp 10y ago
  > While the JVM's GC is decent, it can definitely cause latency spikes. Which one? Java is like C and C++, there are plenty of JDKs to chose from, each it is own set of implementation behaviors, for the different types of customer pocket sizes.
- premium-concern 10y ago
  Scala has value types, and on native all the current restrictions from the JVM are dropped. Additionally, you can also explicitly allocate things on the stack. You can also allocate continuous memory.
Someone 10y ago
For IBM, part of the lure probably is "the enemy of my enemy is my friend". It's not running on a VM that Oracle or Microsoft control, and not a language Google controls. Yes, it is Apple's language, but IBM apparently thinks it will become more popular than one they would control on their own, and picking Apple's language then is, for them, the least risky, as Apple isn't a company focusing on servers.
- pducks32 10y ago
  Other than Swift being a great language this is certainly at the top of the list. If not on a management level then on a developer POV level. Plus in some way they associate Apple with themselves, they become (in some weird way) the Apple of enterprise.

by nnq 10y ago

qaq 10y ago

It's fairly decent as far as OOP languages go, but I'd say it's appeal as server side language is limited to iOS devs though :).

eyelidlessness 10y ago
I don't think it's fair to call Swift an OOP language. It is certainly multi-paradigm, but provides a lot of facilities for functional programming as well. If you are not working directly with Cocoa, you can do a lot of interesting stuff with structs and protocols. It appeals to me as a server-side language, and I've never done any iOS work. The reasons it appeals: - Static types - Good type system - Lots of good support for immutability - Apple is heavily invested in Swift, and very responsive to the community It has some downsides. I'd evaluate Swift against Clojure and Elixir (which both have good, though quite different, concurrency stories), and maybe Haskell (but that would be tough from a buy-in perspective). But evaluating it against Python (which my team currently uses), it's hard to see a downside; we chose Python for Django and DRF, but we're increasingly not in love with that choice.
Aker89 10y ago
Okey, so what is appealing to you then? (just curious)
- qaq 10y ago
  Elixir

hellofunk 10y ago

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.

geodel 10y ago

It is backed by Apple and will be main language to develop for iOS/macOS/tvOS/watchOS systems.

supster 10y ago

1. Inferred static nominal typing with generics 2. 1st class support for Optionals 3. Support for Structs and Classes 4. Native binary & scripting mode 5. Automatic reference counting (instead of garbage collection) 6. Large standard library 7. Large corporate backer (Apple) 8. Open source 9. Good C, C++, & Obj-C interoperability 10. Decently fast (https://medium.com/@qutheory/server-side-swift-vs-the-other-guys-2-speed-ca65b2f79505#.1fj3tnmxa https://medium.com/@qutheory/server-side-swift-vs-the-other-...)

stepanhruda 10y ago
Non C++ interop yet
- supster 10y ago
  You're right, I believe it's on the road map
  - 0xCMP 10y ago
    But good Objective-C interop for working with old app code and libraries (Which comes from the C support, but with all the special stuff done to talk to Obj-C done for you)
- pjmlp 10y ago
  No, but one can make use of Objective-C++ as a way to create Swift wrappers.

Dancing_Mad 10y ago

It allows enterprises to use their current iOS and macOS developers to do Web Application and server side applications. For developers it gives them additional ecosystems to use their skills on without having to learn a new language from scratch.

toomanybeersies 10y ago
I would suspect that most companies have more non-iOS developers than iOS developers.
softawre 10y ago
Heh, deja-vu man. That's what we said about ASP.net/windows years ago.
Un1corn 10y ago
>It allows enterprises to use their current iOS and macOS developers to do Web Application and server side applications. That's what they said about front-end web developers and now we have nodeJS.

aikah 10y ago

Swift is statically typed (Elixir isn't) with a good type system (Go hasn't) and doesn't run in a VM (like Scala or Kotlin). I don't know how good its concurrency is and on how many platforms it is available though. It also looks like the language itself is still not that stable which is in my opinion a no go.

pjmlp 10y ago
Scala and Kotlin both have projects for AOT compilation to native code. You can also get it today with any commercial JDK like Excelsior JET.
- iheartmemcache 10y ago
  Yep, and as a result of this, the JDK ecosystem is healthy as ever. N.b to those who have only written web or phone apps for a living -- GC latency isn't 'bad' in most cases - unpredictable latency is what's bad. Having a deterministic upper-bound is what is important in the enterprise, on your aviation component regulating cabin pressure, on your SWIFT bank transfer. Also, see the top comment here: https://news.ycombinator.com/item?id=11759762 https://news.ycombinator.com/item?id=11759762 for a JDK discussion against ref-counting, along with this [now incredibly old] paper https://www.cs.purdue.edu/homes/hosking/690M/urc-oopsla-2003.pdf https://www.cs.purdue.edu/homes/hosking/690M/urc-oopsla-2003... (N.b. around the time that paper was published, I was in HFT. We used Azul C4 and it just fine to crush even with management taking their typical 30/3 fees. Though to be fair, this was when the easy pickin's were still there to be plucked. Don't underestimate how well good-ol' free Hotspot is now; we're not talking 1996 Jakarta days with Swing)
  - pjmlp 10y ago
    One of the reasons I always argue for GC is that I used Native Oberon, and also collect papers related to Xerox PARC and DEC research. Modern hardware would be a dream to any of those researchers doing systems programming in GC enabled languages. I only consider the biggest flaws of Java not adopting AOT from the beginning and the lack of value types. Now the JDK ecosystem needs to wait until Java 10, probably around 2020 or later, to get them.

TurboHaskal 10y ago

It is backed by Apple and will become the de facto language for writing iOS (macOS too?) applications, potentially attracting a healthy pool of developers and thus reducing costs which in the end is all that matters in non high integrity software. Features don't matter much I'm afraid.

coldtea 10y ago

>It has anything interesting over Elixir or Go Compared to Go it's a whole other level of interesting... Think of Highway 50 (NV) vs Highway 1 (CA).

cozzyd 10y ago
70 mph vs. 15 mph?

mdasen 10y ago

It does have some interesting bits. 1. It doesn't have a GC. While the JVM's GC is decent, it can definitely cause latency spikes. 2. It has value types. Go has this, but Scala and Kotlin mean running on the JVM which means leaving memory locality behind. In fact, Swift allows you to select whether you want an object that contains pointers to things or a struct. Go gives you structs and Scala and Kotlin give you pointer-based objects. If all you care about is syntax, Swift might not be that interesting to you. However, you get options in terms of how the program runs that the other languages you've mentioned don't give you. You can't decide that you want to create an object in Scala or Kotlin that is contiguous in memory. You can't decide you'd rather not have GC pauses in Go. In many ways, Swift brought together the kind of niceties that have been available before. Generics aren't something new, value types aren't new, objects aren't new, first-class functions aren't new, ARC isn't new, non-nullable variables aren't new, closures aren't new, type inference isn't new. . . But none of those languages have all of those. Go took a hard stance against generics (I'm not going to go into why). The JVM doesn't really do value types. GC has been the standard for most new languages for a while. Swift definitely offers new things.

pjmlp 10y ago
> While the JVM's GC is decent, it can definitely cause latency spikes. Which one? Java is like C and C++, there are plenty of JDKs to chose from, each it is own set of implementation behaviors, for the different types of customer pocket sizes.
premium-concern 10y ago
Scala has value types, and on native all the current restrictions from the JVM are dropped. Additionally, you can also explicitly allocate things on the stack. You can also allocate continuous memory.

Someone 10y ago

For IBM, part of the lure probably is "the enemy of my enemy is my friend". It's not running on a VM that Oracle or Microsoft control, and not a language Google controls. Yes, it is Apple's language, but IBM apparently thinks it will become more popular than one they would control on their own, and picking Apple's language then is, for them, the least risky, as Apple isn't a company focusing on servers.

pducks32 10y ago
Other than Swift being a great language this is certainly at the top of the list. If not on a management level then on a developer POV level. Plus in some way they associate Apple with themselves, they become (in some weird way) the Apple of enterprise.