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?
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.
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..
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.
RC does otherwise have very bad interactions with threads of course.
edit: clarify
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.
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).
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.
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.
You can always use AppCode if you don't like Xcode.
On my computer, recent versions of AppCode constantly use at least 100% CPU, even when it's in the background doing nothing. I got this a few times in earlier versions as well, but an "Invalidate caches and restart" usually fixed the problem. No such luck with recent versions. It will always use at least 100% when it's running.
I often get 30 seconds of beachball when I switch back to AppCode from some other app, despite having 16GB of RAM and not running any other remotely heavy app. This will happen even if I just leave AppCode for half a minute in order to check something on a web page. It's gotten so bad that I've developed the habit of checking web pages on my iPad instead of on my Mac, in order to avoid temporarily leaving AppCode.
There is a particularly infuriating bug that will sometimes cause AppCode to freeze when I type the opening parenthesis of a function invocation. When this happens, killing, restarting and typing again won't work, AppCode will freeze at the same spot. The only workaround I have found when this happens is to type my function invocation in some other editor and copy and paste to AppCode (often after waiting the usual 30 seconds for AppCode to stop beachballing).
It is not just me – all my coworkers suffer from the same problems. AppCode is by far the most annoying app I use on a daily basis. I hate it nearly – but not quite – as much as Xcode.
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-...)
You can also get it today with any commercial JDK like Excelsior JET.
Also, see the top comment here: 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...
(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)
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.
Not sure about Kotlin (stable version of the language was only recently released; more likely a stable JS target is higher on the priority list), but Scala Native isn't production ready, will likely be at least a year from now; same goes for Scala Meta, and Dotty's even further out, minimum 2 years away.
Swift has a head start here, and a huge captive audience in legions of iOS developers -- unlikely that Scala will be able to compete on the native front directly. More likely Scala.js + React Native may draw some from the JS developer pool that want to take advantage of static types and seamless client-server interop that can be had via Scala/Scala.js today.
In fact, it appears that a Kotlin Native project exists in the sense that a blog post exists that announced a native target is something they're looking into implementing down the road -- hardly a project ;-) Scala Native's been under heavy development for over a year now[1], and even then it's a long way off.
[1] https://github.com/scala-native/scala-native/graphs/contribu...
Features don't matter much I'm afraid.
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.
That's what they said about front-end web developers and now we have nodeJS.
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.
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.
Additionally, you can also explicitly allocate things on the stack.
You can also allocate continuous memory.
Compared to Go it's a whole other level of interesting...
Think of Highway 50 (NV) vs Highway 1 (CA).
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.