
Whither Swift? - tambourine_man
http://lapcatsoftware.com/articles/whither-swift.html
======
stupidcar
This article is the best example I've ever seen of how smart people can
convince themselves of anything, no matter how absurd, if they want to believe
it enough.

The author likes Objective C and doesn't like Swift. That's fine. But he's let
that emotional state override his rationality to the point that it totally
colors and distorts his thinking.

None of his arguments hold together. They're all speculation based on
supposition based on guesswork, and all under-laid by an almost desperate
desire that this fantasy will come true, and that Apple will drop Swift. It's
like listening to a broken-hearted man explain how his ex-lover will soon
return to him. How this is a test that only make their love stronger in the
end, etc.

Apple aren't going to drop Swift. It is the future of iOS and macOS
development, and the sooner the author accepts that and moves on with his
life, the better.

~~~
bluejekyll
I read the entire thing, and didn't get the impression you got. This arricle
is pointing out two clear issues for Swift that need to be overcome. 1) that
the default language to have the broadest support is obj-c; I see a lot of
companies preferring to ship obj-c when they need to support a framework for
both obj-c and Swift. 2) Apple needs to more fully commit to replacing code
internally with Swift, by say making the decision to stop building new feature
support into obj-c and only target Swift.

This is more of a project management issue. It will be interesting to see what
Apple ends up doing, but I agree with the article that long term support of
both is not in Apple's best interests. Though my money is on Swift...

~~~
simonh
Why are either of those problems?

1) If some developers still prefer to develop in Obj-C, good for them. Of
course Obj-C still has the broadest support, Swift is still in the process of
taking it's training wheels off.

2) Why should Apple want to replace any of their Obj-C code? If it's good code
and works well and a lot of other code depends on it, replacing it just for
the sake of it would be pointless.

Partly all this depends on what you consider to be long term. Swift is coming
to 3 years old. To my mind 5 years hence is the immediate future. Long term is
like 20 years plus.

~~~
rdsnsca
Apple has totally rewrote the dock , in macOS Sierra in Swift.

~~~
simonh
And presumably they had a reason for wanting to do so other than Swift Rulz.

What I'm arguing against is not the idea that new code or new versions of
things shouldn't be in Swift. Maybe they should, maybe they would be better in
Obj-C on a case by case basis. I'm arguing against the idea that all the
existing Obj-C code is an embarrassing legacy that must be purged as a matter
of urgency or else we should all start panicking about it.

Heck, large scads of the OS and the application services frameworks are
written in plain old C - HealthKit is plain C. Long may that continue. Same
for Obj-C.

~~~
rdsnsca
There is a thread on the old Apple Swift forum that addresses why they like
Swift. Its an old post from 2014 called : Why Swift? And why now?. You will
need at least a free developer account to be able to log in and see it.

[https://devforums.apple.com/message/986257#986257](https://devforums.apple.com/message/986257#986257)

"13 of the security issues fixed in 10.9.4 could have been prevented or
mitigated by Swift (9 buffer overruns, 2 int under/overflows, 2 null derefs).
That alone makes it worth it from my point of view.

As for performance, that's a work in progress but is improving rapidly; Swift
is already faster than ObjC in some cases."

------
fauigerzigerk
He's missing a crucial piece of evidence. Apple has done a lot of work to make
sure that Swift and Objective-C can coexist in same project. You can call
Swift code from Objective-C and Objective-C code from Swift with little fuss.
This is completely unlike Microsoft's C++/.NET situation.

If you look at the source code of the Swift standard library, "toll free"
bridging code is everywhere. It even affects the language design of both Swift
and Objective-C.

Yes there are still inefficiencies, but they are small. Apple has done
everything humanly possible to make this interface efficient, seamless and
sustainable.

So I think the plan is very clear: Don't force people (including Apple itself)
to rewrite old code. Make it possible and desirable to add new features to old
Objective-C projects in Swift. Maybe let Objective-C die of old age at some
point in the very distant future.

There is a ton of evidence that they are in this dual mode for the long haul.

I think the one flaw in their strategy is that people who like Swift will
start to hate the antiquated object oriented design of Cocoa and some lower
level OS services.

My prediction is that more and more of Cocoa will be wrapped with idiomatic
Swift code that Objective-C devs will not want to adopt. At that point, there
will effectively be two competing system APIs.

The pressure to make a clean break with Cocoa will grow because some un-
idiomatic parts of Cocoa will be hard to wrap and people will call for a
modern replacement for Cocoa long before Objective-C is gone.

So I think, most of the friction in this transition will arise on the library
side, not with the languages themselves.

~~~
iainmerrick
I agree with you, but just to play devil's advocate, don't forget that Apple
spent a lot of time and effort on toll-free bridging between Objective-C and
Java back in the day.

Java was close to a first-class citizen on OS X and could even have eventually
supplanted Obj-C (despite lacking some key features). Then Apple decided they
didn't like Java any more, and running Java on OS X has been increasingly
painful ever since.

I don't mean Swift would be ditched, if an analogous situation arose; rather,
Apple could very easily decide to axe Obj-C if they don't feel like supporting
it any more. They don't care at all about sunk costs (correctly, in most
cases).

