
Swift open source – let the revolution begin - tambourine_man
http://www.jessesquires.com/swift-open-source/
======
mikeash
The open source release has been pretty amazing so far, and I believe it's
without precedent in Apple's history (with the possible exception of
ResearchKit).

I was afraid they would just toss a snapshot over the wall and leave the
community to struggle with maintaining it (if anyone cared to). At best, I
thought we might get some regular snapshots and discussion.

Instead, everything is out in the open, the team at Apple is apparently
pushing to the same repository we get to see, they have an open bug tracker,
they're actively soliciting and discussing proposals from the community,
accepting patches from the community, etc.

This is business as usual for most open source projects, of course, but to see
it coming from Apple blows my mind a bit. It's really great to see.

~~~
panic
There is some precedent at Apple: WebKit is also developed in the open.

~~~
bsimpson
Didn't it have to be because of KHTML?

~~~
panic
No, originally Apple just provided huge patch sets. Here is some history from
2005, a few months before WebKit moved to a public CVS repo:
[https://blogs.kde.org/2005/05/13/webcore-khtml-firefox-
know-...](https://blogs.kde.org/2005/05/13/webcore-khtml-firefox-know-your-
facts)

~~~
mikeash
Good example! And yes, KHTML's license requires Apple to release the source
code for their changes, but it doesn't require them to do so in anything like
a nice fashion. You can comply with the (L)GPL with tarballs and silence-
implying-raised-middle-fingers rather than public repositories and bug
trackers.

~~~
tzs
It goes even farther than that. They could have separated most of their work
out into separate modules that linked with the LGPL code from KHTML, and all
they would have to do to comply with LGPL is provide a way for the user to
replace the LGPL code. They would not have had to release the source for their
modules.

LGPL is quite friendly to proprietary code.

~~~
rsynnott
> They could have separated most of their work out into separate modules that
> linked with the LGPL code from KHTML, and all they would have to do to
> comply with LGPL is provide a way for the user to replace the LGPL code.

And indeed, they _do_ do this, I think; a lot of WebKit is BSD license.

------
andreasley
Excellent summary.

I'm really happy that Apple open-sourced Swift in this way. However, most of
the ~400 pull requests are fixes for single typos. I hope that managing the
GitHub issues won't become too much of a burden for the main developers (those
with write access to the repository).

~~~
shurcooL
It's not a very hard problem to solve though. Just fix the typos, and don't
introduce (many) new ones.

The people contributing those fixes are doing so because they want to
contribute, and typo fixes are very easy to be certain about that it's an
improvement (without a chance of introducing regressions, etc.).

Of course, as the easy-to-fix problems are eliminated, focus will shift to
finding more meaningful ways to make improvements, or just using the language
which has fewer problems as a result.

~~~
elwell
Yeah, it's _looks good_ on your GitHub profile to be a 'contributor' to Swift.

~~~
edgyswingset
This brings up an interesting problem to solve:

How to tell if something is a "real" contributor rather than someone who sends
the occasional spelling fix. I imagine recruiters would be interested in some
way to easily tell this.

~~~
TheDrizzle43
All they have to do is ask them in the phone screen "So what did you
contribute to Swift?"

~~~
dvcrn
"I analysed the swift codebase for character sequence problems and actively
contributed in reducing these. My contributions were responsible for
eliminating hundreds of possible issue reports to the project."

------
misiti3780
I'm excited about Swift but is there any reason someone who is not making
money as an iOS dev but knows objective C well should drop everything in learn
it (serious question)?

My initial opinion was swift does a lot of things much better, (no header
files, new operators, etc.) but learning a new language takes a long time + it
appears a majority of code is still in objC

~~~
tedkalaw
sometime in the future, Apple will begin releasing swift-only APIs. it's
unclear that one should "drop everything", but swift usage will only increase
in the future. in addition, as a company, it will become difficult to hire new
people if you don't try to move to swift at some point.

ymmv, of course. i'm new to iOS land and i write objective-c exclusively
during my day job. that being said, the difficulty in iOS development (in my
experience) is not in the language, but the APIs, abstractions, and patterns -
and they are the same regardless of whether you're using swift or objective-c

~~~
HaloZero
I mean sometime in the future will probably be pretty far away for Obj-C
developers.

