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