~~~
fauigerzigerk
Toll-free bridging between a runtime that uses a tracing GC and one that
doesn't share that exact same tracing GC is impossible. It's just a desperate
stop gap.

Of course Apple could theoretically ditch Swift or Objective-C or replace both
something else. But there is zero indication of any such intention.

~~~
iainmerrick
Yeah, the point I was trying to make is just that Apple could easily decide to
ditch Objective-C in the relatively near future.

From our point of view as developers, there are good reasons not to, like
maintaining backwards compatibility and keeping developers happy, but Apple
generally seems to ignore those issues. Not that they actually want developers
to be unhappy, they just expect and require them to fall in line.

(Or they could ditch Swift too and go with something entirely new and crazy,
but that seems too unlikely even for me)

 _Edit to clarify:_ I think what they _do_ care about is technical issues, and
giving themselves the tools to make the slick products they want to make. And
their technical strategy is generally pretty sound -- look at their balanced
CPU+GPU designs on iOS, for example, both faster and more power-efficient than
the ludicrous octo-cores and oversized screens you get on "flagship" Android
devices.

To me, making Swift and Objective-C interoperable was a smart decision to give
themselves (and coincidentally their developers) a smooth migration path. They
also think that reference-counting is _better_ than tracing GC for the types
of applications they care about (and I think they're correct). But nothing in
that says they care about keeping Objective-C around indefinitely.

------
WayneBro
The author says "Objective-C and Swift cannot continue to coexist
indefinitely." but their only supporting argument is that a multi-lingual
platform is bad because nobody will know what language to choose.

This is the same charge that has been leveled against Microsoft since they
don't use .NET to produce every single piece of Microsoft software. Has that
somehow stopped .NET from continuing to grow? No, it has not.

Off-topic: Learned a new word reading this. Lacuna ~ _an unfilled space or
interval; a gap._ Thanks!

~~~
paulddraper
Or JVM...

Java, Groovy, Scala, Closure

Will they exist "indefinitely"? Well, all language have a lifetime, but these
will/have coexisted for decades.

~~~
icpmacdo
Quick spelling correction I think you mean Clojure. You got me searching for a
new programming language that has a namespace conflict with a programming
concept :) .