“Objective-C is not going away. We still love Objective-C as a language; we
still very much depend on Objective-C and do a tremendous amount of work in
Objective-C here internally at Apple,” Federighi told Ars. “We’ll be
supporting Objective-C and continuing to evolve it as necessary to fit into
this evolving world. We do think that Swift is the language that we recommend
for new developers to our platform who are investing for the future and
building new apps. We think Swift is absolutely the right place to start. But
we’ll continue to maintain, advance, and support Objective-C for as far as we
can see.”

From [http://arstechnica.com/apple/2015/12/craig-federighi-
talks-o...](http://arstechnica.com/apple/2015/12/craig-federighi-talks-open-
source-swift-and-whats-coming-in-version-3-0/)

------
rw2
Swift is a good language, but compared to things like Python, the syntax is
still not as clean and intuitive.

It's definitely a much better improvement of Obj C and I would have never
built 3 apps in the app store without it, but I don't see it going out of the
iOS dev environment anytime soon.

~~~
jeremy_wiebe
I'm not sure that this is completely the same, but when node.js was introduced
it provided a server-side programming language that a ton of web developers
were familiar with.

Swift is doing something similar now that it's open source there is a huge
community of iOS (and to a smaller extent Mac) developers who are excited that
they can code on other platforms (or will be able to in the near future) using
a language they already know and love.

~~~
bsimpson
Honest question: how common are non-GUI Objective-C apps? So far as I know,
Objective-C has been available outside of Cocoa for a long time, but you never
hear of people using it for non-Mac/iOS apps.

Is Swift different in this regard? Is more of the standard library open in
Swift vs. in Obj-C? Any reason to expect it's non-Apple uptake will be better
than Obj-C?

~~~
ElvishJerricco
Objective C was poorly supported outside of the Apple ecosystem. Plus
Objective C as a language hasn't been all that preferable to most developers.
There was basically no reason to use Objective C at all outside of iOS and Mac
development.

Swift, on the other hand, will now have full Apple support on Linux, and is a
much nicer, and potentially more useful language. I think that with some
effort on the community's part, it could become a serious contender for server
side development.

~~~
eropple
I tend to agree. I've been using Swift off and on pretty much since its
inception, and I like it well enough that I'd consider it for server-side
stuff once the ecosystem's worth anything. My hope is that it brings a little
sanity to things by presenting a sufficiently trendy alternative to Golang so
I can deal with that a little less often (but that's only hoping).

------
Thiz
I wish I could use the Swift compiler from the command line instead of having
to download a 10GB XCode monster over my shitty 14kb modem that will take a
couple of years.

Is there a swifter option?

~~~
azm1
14kb ? Are you still on 14.4k from 1991 ?

~~~
Thiz
Well yes, I live in Venezuela.

Thank socialism for that.

------
johnthomas14
I love Swift, it's a great tool.

------
zanny
It seems to be the same effect as people getting Macbooks because... they have
an Apple logo on them.

Technically, either Rust, Python, or Go is superior to Swift in every usecase
it has. It doesn't fill a niche, its just Apple would rather reinvent the book
than use an alternative on iOS, and they wanted clean compatibility with their
other NIH language Obj-C. Its a nice compromise language for applications, but
it is currently an app language without a framework outside Apple operating
systems.

Besides that ecosystem compatibility its just worse than the alternatives
besides the whole Apple is behind it so everyone is developing in it because
they dream of working at / for / with Apple for some reason. Are Mozilla,
Google, and and Guido just not sexy enough anymore?

~~~
rsynnott
> Technically, either Rust, Python, or Go is superior to Swift in every
> usecase it has.

How so, exactly? The only one on that list I'd say maybe to is Rust.

~~~
bsaul
Swift as a language may not be superior to go in itself ( quite the opposite
imho), but the fact that go chose a specific type of concurrent programming
and built their language around it makes it more straightforward.

With swift, designers chose not to choose. Which means you'll resort to using
libraries ( basic threads with gcd or C libraries such as libmill, or libuv),
which means future incompatibilities between codebases that chose different
models.

~~~
stevetrewick
No. GCD is not 'basic threads', GCD is a concurrency model based on executing
blocks (closures) on queues. Threads are abstracted away by GCD.
NSOperationQueue abstracts even further to provide a higher level concurrency
model. Or you can go down the stack to NSThread to actually get your 'basic
threads'.

The programmer gets to choose the level of abstraction appropriate to the task
in hand.

~~~
bsaul
let's say gcd is still much lower level than channels+select or asyncio+single
run loop or actors+shared nothing.

At the minimum, i would say it's much more flexible but also much less
opinionated.

