Swift open source – let the revolution begin | Hacker News Reader

Swift open source – let the revolution begin

jessesquires.com

161 pointstambourine_man55 comments

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.

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

Didn't it have to be because of KHTML?

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-...

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.

I may be wrong but I have the feeling that KHTML case is a good exception. Apple traditional way of complying with OSS licenses is not that nice (tarball + patches and there you are).

See for example: http://www.opensource.apple.com/release/os-x-1011/

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.

> 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.

You can also comply by sending CDs in the mail. You can require postage and reimbursement for the CD as well.

Good point. Have any companies actually tried this as their open source license compliance strategy?

WebKit was open from the start because they forked KHTML which was licensed under the LGPL.

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).

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.

Yeah, it's looks good on your GitHub profile to be a 'contributor' to Swift.

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.

Is it too much to ask that they actually look at the content of the pull requests?

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

"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."

How is that a problem? If you really want to know the details, they are a single git query away.

My suspicion is that someone who's smart, engaged and motivated enough to have figured out a way to be able to say they're a Swift contributor by fixing typos is probably in the top 10% of candidates anyway.

One solution would be to implement upvotes/downvotes on github pull requests.

good point , but it applied to every open source project too

A contribution for a typo is also a serious contribution

There have been some fantastic pull requests. Examples:

https://github.com/apple/swift/pull/253

https://github.com/apple/swift/pull/272

Exactly: It's important that they don't get lost in the noise.

That's the low-hanging fruit; actually contributing to the language requires an 'in' with the development team, possibly knowledge of C++, and of course knowledge of building programming languages.

Although I've seen that a lot of the basic Swift types are written in Swift, so that would be an area to improve too - that is, if anyone can spot one.

Is there a task list for the project? I don't see an 'issues' page.

Issues are at https://bugs.swift.org

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

Programming in Swift with protocols[1], generics, and value types is so much more productive than Objective-C for me. The amount of reusable code that you can write now is very high - even throwing away what type safety Obj-C can offer and making everything an "id" couldn't do many of the things you can do.

It's not clear from your post if you're trying to make money as an iOS dev but failing, or if you're making money writing for a different platform, but happen to know Obj-C. If the former, you should learn Swift - but you don't need to "drop everything" to do so, it's just a language. If the latter, whatever, doesn't matter either way.

[1] Unlike in Obj-C where they were relegated mostly to delegates/data sources and a few obscure framework classes (remember IKImageBrowserView?), in Swift they're practically the base of the language - almost every type you write should probably be based on a protocol.

Learning a new language doesn't take a long time. If you can program, then picking up a new language is a matter of days especially if it's the same paradigm. If it's something radically different, I can't see why it should take more than a month. The only learning curve to swift would be it's standard library. But in this age of IDEs with auto competition and copious documentation that's not much of a program.

> in this age of IDEs with auto competition and copious documentation that's not much of a program.

I can see you wrote that post in an auto-completing IDE.

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

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...

The beauty of making Swift open source means that changes to the language will be influenced by the broader community. If Apple finds this kind of thing useful, then perhaps the APIs will get the same treatment and we'll start to see an improvement in the iOS dev experience.

It takes a few days to learn enough Swift to start coding in it. Just start adding new Swift methods to your Objective C classes by using extensions

extension MyViewController {

  func fooAction(sender:AnyObject) {

 }

}

You need a bridging header to call back to ObjC

Very few people are blogging or writing books with ObjC. It's mostly Swift, and has been since June 2014:

http://www.h4labs.com/dev/ios/swift.html

Let me put it this way.

At WWDC 2015, the only talks that used Objective-C were related to the new language features. I don't remember any other still using the language.

So you can already see in which direction Apple bis steering the boat.

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.

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.

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?

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.

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).

Coming from some recent experience with Node/JS stuff, it lets you directly re-use some code (namely, data models and code that interfaces directly with them) on both the client and the server. It makes life a lot nicer.

Also, OSX isn't used as a server OS for good reason. Swift on Linux means that you can run that shared code in an environment designed around servers.

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?

It's part of the Command Line Tools, which is about 160 Mb on my computer. If you install Homebrew you should get a prompt to install the tools (or try to run gcc from the command line).

If I'm not mistaken, you can use the installation guidelines on swift.org, and just skip the Xcode related parts. I believe you just need to run the downloadable packages and install them, and they shouldn't require Xcode or anything. Then just add Swift's bin folder to your shell path.

https://swift.org/download/#apple-platforms

Email me your address on mritun@gmail.com and I shall mail you a DVD with whatever you need.

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

Well yes, I live in Venezuela.

Thank socialism for that.

I love Swift, it's a great tool.

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?

Since I expect nothing less than clear, well-informed commentary from Hacker News regulars, I would be very interested in learning exactly what technical aspects make Rust, Python, and Go superior to Swift in each use case, as well as lessons that future PL designers might draw from the Swift team's missteps.

> 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.

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.

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.

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.

Reply on news.ycombinator.com