~~~
johnny22
it's also a way to minify js
[https://developers.google.com/closure/compiler/](https://developers.google.com/closure/compiler/)

------
jamesk_au
Chris Lattner talked about some of these issues on the Accidental Tech Podcast
a few weeks ago: [http://atp.fm/205-chris-lattner-interview-
transcript/](http://atp.fm/205-chris-lattner-interview-transcript/)

It was a great episode and is worth the listen for those interested.

On Swift adoption at Apple:

 _" The Swift team itself has specific goals they need to achieve before there
can be truly, across-the-board adoption at Apple. ABI stability is the number-
one thing [35:30] that prevents framework developers, for example, from
adopting Swift. That's a really important thing. That's one of the reasons
it's always a really high priority. Swift has been adopted by application
developers and other things. The Dock is public. Swift Playgrounds app is
public. The Music app in iOS is publicly known. So there are definitely some
big adopters.

More broadly though, the big problem is that I think, I won't speak for
everybody but many, many people doing [36:00] Objective-C development at Apple
are chomping at the bit. They want to be using Swift. It's really just a
matter of getting the technology problems solved and checking off the things
that are holding people back. It's not about people dragging their feet and
not wanting to use it."_

On whether to adopt Swift now:

 _" I don't [1:14:30] think Objective-C is going to go away anytime soon.
Apple still supports C and C++ and there's no obvious benefit of dropping
Objective-C, and obviously they have a ton of Objective-C code themselves."_

He also described Apple's approach to some of the strategic questions that
arose early on, such as whether to just invest in making Objective-C better
instead of introducing Swift, and the various trade-offs involved.

------
JamilD
> Apple could convert its entire Objective-C code base to Swift if they
> wanted. They certainly have the resources. The amount of liquid assets they
> own is staggering, of a size unprecedented in history. Nevertheless, their
> current corporate culture suggests they cannot or will not perform this
> conversion.

But _why_? This would be an incredible waste of time and resources, to rewrite
perfectly functional and working code. Rewrite it when you need to. Bloomberg
still has 25m lines of FORTRAN [0] — there's no need to rewrite code when it
works fine already.

[0] [https://etrading.wordpress.com/2006/06/01/25-million-
lines-o...](https://etrading.wordpress.com/2006/06/01/25-million-lines-of-
fortran/)

~~~
bangonkeyboard
_> But why? This would be an incredible waste of time and resources, to
rewrite perfectly functional and working code. Rewrite it when you need to._

The functional mDNSResponder was rewritten and replaced with discoveryd,
causing networking issues for millions of users. The popular Final Cut Pro was
rewritten with FCPX, shedding many of its features and most of its userbase.
The powerful and flexible QuickTime application and framework were rewritten
and replaced with QTX, losing almost all of their functionality in the
process. syslog(1) was deprecated and replaced with log(1), a more verbose and
difficult to use tool, for no discernible reason.

Throwing away working code and rewriting it, of late most often for the worse,
is something of a habit at Apple.

~~~
astrange
> syslog(1) was deprecated and replaced with log(1), a more verbose and
> difficult to use tool, for no discernible reason.

The new log store contains (or tries to) every old file in /var/log and every
log-level flag in the system, so you can search them all in one timeline. It
also improves privacy because all the %@ formats can be censored after a short
time.

------
melling
His whole argument is that if Apple had to pick one language today, it would
be Objective C because internally they have largely stuck with Objective C up
to now.

Well, Apple isn't going to pick one language today. They might deprecate
Objective C in 5 or 10 years, but in the near term nothing should change.
They're infamous for dropping "legacy" so I wouldn't rule out Objective C
having a finite lifespan.

The author is right that the developer community has really embraced Swift. It
is a much nicer language, with a lot less visual noise, for example.

As a quick aside, I've been working on a Cookbook for the Swift:

[http://www.h4labs.com/dev/ios/swift_cookbook.html](http://www.h4labs.com/dev/ios/swift_cookbook.html)

And I've been adding to a Github repo with lots of little examples:

[https://github.com/melling/ios_topics/blob/master/README.org](https://github.com/melling/ios_topics/blob/master/README.org)

Finally, the Stanford CS193 course has start for Swift and iOS 10:

[https://itunes.apple.com/us/course/developing-ios-10-apps-
sw...](https://itunes.apple.com/us/course/developing-ios-10-apps-
swift/id1198467120)

------
mahyarm
Apple uses many languages internally. And swift & objective-c are very close
in programming models in many ways. It's pretty natural for an ObjC dev to
learn swift and vice versa I would imagine. If apple is having a hard time
find new objective-c dev, but has swift devs, it will just train them.

A lot of code is in C++ at apple, like most of their graphics, UX &
networking. Drivers in C. A lot of apps are non-ARC objective-C still and so
on.

Also swift is not a solid enough language yet. Debuggers, compiling & indexing
are too slow & unstable and there are things like ABI stability that are not
delivered yet. I would give swift ~4+ years before it would be something to
consider replacing Objective-C completely.

------
wmil
Microsoft has managed to keep VB and C# alive and well supported even though
its major codebases are in C++.

I don't think it's as big of a problem as the author seem to think it is.

~~~
pjmlp
Actually even though C++ has first class support on UWP, I have noticed that
the language focus at Microsoft developer presentations is showing it more for
lower layers of the OS and games, with C# and VB being targeted for apps
development, with F# getting the data science part.

~~~
nickpeterson
F# isn't really aimed at data science, thats a common misconception ( I
believe MS has ceased describing it that way). It's basically just a general
purpose, functionally oriented language.

~~~
pjmlp
When they finally support it the same way as VB and C#, including the GUI
tools, UWP, and some of the MSDN documentation about .NET, and above all when
the F# community stops doing presentations about type providers as the single
killer feature, then it will be a general purpose, functionally oriented
language.

Currently I cannot use F# on UWP until .NET Core 2.0 gets released, cannot use
the same workflows with Blend and Visual Studio as I do for C#, and while type
providers are cool, I have zero uses for them.

~~~
nickpeterson
Yeah, I have no arguments here. If you're goal is a friction-less integration
with Microsoft tooling and projects, F# is not the way to go (definitely C#).
F# practitioners would do better to position themselves as just a language in
it's own right, not necessarily an 'alternative to C#'.

Sort of like Elixir compared to Erlang.

------
mikek
I think the plan has always been that Swift is the future, but Objective C
will be around for a long time. Think a 30-year horizon.

~~~
Humdeee
I would agree with this. I'm imagining Obj-C to eventually be Apple's COBOL.
Even presently, a lot more job postings regarding iOS development are
expecting Swift experience than even a year ago.

------
jupp0r
The piece is really well written and makes some good points (especially about
Apples code base, the costs of rewrites, etc.)

I'm still perplexed by the argument that there are boxes like "Objective-C
programmer" or "C++ programmer" and that this categorization is a good
abstraction for thinking about these problems. In earnest, nobody working as a
developer can expect to use the same tools in 5-10 years that they are using
today, especially in fields like mobile.

It's not that hard to learn a new programming language if the paradigms are
known from another language. Swift is not that different from other imperative
languages that there would be a particularly bad learning curve.

------
iainmerrick
This is nothing but inconclusive speculation. It mostly focuses on whether and
when Obj-C will be retired, so the title should really be "whither
Objective-C?"

------
georgeecollins
What I dislike about this situation is that Apple wants me to make software
that only works, or works best, on their device. I want to make software that
is as portable as possible. I don't want my next programming language to come
from someone who wants to lock me in. This makes me uncomfortable with Swift.

~~~
toyg
Like Objective-C is a realistic choice anywhere but on OSX...

If you play with Apple, you can only ask how high you have to jump. They will
certainly not help you write cross-platform code, if they can avoid it. They
practice lock-in very aggressively at all levels.

~~~
valleyer
Yeah, it really was sneaky of Apple to convince NeXT to write their
development framework in Objective-C a decade before they acquired them.

~~~
pjmlp
NeXT had a portable version of NeXTStep for Solaris and Windows, called
OpenStep.

------
lupinglade
First off, I was always a huge obj-c fan, but I can tell you from first hand
development of what is most certainly the largest and most complex pure Swift
source tree that Swift has many serious advantages over obj-c. I am convinced
we could not have such a stable product so quickly without it. It has
immensely improved productivity. It has some shortcomings still and sometimes
you do miss obj-c's dynamic dispatch, but on the whole Swift is far more than
an evolution. I think Apple is definitely on the right track and you will see
obj-c getting deprecated within the next 5 years or so. As others have
mentioned, ABI stability is the number one issue preventing Apple from
rewriting frameworks in Swift.

~~~
krzat
How can our apps be stable when compiler is not stable.

------
frankus
As far as I know all of Apple's framework code is in Objective-C, and there
are two big problems standing in the way of converting it to Swift: AppKit and
the like still has to support 32-bit apps (and it's apparently challenging to
back-port that support to Swift) and Swift doesn't yet have ABI stability.
(source: the SWIFT ADOPTION AT APPLE section here: [http://atp.fm/205-chris-
lattner-interview-transcript/](http://atp.fm/205-chris-lattner-interview-
transcript/))

~~~
leonatan
There are a lot more challenges than just ABI and 32 bit. Swift is not
dynamic, lacks many of the features the ObjC runtime provides - so most of
Apple's frameworks cannot actually be implemented in the same way with Swift.
Basic stuff like KVC, KVO, responder chain, etc. go out of the window. And
many of Apple engineers are not convinced throwing these technologies out of
the window for some imaginary benefit from Swift is the right direction.

------
delinka
This author has also forgotten about the annotations that Apple has provided
to make interoperability between Swift and Objective-C quite a bit easier. See
"Swift API Design Guidelines" from WWDC 2016.

Moving on ... "If Apple had to deprecate one of the two languages today, which
would they deprecate?" Why is that even a question? I don't understand the
motivation here. What if Apple had to decide between mobile hardware and
desktop hardware? I guess they'd drop everything that wasn't the biggest
revenue generator...

~~~
simonh
Well exactly. Apple is opening a lot of stores in China with employees all
speaking Chinese. Were all told 'China is the future'. Suppose Apple decided
to standardise on one language for all their store. What would it be, English
or Chinese? Equally daft.

If we take this perfectly sensible option, for which there is no obstacle to
Apple pursuing it and which is Apple's stated intent off the table, which of
these remaining bone headed options do you think Apple will choose? Er, who
cares?

------
coldtea
>* If 2 was the plan, I really wish Apple had been more forthcoming about it.
The message from Lattner would have been misleading at best. If Swift is the
future, why not be absolutely clear with developers about that, and let us
plan accordingly*

Because it's nowhere near a short or even mid term thing? It will take a
decade or more to be able to move to Swift 100%, and even then, it will came
with ample warnings years ahead to port your Obj-C code over.

------
adamnemecek
> And of course Lattner has now left Apple, so he won't be there to take the
> criticism if his claim turns out to be false.

IIRC he said that he's going to still be on the core team of the language. I
don't remember the email (and I can't find it right now) but I had the
impression that for me, as a user, very little actually changed.

~~~
antfarm
"This decision wasn't made lightly, and I want you all to know that I’m still
completely committed to Swift. I plan to remain an active member of the Swift
Core Team, as well as a contributor to the swift-evolution mailing list."

[https://lists.swift.org/pipermail/swift-evolution/Week-of-
Mo...](https://lists.swift.org/pipermail/swift-evolution/Week-of-
Mon-20170109/030063.html)

------
huangc10
It's in Apple's best interest to continue supporting both. Why? Let's just
remove the POV of app developers and simply look inside Apple.

The article mentioned a very important point. Apple itself has not adopted
Swift as fast as the developer community. This is because (I don't know this
for a fact, but am quite sure), a large portion of hw/sw engineers know how to
write C, C++, and Obj-C. They don't just know how to write it, I bet a lot of
them are damn good at it and if not, top in the industry. Why convert? As many
mentioned in the comments, it would be a huge overhaul and what about Apple's
internal engineers? Would they put themselves out of a job?...Not likely.

Maybe in 20 years (if there still is an Apple...), there will mostly be Swift
engineers. I just don't see them shooting themselves in the foot by removing
obj-c in the near future (as in 5-10 yrs).

------
kirb
This is a bad argument. Just because there’s a lot of chatter about Swift,
doesn’t mean there’s more Swift code than ObjC out there. Of the 31 apps I
have installed on my jailbroken phone, 9 contain libswift libraries. Of
course, that doesn’t even mean the entire apps are written in Swift; most of
the uses I see are for app extensions probably because they’re a more recent
addition. Worse on my Mac – 7 out of 94 non-Apple apps installed.

You don’t throw away good code just because “eh, I like Swift better”.
Couldn’t imagine having to justify rewriting good code to my employer. If it
works, you keep shipping it till it breaks, then when it does break you spend
a while fixing it and continue shipping it. Only when that becomes unviable do
you consider rewriting it, and depending on the developer/project situation
that may very well be in Swift.

Microsoft fell into the trap of rewriting good code with the failed Windows
Longhorn project – for what was meant to be a minor release, they burned a
heap of time rewriting large portions of Explorer (taskbar, start menu, folder
windows) in C#. Explorer in all beta releases since the rewrite began were
very unstable. They scrapped it and kept the existing C++ codebase. Fast
forward now, Explorer still runs great in Windows 10 with the same C++ code,
right? See also the Joel on Software article everyone usually links when this
topic comes up: [https://www.joelonsoftware.com/2000/04/06/things-you-
should-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-
do-part-i/)

Music, Calculator, and a minor part of the new Messages app were rewritten in
Swift in iOS 10. Dock was supposedly rewritten in Swift in macOS Sierra, ditto
Notification Center. Plenty of Touch Bar code is Swift. I think the fact that
they’ve _started_ to use Swift with new non-framework code is pretty
important. But I’m certain there will still be ObjC in service for way longer
than Apple removes its last line of it from the codebase. It can’t just be
phased out like Rosetta or Carbon, especially when 3rd party apps are what
keep iPhone sales up.

------
cxromos
Eventually most of the open source libraries will be Swift based, therein lies
the answer, for the developers and for Apple. Apple doesn't need to drop
Objective-C, the community will. I work with both, and like them both,
although Swift is far better language.

------
tolmasky
First off, this is very well written. Secondly, I'd like to state that I think
that Objective-C and Cocoa were _really_ good. I disagree with most of the
design paradigms _today_ , but I think the Objective-C/Cocoa ecosystem
represented something approaching a local maxima in the mutable programming
space. Maybe not even a maxima, as I was actually really happy with the
direction it was going pre-Swift (KVO was starting to get good in NSTreeNode,
the language additions were welcome, etc.)

All this to say: I think the Swift transition was really misguided, and I was
incredibly surprised that that wasn't the general take at the time. Everything
about it seemed not well-planned out: the fact that no one at Apple had heard
of it (you have the world's best ObjC programmers in-house and don't bother to
get internal buy-in first!), the fact that it was really a response to C++ not
Objective-C (this is so clear when listening to Lattner, who incidentally, did
most his programming in C++ it seems), the fact that they sold it as good for
everything from scripting to systems programming (huge red flag), and on and
on.

But the real concern here was the opportunity cost. What was the problem they
were trying to solve with Swift? That square brackets were off-putting? That a
group that until that point were totally bought into dynamic dispatch should
switch gears completely to a strict typed language? If you ask me, the only
goal that _should_ have mattered was making _development_ easier and expanding
the scope of people that could approach the platform. And, for the record, I
am sure they believe they attacked this problem, I clearly disagree however.

I think the real areas ripe for improvement were the tools. Look no further
than Facebook, with React Native and the no-recompile workflows where you
change the UI and see it instantly on your device. _This_ would have been game
changers in making development easier, not adding Maybes (and this is coming
from someone who does immutable development now). Objective-C could have been
_evolved_ into the language they wanted. It would have probably taken just as
long as however long this "transition" is going to take, and it would have
given everyone immediate actionable benefits instead of being a binary switch
that comes along with the pain of having to ship the runtime.

Instead, we have discussions about whether _Foundation_ is going to be
rewritten in Swift. This seems like such an incredible misprioritization.
Essentially creating a situation for yourself where you _have to_ burn
everything down and start from scratch, all while in the meanwhile have the
head-scratching platform where the base libraries are written in a dynamic
language and user land code is a strict systems language.

The last thing I'll mention is the worrying lack of "purpose" for Swift. Talk
to a Rust guy, and he WILL tell you the reason to use Rust. Talk to a Haskell
person and they'll do the same. The sole reason for Swift seems to be "to take
over the world". It is decidedly not a very opinionated language in that
regard. In the ATP interview, Lattner even said that dynamic dispatch may be
added later to Swift so no one should worry about it, it seems like such a
kitchen sink. (I loved the bit where he said that if they add in multiline
string literals they can probably "win" the scripting space). Not a lot of
passion there.

~~~
dep_b
> The last thing I'll mention is the worrying lack of "purpose" for Swift.
> Talk to a Haskell person and they'll do the same.

Really? Real type safety and no null pointer exceptions unless you really want
it are not a purpose? A compact syntax that is still as descriptive as
Objective-C's syntax?

My programs are _much_ more stable in a lot of regards since I started using
Swift.

~~~
tolmasky
I do not believe stability was the problem in iOS land (from my personal _user
perspective_ ). The problems with iOS apps I experience most frequently come
from a lack of handling asynchronous events and state management. I can
frequently get programs into weird states due to clearly not handling edge
cases in the way animations finish, or things loading before something else is
ready, etc. I think attacking asynchronous flow management (the way countless
other languages like JavaScript and Python and C# have with async/await for
example) would have really demonstrated and understanding of the key space
this language was going to be initially used for. Instead, async primitives
are going to be missing for at least another version of the language, and
programmers will remain using very primitive synchronous tools for managing
increasingly complex asynchronous states demanded from ever more animation-
heavy and internet-talking apps. I believe investing in asynchronous language
additions for Objective-C would have lead to much more stability from a user
perspective. And they aren't even mutually exclusive, Objective-C was already
moving in the direction of more type safety and could have continued down that
path.

Separately, I think people that have used languages like elm or Haskell would
argue that Swift does not present a particularly strong example of "real type
safety". Both from a language perspective (yes certainly stricter than some
languages, but not as strong as others), but also from a culture perspective.
Haskell/elm people I think have a true culture of correctness in code (and
arguably Rust as well from the type-for-ownership-safety perspective), which
Swift does not particularly share as far as I can tell. Don't get me wrong, it
is in fact "stronger" than Objective-C, but I don't think its the slam dunk
go-to language for mission critical software, or guaranteed to be safe
software either mind you. Again, I think an _indicator_ of this is the fact
that the creator is convinced it could rock both systems programming AND
scripting. I think most other languages, if asked the big "why?", would tell
you THE raison d'être for its existence. Aside for "the standard language for
iOS apps" default answer, I don't get a strong sense of that from Swift, if I
did, I think there would be a lot of work in "Swift is for X, we don't want to
be distracted by Y right now" (I think many people want to write server code
in elm, but they staunchly want to NAIL UI programming, Rust wants to NAIL
systems programming with safety, etc.) With Swift its always "oh once we add
this feature, then it'll be perfect for that too".

