51–58 of 58 posts
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).
There have been some fantastic pull requests. Examples: https://github.com/apple/swift/pull/253 https://github.com/apple/swift/pull/272
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
You can also comply by sending CDs in the mail. You can require postage and reimbursement for the CD as well.
Earlier quoted context omitted.
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 par…
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.
Earlier quoted context omitted.
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…
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.
At the minimum, i would say it's much more flexible but also much less opinionated.
Earlier quoted context omitted.
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.
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?
14kb ? Are you still on 14.4k from 1991 ?
Thank socialism for that.
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?