~~~
mpweiher
> I do not believe stability was the problem in iOS land (from my personal
> user perspective)

This. (And the parent). Almost everything that's an improvement in Swift rated
at best a "nice to have" in my experience with development pain points.

And what's really surprising is that, due to the flexibility of Objective-C,
we actually _had_ some fairly good ideas of where those pain points were: all
the places runtime-dynamicism/metaprogramming was used to "extend" the
language.

So address these points, and better yet, create better metasystems that allow
users of the language to tackle these issues with less hackery.

Instead, pretty much _crickets_ on all of these fronts, and at best grudging
incorporation of minimal bridges to those same hacks. Wut?

Instead a "playground" for the compiler to show how incredibly smart it is.

------
dep_b
Objective-C(++) are not going anywhere. I would start a new project in one of
both languages without hesitation. It works, it's stable, there's tons of
software out there and last but not least it's compatible with Swift.

------
joeld42
I don't see any reason that Obj-C can't stick around for a long, long time,
even if Swift is the "preferred" language.

Also, rumors of first-class support for Swift as a .NET family language are
very interesting and would make the language much more realistic for cross-
platform work. That could even lead to Unity support which would make me sooo
happy. But I'm not the typical use case for sure.

------
solidsnack9000
> The application development environment for C was not Cocoa but rather
> Carbon, and Carbon has been largely deprecated.

This might be the template for the transition from Objective-C to Swift. I
would be interested in the author's thoughts on that -- how is it similar or
different? One could see a situation where Objective-C is still there, like C,
just not of interest to most app developers.

------
makecheck
Conversion to Swift is not something that must be done 100% at once (due to
reuse of the Objective-C back-end), nor is it wise to change quickly (due to
source _and_ binary incompatibilities that have been very clearly documented
for the first few Swift versions). Slow-moving engineering teams, even within
Apple, are just being wise; they can still be firmly behind the move to Swift.

------
haidj
Does Swift support Windows and Linux?

If not, Swift will be doomed to be an Apple-specific language.

~~~
chc
Swift officially supports Linux, and there is unofficial Windows support (and
I remember them saying they planned to support Windows officially, though I
don't know if that's still a goal).

~~~
dwills
The Swift support on Linux is the bare minimum required to say "Swift supports
Linux". I seriously doubt that Swift will ever be any more "portable" than
Objective-C. That is, Swift, like Objective-C, is portable in theory, but
nobody uses it for anything except to write programs for Apple's iOS/macOS
platform.

~~~
thawkins
Ibm has extensive support for swift on linux, and seem to be pushing it as a
first class solutikn for thier linux based develooment.

[https://www.theregister.co.uk/2016/02/23/ibm_releases_kitura...](https://www.theregister.co.uk/2016/02/23/ibm_releases_kitura_a_swift_web_server_framework_for_linux/)

