Hacker News new | past | comments | ask | show | jobs | submit login
Swift is Open Source (swift.org)
1824 points by psuter on Dec 3, 2015 | hide | past | favorite | 432 comments

A lot of folks to thank at Apple right now, can't wait until all of this propagates so we can take a look at what's new in Swift 3. Two thoughts:

- VERY happy to see the open sourcing of much of the Foundation libraries (which includes strings, dates, networking primitives, concurrency/task queues, I/O, etc). It'll provide a very strong start and make working with Swift immediately productive.

- Holy crap, there's a package manager. This has been sorely needed since about day one of Swift development, glad to see that it's been a priority as part of the effort to open source!

It doesn't look like they've opened any of the existing Foundation framework we all know and love and that's written in Objective-C. The swift-corelib-foundation repo contains a bunch of .swift files, and those contain lots of calls to NSUnimplemented().

The Core Foundation stuff (included in swift-corelib-foundation) has been open for a while: http://www.opensource.apple.com/source/CF/

The Foundation stuff is a complete Swift re-implementation of Foundation (fairly impressive goal) and is still in-progress (basic classes like NSArray and NSData look complete but none of NSURLConnection is implemented). They are targeting Swift 3 to have them complete. As the Core Libraries project page says:

"These libraries are part of the work towards the future Swift 3 release. They are not yet ready for production use, and in fact are still in the earliest stages of development"

NSURLConnection is deprecated in iOS 9 so I won't be surprised if they choose not to implement anything that's been deprecated.

> This has been sorely needed since about day one of Swift development, glad to see that it's been a priority as part of the effort to open source!

While not first-party, https://github.com/Carthage/Carthage

Swift's appears to possibly be limited to Swift, so Carthage will still be useful to integrate with Objective-C frameworks.

Well, Swift and C libraries via sysmodules actually.

so we can take a look at what's new in Swift 3

Are new versions backwards compatible?

Historically they haven't been, and the page about planning for Swift 3.0 says it will introduce breaking changes. (It also mentions that Swift 2.2 will be released in the interim and its compiler will try to warn about things that will be broken in 3.0 so you can get your code ready early.)

It's interesting to compare Swift 2 -> 3 to the Python 2 -> 3 upgrade experience. Apple will simply break whatever they need to break to get the improvements they decide would be valuable, move on, and anyone who doesn't follow is likely to be left in the dust.

Frankly, I welcome it after years of feeling like the only Python 3 user on Earth.

For the next few years, I expect Apple will wield a great deal more power over the Swift user community than the Benevolent Dictator For Life has wielded over his supposed minions. I hope we'll get a better language this way, and that these changes won't simply break third-party products to make changes that mostly benefit Apple.

Rich, powerful giant gives power to fork to the little people. Will it be like C#? Like Java? Eventually like Python? Should be interesting....

It's kinda maddening sometimes, I have an app that every time XCode is updated it pretty much has at least one little change that has to be done to get it to build again. It makes me somewhat dread every update.

But, at the same time, they keep users upgrading at the same relentless pace and so you generally don't need to worry about supporting 10 year old versions of the OS.

Cuts both ways I guess!

These circumstances are no where near the same: Swift is a compiled language, and they carefully made the decision to embed all of Swift and its runtime libraries in your application, allowing them to break things without disrupting existing applications and without needing backwards compatibility cruft in their operating system. They also have essentially been actively discouraging people from writing libraries in Swift by pointing out constantly that there is not a stable ABI, so you only see a small handful of things written for it in comparison to Python.

Swift does not have a large userbase for now, and users adopting it are anticipating the breaking changes from beginning. When it stabilizes and developers grow, breaking changes will be less likely.

Swift 3 will be ABI stable, so things will break less - that might not include standard library stability, but Swift projects currently include a copy of the standard library to avoid that.

It's really interesting that they decided to retain the full history! It also gives away some information about the initial contributors and the timeframe of when they started.

I love it. I've never taken a compiler class so going through and reading all the commits since day one is really fascinating. It's easy to see exactly how the language and structure of the code base came to be. Super cool in my book.


Here are some visual aids that better shows how this project has evolved. It also shows how active things are today.


Anyone willing to make a Gource video?


It's cool to see that it was basically all Lattner at the beginning and his decisions about the license/exception still stand.

EDIT: License/Header in each of files were apparently retroactively added.

First page of commits if you'd like to see how the codebase iterated. Find it quite fascinating personally.


Thanks. Actually, first page is 822 for me [0]

[0] https://github.com/apple/swift/commits/master?page=822

Look carefully at that copyright date: 2014-2015. They've rewritten history.

It looks like they used an automated tool to add copyright notices to files in the repository. Probably were required to do that by legal. So it's not 100% faithful history, but close.

This raises some interesting legal questions. If I start a git repo and only add a license in the Nth commit, does that license apply retroactively to a checkout of the first N-1 commits? What if I start out with one license but I change it in the Nth commit? If someone clones the git repo with the Nth commit in it and then checks out an earlier commit, which license applies?

(For simplicity, assume I am the only author of the repo, so I can always change the license arbitrarily whenever I want to.)

"does that license apply retroactively to a checkout of the first N-1 commits"

No, unless you explicitly state it somewhere (and even then, I'm not certain).

If they add a license to the older commits via rewriting history then yes, those older commits will now be licensed. If they don't do so, then copyright will be default i.e. you can't do anything with it.

Now, if they had a large history and didn't retroactively license files, but just pushed the repository out all at once, I have no idea if the license on the latest commit would apply to the older commits. In the end, the question is all about whether or not Apple has the legal ability to sue you for copyright infringement.

Is there any legal precedent for this? It seems like one could make a reasonable legal argument for either interpreting a repo as a single distribution or as a bunch of separate ones.

You can retroactively make a license more open, but you cannot retroactively make it more closed.

If I am the sole owner of a work, I can change the license of newly distributed copies from any previous license to any new license that I want to, even if the new license is more restrictive. The new license doesn't retroactively apply to copies that were distributed under the old license, only new copies distributed under the new license.

However, my original question still stands. If I hack privately on a git repo and never distribute it, and then I only add a license in commit N right before first releasing it publicly, what is the license of commits 1 through N-1, which do not contain a license themselves (or perhaps contain a different license) but were never distributed separately from the license contained in commit N?

Unspecified, so legally murky. But there's a notion of "implied license", so someone using the code could argue that "openly putting it somewhere publicly" constitutes and implicit license grant.

Note by the way that you are ALREADY explicitly granting some rights by putting it on GitHub:

We claim no intellectual property rights over the material you provide to the Service. Your profile and materials uploaded remain yours. However, by setting your pages to be viewed publicly, you agree to allow others to view your Content. By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories.

Arguing that this constitutes an implicit license to use this code probably wouldn't be too hard. However trying to relicense/redistribute is less likely. In the end this will have to be decided by a judge in court.

I'm a law student but not an expert, and I haven't researched the caselaw (yet?). Rcthompson, I apologize for taking this opportunity to go way beyond your question (see below). [This also reflects my assumption that you are coding within the US. And also this is not legal advice, merely hypothetical musing.]

Whatever you write, if copyrightable, automatically achieves copyright protection when fixed in tangible form - and you automatically obtain authorship rights. That gives you the right to grant licenses for any of the rights you've obtained (including to produce derivative works). Swift's license (https://swift.org/LICENSE.txt) allows you to modify the license of your additions (your right under federal law anyway), but not the sections you didn't author.

I mean... I can see it cutting both ways. On its face, it's a very fair system - you can use whatever you want but only own whatever you wrote. What becomes problematic is if companies (realistically) with wide distribution nets grab open-source code, modify it slightly, alter the license of the bundle and resell it. I know that's not a new phenomenon.

Another concern I see is if libraries or maybe files or something have proprietary names, then in theory you'd require an express license from the proprietor (in this case basically Apple).

I was concerned I didn't understand the basic question that prompted my response, which was from rcthompson, but he reframed it: commits 1 to n-1 have sort of Schrodinger's Cat licenses. They have copyright protection (regardless of any of this). And that grants you the right to control licensing of those rights (reproduction, public display, derivative works, etc.). But I don't see why you couldn't retroactively apply whatever you want. The Swift license applies itself, if you don't specify otherwise, upon submission of your work to the licensor (I guess per notice requirements). Until then it's unclear. However, federal copyright protections and state common and statutory laws would also apply (and would basically grant you the right to control licensing).

It depends on how the license was intended to be applied.

If you're the sole owner and declare the entire repository contents under XYZ, the previous commits would be available under the license, regardless of the actual commit that adds the license file. If you declare a specific revision under XYZ, then only that revision is under the license.

A different example is the case of a repository with many copyright holders changing the license, and not being able to drag all the previous code into the newly licensed version. You wouldn't be able to take all the commits in history under the terms of the new license.

That may be true for some open source/free software licenses, but I don't think it is true for all. It would depend on whether or not the license says it is irrevocable and whether or not the license is sub-licensable.

Let's suppose Alice gives Bob a copy of code whose copyright is owned by Charles, and the code was licensed to Alice under and open/free license.

If the license is revocable, Charles should be able to revoke the licenses for existing copies, and offer replacements that are more closed. Those who do not accept that replacement license should, I think, be able to continue using the copies they have but they will not have a license. Their rights will be limited to those rights that copyright law gives to owners of legally made copies. For software, that would mean they could use the code, but could not make and distribute copies or derivative works.

If the license is irrevocable, then Charles should not be able to take away existing licenses, but he may be able to stop issuing new licenses. That brings is to the issue of sub-licensing. If the license is sub-licensable, then when Alice gives Bob a copy, Alice can also give Bob a license via her sub-licensing right.

If the license is not sub-licensable, then Alice cannot give Bob a license. Bob's license has to come from Charles. So what happens if before Alice gives Bob a copy, Charles has decided to stop issuing new licenses?

I think Alice should still be able to distribute to Bob, because she has a license that allows distribution. Without a license from Charles, though, Bob would only be able to use the code for things copyright allows the owner of a particular legal copy to do without a license, which would be use it himself but would not include making and distributing copies and derivative works.

Alice might be able to argue that the terms of her license with Charles require Charles to provide licenses to those whom Alice distributes to, and so perhaps Alice could go to court to force Charles to keep granting licenses.

I don't recall enough from law school about third party beneficiaries to figure out whether Bob could sue Charles based on Alice's license to get a license from Bob for a copy he got from Alice, or whether, if Charles sued Bob for copyright infringement Bob could use Charles' contractual obligation to Alice in his defense.

You can retroactively do anything that doesn't change the status of existing copies held by others under valid licenses that don't allow you to force a licensing change.

You can remove GPL from something you yourself put GPL on, but existing copies held by others are still under GPL.

You can make something Apache licensed that was proprietary too, and old copies will remain proprietary unless you declare an exception valid for all existing copies under your copyright (which may be what you meant?).

They apply to those copies you added the notices in and any copy made from those with the notice.

If nobody ever has made a copy of a version without the notice, that effectively means that all published versions now are under that license and that nobody may use it under another license, because they have no legal source of it under any other license.

If there's already copies been made, those copies remain under the previous licenses if any (which may be "all rights reserved" as the legal default).

Whatever you write is copyright under the creator or the employer of the creator. What license you put past that is whatever you want, whenever you want.

It's also interesting that Lattner joined Github only in October.

They just made public the repo with the guidelines for Swift's evolution process: https://github.com/apple/swift-evolution/blob/master/process...

It's also interesting to see the graph of contributors (https://github.com/apple/swift/graphs/contributors). I noticed for example that Slava Pestov (The creator of the Factor programming language) has made a number of commits. Apple has hired some really smart people to work on Swift!

Edit: Also jckarter the creator of the Clay programming language is in there too!

Lexer.cpp: int X;

Interesting that they started with git, instead of even a very small section of working code first

I think it's because they need a repo before they can start collaborating, so it's best to set it up ASAP to allow people to start pushing code. In my opinion it also helps to set up the initial repo right away so you can benefit from version control features and be in the mindset of making proper commits instead of a huge initial commit that appears out of thin air.

Interesting there is no link to add issues to those repositories !

Probably because they will want to use radar for bugs and general discussion might be done like Linux mailing lists.

Edit yeah. that's basically how they are handling it but with the exception that they are using a public jira instance for language bugs, radar for xcode and nda bound bugs and a mailing list for general discussion.

https://bugs.swift.org/ <-- public jira instance

Apache 2.0 License + Runtime Library Exception + copyright owned by the contributor (i.e. no assignment or CLA) + good community structure and documentation + code of conduct... well done, Apple!

Anybody knows what effects of the "copyright owned by the contributor" are in the context of Swift's Apache license?

I guess the "good side" is that the lawyers of other companies probably like when the code made by their programmers keeps being copyrighted by the company. But it is still an Apache license, so they can't demand too much from the users of the code.

Still, are there any negative aspects? Any imaginable danger?

Can the standard library have problems with (once in the future) having different copyright holders for its different parts?

What it means from a legal standpoint is that Apple is bound by the same terms as everybody else.

The way it works is this: Apple is making Swift available to you (and others) under Apache 2.0. You send in some changes, which you make available to Apple (and others) under Apache 2.0. Everyone is on equal footing, and Apple can't relicense it to someone else on terms of their choosing that involve, for example, neutering the patent grant's self-destruct clause.

This was the default way that open source worked for years, before people started cargo-culting the (totally unnecessary) CLA process into their projects.

What it means from a practical standpoint, though, is that the project is easier to contribute to, what with the impedance imposed by a CLA process being, you know, non-existent.

That ridiculous: "started cargo-culting the(totally unnecessary) CLA process"

It's so they can re-license in the future. There are some projects with so many authors that it is impossible to re-license because you need sign-off by every single person, even if it makes sense to re-license.

From a contributer's point of view, the inability to re-license practically is often a feature, not a bug. CLAs make the worst case scenario touted by GPL advocates about non-GPL licenses practical: They can profit directly and exclusively from your work without your direct consent.

Also the ability to relicense an Apache License 2.0 work is relatively unimportant (compared to, say, the ability to relicense something under a more restrictive license like the GPL).

I know CLAs let corps relicense. In fact, you'll find that I explicitly mentioned relicensing in the sentence immediately preceding that one...

Can you explain what's ridiculous about the part of my comment that you quoted?

That's a feature. What is the point of contributing to a project, if someone else can effectively destroy all your work at their discretion?

"copyright owned by the contributor" means that as the project matures there will be way too many contributors. To change the license for the project to something that is not Apache-compatible Apple would have to ask every contributor to re-license their code, and if the code author disagrees re-implement corresponding parts. In practice that's a signal to every one that the licensing terms are very unlikely to ever change.

Aside from the hilarious description of Oracle [t=2107], it's worth watching "The Rise and Development of illumos" [1] as it discusses some consequences of signing away copyright on your contributions to an open source project.

[1] https://www.youtube.com/watch?v=-zRN7XLCRhc

Can you or someone summarize the salient points, for someone who doesn't have time to watch an hour-long video?

Sun Microsystems released the Solaris operating system source code, but required all contributors to handle the copyright ownership on their code to Sun.

Then, shortly after Sun acquisition, Oracle closed the Solaris code and got away with all contributors' copyrights.

Super, thanks!

It's a good watch. Don't skip it.

I find his speaking style extremely irritating. I can't take more than a few minutes of this. I'm sure it's full of substance, though. Perhaps there's a transcript somewhere?

I hope Bryan once publishes the annotated presentation? I'm also one of those who have problems following the narration in the video. Until then, I've posted a link to the slides here (see my other post).

Not really.

Your typical corporate IP lawyer might feel queasy about the collective copyright aspect, but so much of the open source world works this way now... they can suffer in their jocks.

One important question they'll ask is: "Who can enforce the copyright and licence?" (Which is when the subtle difference between joint and collective copyright matters.)

Non-trivial contributions are made under the terms of the Apache 2.0 Licence, so regardless of who owns the copyright, everyone operates under those same terms.

One common rationalisation for copyright assignment is ease of relicensing, should it be necessary. That's much less important when operating under the terms of a permissive license.

"Who can enforce the copyright and licence?"

The answer is only the owner of an exclusive right of copyright has standing to sue. So any of these open source projects that have no copyright assignments would have trouble suing. But in practice, who cares. Unless you want to sue people, it literally doesn't matter.

The only folks who often care about suing are those who are trying to enforce certain types of share-alike licenses (GPL, etc) because they are ideological.

If you are using Apache or BSD, you probably aren't suing folks because you are fine with them commercializing it or doing whatever with it (and if you are using these liceneses and aren't okay with that, you may want to reevaluate your life choices)

Joint holders can also enforce copyright, though open source codebases work more like collective copyright. That said, non-exclusive Linux kernel copyright holders have performed enforcement activities (quietly or noisily)...

"Joint holders can also enforce copyright, though open source codebases work more like collective copyright."

Joint copyright is basically non-existent in the US. For example, you must intend to create a joint work at the time of creation. You can't make it joint later on by signing a document saying it's joint with someone. There are other issues too.

This is deliberate, as joint owners each own a 100% enforceable set of rights, and the law doesn't really want tons of people running around claiming to own the same work.

"That said, non-exclusive Linux kernel copyright holders have performed enforcement activities (quietly or noisily)..."

Not in the US. It's not possible in the US. It'll get dismissed immediately.

> Your typical corporate IP lawyer might feel queasy about the collective copyright aspect, but so much of the open source world works this way now... they can suffer in their jocks.

This is a bad attitude if you want buy-in from large organizations. If you're not worried about that, no problem, but if buy-in is your goal (and I'm sure it's Apple's goal here) you can't just tell potential contributors to "suffer in their jocks."

Sure, it's flippant, but do recall that the entire concept of open source absolutely terrified IP lawyers not that long ago (and in some cases, still does).

Lawyers who are too conservative to allow their company's developers to contribute to open source projects (that they don't own) have a problem. Open source is way beyond pussy-footing around just to make corporate lawyers feel comfortable.

And seriously, if Apple can do it, why can't they?

This comment doesn't make a lot of sense. The "corporate IP lawyers" being referred to would be Apple's own counsel, not those of "potential contributors".

Also full change history since before the project was uploaded to Github.

Happy to see that my collection of Swift compiler crashes (see https://github.com/practicalswift/swift-compiler-crashes) has been part of the official Swift repo since September 2014: https://github.com/apple/swift/commit/e5ca8be1a090335d401cd1... :-)

A previous HN thread about the swift-compiler-crashes project: https://news.ycombinator.com/item?id=9020206

I'm really impressed by the attentiveness of the Swift compiler team. Found this in the repo: https://github.com/apple/swift/commit/666646fee95bc75ca81e1d...

One tweet and the bug is fixed within a couple of hours. Wow!

Found that issue while working on the Pythonic.swift project: https://github.com/practicalswift/Pythonic.swift (btw, contributors welcome! Know Python? If so, a very good way to jump into Swift programming is by contributing to Pythonic.swift: a Swift implementation of selected parts of Python standard library)

Wow, congratulations, that's really cool! Speaking of errors, I remember receiving the "Expression was too complex to be solved in reasonable time" error when I was first implementing Catmull-Rom splines for calculating flight paths in a game that I developed. I translated that to, "The math is making the room spin up in here." Definitely the "coolest" error I've hit working with Swift.

I recognized the name Catmull from Steve Jobs biographies... lo and behold you're talking about the Pixar President Edwin Catmull.

Indeed; that's him! Edwin Catmull [1], along with Raphael Rom [2], created the Catmull-Rom spline.

It was perfect for the Galaga-like level in my game. I only need to define a few control points to create a robust flight path for the enemy drones. The cool thing about the Catmull-Rom algorithm is that the spline passes through the control points.

[1] https://en.wikipedia.org/wiki/Edwin_Catmull

[2] https://en.wikipedia.org/wiki/Raphael_Rom

Curious -- were you implementing the drawing algorithm by scratch? or were you using any libraries?

Thanks for asking... I used Apple's SpriteKit framework [1][2]. It's essentially a 2D graphics rendering framework that primarily acts as an abstraction layer for OpenGL ES. In addition, it also offers several other "nice-to-have" features with regard to 2D game development (e.g., collision detection, particles, physics, etc.)

Of course, you could do all of the above without SpriteKit. For example, for all of the rendering, you would simply write everything directly in OpenGL ES.

There are also cross-platform options, like Cocos2d-x [3] and Marmalade [4].

Finally, if you've read this far, you might be interested in reading my general thoughts and feelings from when I finished the game [5].


[1] https://developer.apple.com/spritekit

[2] http://www.raywenderlich.com/category/sprite-kit

[3] http://www.cocos2d-x.org

[4] https://www.madewithmarmalade.com

[5] https://news.ycombinator.com/item?id=8888107

When that happens, try adding type signatures to any closures that are currently using inferred types. It often fixes it.

The programming language eco system is really improving rapidly and efficiently. It seemed the developer's toolkit was limited by the languages created 20+ years ago but within the last few years we're seeing a renaissance in developer toolkits as well as development philosophies.

Languages like Go, Rust, and now Swift are not only great from almost every aspect over the last generation languages like C, C++, Java, but a lot noobs or scripting language developers are also converting to more low level languages. So the barrier to pick up a lower level language and become productive in it has really diminished.

Go has had a head start and introduced minimal simplicity. It's a great/powerful language and almost everybody can pick it up quickly within a few days. I wouldn't listen to people who dismiss the language for its lack of "features" and have never written more than "hello world" in it.

Swift is "important" because of Apple & iOS. It has a much steeper learning curve than Go and naturally it takes a few weeks of dedication to get comfortable with it. However, once you overcome the introductory challenge then you'll start to appreciate the language and its capabilities.

Already the job market for both languages are really high with higher than average salaries. So learning/mastering both Go and Swift is the best decision you can make.

"learning/mastering both Go and Swift is the best decision you can make" is a very bold claim.

In my area we use Go for some systems but found it scales badly from an engineering point of view to larger more complicated systems, compared to languages like Java and Scala. The JVM has much more mature tooling and libraries too.

For mobile applications it will be a while until Swift is stable on Android, so some of the cross platform languages would be a good choice. React Native, Unity, Unreal for example.

For android, we already have kotlin (https://kotlinlang.org/), which is very similar to Swift and has 100% interoperability with java.

Until Google says it is the new king, most customers won't green light it.

Better is very subjective.

They both solve a lot of the same problems, but lots of people will go for Kotlin just for static typing.

It added type checking ala. Hack and Typescript. It's optional, and doesn't give you the same compile-time guarantees that a language with pure static typing does.

Also, dynamic languages like Groovy take a performance hit. Static typed JVM bytecode runs faster than dynamic bytecode.

Whether either of those are relevant to your application really depends, but Kotlin definitely is going to gain some followers due to it's differences from Groovy.

I'm learning Swift right now, and really appreciate type checking.

> Groovy creator Guillaume Laforge blogged that, “an acquainted Groovy eye would immediately notice the inspiration the Swift designers took from Groovy.”

Guillaume Laforge is NOT the creator of the Groovy Language, James Strachan is. And Swift did not take inspiration from Groovy.

What else is inaccurate in the article? 6 months after it was written, Pivotal voted against Groovy's diversion into static typing and Android development by retrenching Laforge and the programmer working on it.

In what way does Go scale badly from an engineering point of view?

It was our opinion that it's harder to write code that will be shared with a bigger team. Some of the factors were the simpler type system, lack of generics meant lots of copy and pasting of common patterns. The package system seemed less comprehensive and flexible in comparison to Java's. These are just subjective issues of course, but I think it's reaching a bit to say that Go and Swift are the best two languages you can learn.

Not a go fan, but seems like if anyone has scale problems, google would, and go would give them these issues too which is surprising since that was kind of the goal to solve from their perspective.

There's different definitions of scale. He is talking about from an engineering perspective and at Google we have seen nothing other than a few periphery sites being written in Go.

I fully agree that Go is a poor language if you are building a large, monolithic application.

> I fully agree that Go is a poor language if you are building a large, monolithic application.

I find that statement hilarious considering that it was explicitly one of the design considerations[1] for Go. So they either failed massively, or there's a difference in perspective on what a good language for programming in the large is.

From Rob Pike's talk[1]:

> Go was designed to address the problems faced in software development at Google, which led to a language that is not a breakthrough research language but is nonetheless an excellent tool for engineering large software projects.

1. https://talks.golang.org/2012/splash.article

>I find that statement hilarious considering that it was explicitly one of the design considerations[1] for Go.

That doesn't mean much, if anything. One of the design considerations for Java was "write once, run everywhere" and that didn't turn out that well either.

Most languages make failed or semi-failed promises.

And their idea of addressing software development at scale, might not be 2015's idea of doing the same.

Aside from Google, most other teams I've read using Go are more often than not writing small or medium-sized services, no big applications or highly complicated stuff.

I share that experience. I use Go whenever the service is simple, requires better performance than Python, and cannot use too much instance resources.

> I find that statement hilarious considering that it was explicitly one of the design considerations[1] for Go.

Isn't it hilarious that a statement from the Go authors could be used as evidence of its awesomeness given how the authors are naturally and heavily biased?

>but seems like if anyone has scale problems, google would

Google doesn't use Go at such large scale though. Some projects here and there, and most of them small for all I've read. The most publicly celebrated ones being a MySQL front-end for YouTube and a caching-layer (?) for Google Downloads. Not exactly earth shattering applications.

My understanding is that beyond the examples you talk about that go is being used extensively in google as a backend glue language for automation and services.


>as a backend glue language for automation and services.

Which again is not "at scale" (except in the sense that this automation manages thousands of servers etc).

It's what people used to use Tcl, Perl, Python, etc for.

These apps were the ones causing glacial compile times in c++?

I don't think the ones "causing glacial compile times" have been replaced.

I'd agree with you about the type system, but what's wrong with the package system of Go? (I have little experience with Java's)

I still remember max howel tweet[1] in which he publicly said that we was rejected by Google. Looking at his linkedin profile[2] , he was later hired by Apple in August 2015. Now he is biggest[3] contributed to Swift package manager. It is good to see that the person who has lot of experience in handing Apple and package system is handing this stuff. I guess, things happens for good.

[1] https://twitter.com/mxcl/status/608682016205344768

[2] https://www.linkedin.com/in/maxhowell

[3] https://github.com/apple/swift-package-manager/graphs/contri...

Highly qualified people get rejected by google's interview process all the time, so people shouldn't take it personally if they get rejected. google is willing to miss out on good people occasionally because they believe they can't fix the problem w/o mistakenly hiring more mediocre/bad people.

Fully agree. I seriously don't understand the statistical illiteracy[1] that drives people to take every instance of a (perceived) false positive or false negative as a sign of an entire system's unsuitability. I guess a lot of people just have problems with the concept of a counterfactual. Note that this doesn't apply to people's reactions to their _own_ experiences, since it's completely reasonable to have a bit of an emotional reaction to something like getting rejected.

[1] I couldn't think of a better way to put this, but it's not quite the right term, since you don't need any education in statistics to understand how irrational these reactions are.

I think it's fine to take it personal, just don't take it out on yourself. Daniel Ek, founder of Spotify, is another Google reject.

I've read blog post on qualified developers being rejected by Apple as well. Last was one was by Furrow.

It's really great to see Apple investing in package management for Swift. Handling dependencies and versioning well is so important for a language to get right out of the gate.

Now I feel better about my past rejections that were based on such stuff.

Fantastic news that Swift is now open-source, though it came about 4 hours too late for my GotoBerlin presentation on Swift 2 Under the Hood (on SpeakerDeck at https://speakerdeck.com/alblue/swift-2-under-the-hood-gotobe... if you're interested)

I've also open-sourced the SIL Inspector that I demonstrated (https://github.com/alblue/SILInspector) and written up a post on InfoQ covering the important points of this release


That was my first thought: Didn't Alex talk about that yesterday night. ;-)

It looks like Apple is also releasing an official package manager for swift.[1] I wonder how that will effect Cocoapods.

[1] https://swift.org/package-manager

Also of note, the largest contributor to the package manager is Max Howell (mxcl), the creator of Homebrew:


It looks like he managed to go through a whiteboard coding exercise in the end! As far as I know, Apple follows roughly the same hiring practices as Google. Well done (no sarcasm here, it's probably great to work at Apple)!

The same guy who wasn't offered a job at Google because he didn't do well in the interview (or was it code in the interview?)

Google doesn't provide feedback on why they reject you. For example, you could be the world's foremost expert on Erlang. But the department interviewing you needs a C++ programmer.

You'd never know that was the reason. You'd just be notified that you weren't called back for another interview and asked to please check back for more positions in a few months.

Actually, you can extract some info from the recruiters. Just ask them, tell them you need it to prepare better next time, tell them you know the reason but want to cross check etc. They will tell you

I was just rejected by Google. They will give feedback -- in my case, the recruiter said that they were worried I didn't seem to care whether my code would actually work as written.

They recruited me through the code jam, but hey.

Interesting to also see Mattt Thompson helped out.

Yea that's great; he's has a clear understanding of what it means to write and maintain a third party package[1] and he's also exceptionally good at writing documentation and code samples[2].

1: https://github.com/Alamofire/Alamofire

2: http://nshipster.com

Thanks for the link. The repos weren't up when I made my comment.

Check Twitter, they are more than happy to see their work deprecated.

Both Cocoapods and Carthage should eventually be phased out with an official package manager.

Positively, CocoaPods was filling a gap that should have been done at system level. So we've updated our FAQ about it, https://guides.cocoapods.org/using/faq.html

It's great to see them follow through with this. I remember when Steve Jobs went on stage and said that FaceTime would be an open standard. Haven't seen that happen yet.

> I remember when Steve Jobs went on stage and said that FaceTime would be an open standard. Haven't seen that happen yet.

FaceTime has been the subject of multiple patent lawsuits, which is what has prevented it from being opened.

See: http://www.bbc.com/news/technology-20236114 and http://www.techzone360.com/topics/techzone/articles/2014/09/...

Why would this affect opening the protocol? Patents aren't about keeping implementations secret.

My understanding is that the patent nonsense forced Apple to transform FaceTime from a peer-to-peer protocol into one that transmitted all data through centralized servers, specifically Apple's servers.

That meant that if the goal was for interoperability, Apple had to either provide server capacity for a bunch of other people's traffic, or they would have had to come up with a way to federate the system.

Federation certainly could have been done, but that's a lot of sudden extra growth in scope compared to just taking what they had and releasing it.

Ah, that would explain it. Thanks!

According to this reddit thread[1] they were sued for patent infringement[2]

[1] https://www.reddit.com/r/apple/comments/1xuzif/what_ever_hap...

[2] http://www.bbc.com/news/technology-20236114

Re FaceTime, I recently read an unsubstantiated but plausible comment that they'd run into patent issues that caused a redesign that caused issues open sourcing it.

and according to someone I heard on a podcast, many of the engineering leadership heard the open sourcing comment for the first time while Steve was up on stage as well.

Probably both are true.

Mind linking the podcast? Generally curious.

Not sure which particular episode (you might be able to find it by looking through old shownotes) but this was mentioned on Accidental Tech Podcast, I think by John Siracusa (of really long MacOS review fame)

They were definitely sued very heavily over face times architecture.

Super excited! I will totally be exploring Swift for quantitative work. Julia has been great so far, but a lack of good IDE tooling is making a large codebase difficult to navigate and keep clean. Python has even less type safety than Julia. Swift has a REPL! Go doesn't, and its lack of generics makes writing most algorithms very limited (there isn't even a matrix 32 library, just 64 bit). Java has horrible native interfacing. C# is pretty anemic on Linux. C++ has too many gotchas, slow compile, to feel productive. Bonus: Swift libs will probably be very easy to deploy on both Android and ios.

It is a huge step for Swift. Finally it is no longer the Apple walled garden and it will become a popular universal platform like Python or JavaScript, for sure. If you want to learn Swift, it is high time. Start with the huge collection of 300+ video tutorials at https://www.youtube.com/user/TheSwiftLanguage

Side note: Julia is great. Very easy to learn, blazing fast, powerful, general-purpose, works everywhere and even integrates well with C/Python/Fortran. As for the IDE, there is Juno based on LightTable, there is Sublime-Julia for Sublime Text, as well as Julia support for Atom.

You don't need an ecosystem? Swift does not have this, not for Linux at least.

I definitely need a tooling ecosystem, so I'll be waiting for good integration between IDEs and LLVM for Swift. Maybe Atom or VSCode will get there soon. For libraries, when I really need something, I'll wrap it myself using C FFI. It is very easy to pass C structs by value or reference between Julia and C. Go is not bad either and does a lot of static checking for me. Swift sounds like for value types it should be easy. Java is super painful with the marshalling back and forth.

some of us get by just fine in happy ecosystems that exist outside of linux.

yeah most of us.

> C++ has too many gotchas, slow compile, to feel productive.

Which raises the question: Why was the compiler for Swift written in C++? I know writing a compiler in C/C++ is probably an instinctual reaction at this point, but um ... what's the advantage of C++? especially if the language will become self-hosting?

LLVM is written in C++ and I'm assuming that the Swift compiler developers are also very familiar with C++. It's also fairly straight forward to write binding for any language to things written in C/C++. The latter makes it at least theoretically possible to build tools on top of the compiler. C++ is really the obvious and simple choice, that you can get away with without large discussion.

Also if it's actually planned to make Swift self-hosting, the language you write the initial compiler in matters even less. If you're throwing it away anyway at the first opportunity, who cares about a few imperfections?

Have you looked into F#?

It's been open source for a while and there is a very good ecosystem that exists already for it. Plus the language itself is a pleasure to use.

No, I haven't looked into it much. I've been hesitant to commit too much to the CLR family, but maybe with MS's new stance on open source, I'll give it a second look. I'm also more interested now in languages that can deploy on mobile, so as alternatives to Julia, I'm actively looking into Swift, Go, or just plain C++. Xamarin is pretty compelling but I'm considering options before being locked into a fairly expensive vendor.

Interesting that they rewrote the Foundation library in Swift for the open-source release rather than open-sourcing the ObjC one and bringing along the ObjC runtime. I wonder if this means they still believe the ObjC runtime and Foundation library are still worth keeping proprietary, or just that this is a step toward phasing out ObjC.

They didn't rewrite most of Foundation in Swift, at least not yet. If you look in the files, they are full of calls to NSUnimplemented().

Interesting to see what they do have and what they don't have: https://github.com/apple/swift-corelibs-foundation/blob/mast...

I believe it is meant as an abstraction layer for non-OSX systems.

If you watch the WWDC 2015 videos, the only ones that used Objective-C instead of Swift were related to the language improvements.

I guess that says it all.

I find the number of typo PRs to be amusing. Makes me wonder if there's a mass effort to slog through commented code just to jump into the contributor list.

Correct spelling is certainly good, but the interesting phenomenon is getting a PR merged in a high-profile project - however slight the change - as a badge of cool.


This is absolutely a case of earning a badge of having contributed to this complex famous project, but it is also a way to on-board and empower people. Recruiter should always look deeply and not taking "contribution" at face value.

Definitely to get the little achievement, me included. I wouldn't put it on my resume but I guess it is a fun little thing to have.

Generally when I'm using a new framework, I like to scan the code to pick up on style, undocumented features, etc. Sometimes this results in a few typo-level pull requests.

I never though of this as being resume line item grubbing behavior, now I can't decide whether to stop doing this or start putting it on my resume :)

This is what I end up using the GitHub online editor for.

Just re-stating the obvious, but it's also interesting how GitHub has become the default go-to of repos for everyone, like Google is for - well - googling. Kudos to both GiHub and git, you are simply awesome.

What kind of trolling is that ?

>I think we should use GPL v3 instead.


In all seriousness, I'm not sure they could switch it to GPLv3. I think that Apple's firmware signing might run afoul of the anti-tivoization clause and prevent them from shipping Swift on Macs. IANAL

Apple seems to think so, which is why all their GNU tools are frozen at their GPLv2 versions.

Apache2 is compatible with GNU GPLv3, though.

Compatible doesn't mean equivalent. GPLv2, AGPL, and LGPL are all compatible with GPLv3, but they don't have the same terms.

GPLv2+ (GPLv2 with the optional "or any later version" language) is compatible with GPLv3, but GPLv2 is not otherwise compatible with GPLv3 (e.g., Linux is under GPLv2, and not GPLv3 compatible.)

That issue changed my view of GitHub, and related things. I'd seen a few animated gifs in other threads this past week, but it didn't really sink in until this.

I used to hold scientists and programmers to a different standard than most normal people, because it seemed like a certain level of advanced understanding was necessary to build anything functional in those fields. But I've since realized that special ability does not carry over into all areas of life.

It feels like seeing a ghost. I'm embarrassed to be registered with GitHub, and also to be human.

> I used to hold scientists and programmers to a different standard than most normal people, because it seemed like a certain level of advanced understanding was necessary to build anything functional in those fields.

This is a dangerous and wrong idea.

> I used to hold scientists and programmers to a different standard than most normal people, because it seemed like a certain level of advanced understanding was necessary to build anything functional in those fields.

I think you need to reevaluate the standards to which you hold people you know nothing about. GitHub is a free platform that anyone can post on, regardless of academic pedigree. Further, having specialized knowledge and being a troll are not mutually exclusive qualities. The humor of early hacker culture may have been more witty but it was nonetheless a means for programmers to take themselves less seriously [1].

> It feels like seeing a ghost. I'm embarrassed to be registered with GitHub, and also to be human.

Maybe that's a sign you should get over yourself.

[1] http://www.catb.org/jargon/html/

Whenever I pictured the kind of person who posted reaction gifs to a thread, I imagined some 14 year old kid trying to be cool.

Now, seeing this on github, I can only spend a few minutes clicking on the gif-poster's names and taking a glance at their code to see if they are actually mentally retarded or 14, and leave mystified and horrified.

I'll take people who post reaction gifs over people who use "retarded" as an insult.

This is a serious question: what about enjoying memes, and humor in general, indicates a lack of "special ability"?

I won't disagree that the stuff people have posted in that issue isn't funny. But honestly, I'd rather see that kind of thing than live in a world where people feel the need to treat everything (or even all technical things) seriously. There's enough darkness in the world without imposing more on ourselves.

FLOSS gotta FLOSS. I'd be surprised if they didn't open a pull request to change the license.

I actually read this PR as trolling against GPL folks, in the vein of making fun of their license of choice. Seeing that people have also thought differently, it would perhaps be better not to blame a group at all.

Github is weird.

Yeah, and memes are tiring, but lots of people clearly enjoy them.

I really enjoy Github as a technology platform. As a social network, not so much.

With open-sourcing C# and Swift, the era of major closed source programming languages is now officially over.

I think the make up of the web is an indication that that era has been over for a decade or more, and it just took some people/companies a while to realize it.

Proprietary languages, even ones backed by a behemoth like Microsoft or Apple, could never really dominate the most important platform when facing off against open competitors (even open competitors with no real money or power to speak of).

Great news! Coding in Swift is fantastic and I would love to see it coming to more platforms, maybe even on servers. It could become a serious Javascript competitor due to its elegant syntax, the type safety and speed.

I completely agree. I want to be able to write the core of an application once, and then add on a UI for every platform I deploy it on (Windows, OS X, Linux, iOS, Android, etc.). Currently, the only real options for doing this are C/C++, and that's just no fun to do.

I'd love to have a higher level like Swift that can be easily ported between platforms and connected to whatever development language/environment that is commonly used on that platform.

I'm hoping that open sourcing Swift will allow something like this to happen. It seems like Microsoft is already making moves toward making Swift interoperable with .NET as a way of making it easier iOS developers to release Windows phone apps, so I'm optimistic.

You can do this with rust and go already by cross compiling which they both make easier than C++ makes it.

> It could become a serious Javascript competitor due to its elegant syntax, the type safety and speed

Particularly in combination with Web Assembly. I wouldn't be surprised if there is already an LLVM bitcode > WASL compiler in progress.

Am I the only one who finds it odd that while pushing two high level but performant languages (Objective-C and Swift) Apple wrote their Swift compiler in C++?

Lattner directly addresses this in a FAQ in the repository[1] "Do you plan to rewrite the Swift compiler in Swift?

Not in the short term. C++ is a very pragmatic language for implementing compilers, since it has good performance characteristics and allows higher-level programming idioms than C.

That said, we do expect Swift to a better language than C++ in a number of ways, so why don't we implement the compiler itself in Swift? There are a couple of reasons that bootstrapping is not a good idea, at least in the short term:

This complicates bringup of the compiler, because you have to move both the compiled language and the compiler at the same time as the language evolves. We want the language evolution and direction to be driven by general purpose programming challenges, not by the specific needs of compiler hackers. The urge to "scratch our own itch" might be too great. That said, we are writing the runtime library in Swift itself. We may also decide to rewrite the compiler in Swift sometime in the distant future when the language settles down. At that point, it may be a good opportunity to revisit previous (internal to the compiler) design decisions, and we do expect and hope Swift to be a great language for doing many things, including implementing compilers."

1. https://github.com/apple/swift/blob/master/www/FAQ.rst

It is not odd for anyone with background in compiler development.

By using C++ they could ramp up the compiler much faster and rely all improvements done to LLVM.

Eventually if the language succeeds in the market at large, they can decide to bootstrap it.

Although I am a fan of bootstrapping, I also see a good value to expend development resources elsewhere until a language reaches wider adoption.

Not to mention, bootstrapping in a language that's not stable yet can be.... quite a pain.

Hahaha, I'm amazed that the Rust developers were able to do that.

Saying it was "quite a pain" is the understatement of the year.

Yup. I really think it was worth it though, it taught us a lot about how to make the language.

Mind, are you not worried at all that it may have taught you a lot... about how to make a language for writing compilers in? (paraphrasing Chris Lattner)

That is indeed a concern, I agree with Chris here.

The solution we had, though, is Servo. It being developed alongside as well meant we had another significant, non-compiler project, which guided us out of that trap.

Why would Apple write a Swift compiler in Objective-C, a language that it is in the process of phasing out in favor if Swift?

And of course it is not possible to write a Swift compiler in Swift before the language exists.

So no, not odd at all. Quite logical actually.

> of course it is not possible to write a Swift compiler in Swift before the language exists

No, but you can do a self-hosting port after you have a first rudimentary compiler. Many compilers have been built like this. Some did it early in language development with a purpouse built one-off bootstrapping compiler, some did it after the language was somewhat stable (eg Go).

ObWP: https://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29

Some people I know previously asked this question to one of the Swift developers. I believe the reasoning was along the lines of (very liberally paraphrased/interpreted): Even aside from the problem of bootstrapping the compiler's compilation to start, performant compilation on C++ is a very mature and well-explored problem space. C++ already compiles on a ton of systems, and maintaining a C++-to-Swift(bootstrap compiler)-to-Swift(final compiler) compilation process is added complexity and invites repeated work.

From a language design point of view, the things needed to get a language to the point where it could successfully and efficiently compile itself would skew or re-order priorities in a much different fashion than if they were to focus on building and iterating on an applications and systems language.

tl;dr: LLVM and Clang and their assorted toolsets do quite a bit of valuable work; reinventing that to serve the language they're building is a feedback loop is a downside that also removes some upside from the equation, too.

I believe I saw Lattner once describe a self-hosting compiler for Swift as an anti-goal, at least before the design had stabilized.

Aside from the value of maintaining LLVM as a shared codebase, the concern was that writing a compiler in Swift could bias early language design tradeoffs towards decisions that would make it easier to write a compiler at the expense of the larger universe of potential applications.

Objective-C bridges to and from Swift easily, so it would be easily to incrementally replace Objective-C code with Swift code. Since C++ doesn't interact with Swift at all, it would either have to be wrapped in C/Objective-C, or the entire compiler would need to be rewritten at once.

That being said, C++ is probably a better choice, because dynamic dispatch sucks and there's better platform support.

Chris Lattner who created Swift wrote LLVM in C++, so it is probably easier to work with and he know C++ very well.

That is probably the answer. But to be fair there is no one that knows Swift better than Chris Lattner.

Because it is based on LLVM and the main LLVM API is C++ based. And no other language has good C++ interoperation.

Yes other languages have LLVM bindings, but they aren't as comprehensive as actually linking to the LLVM C++ API.

Source: Have written a (toy-ish) compiler with LLVM

I'm glad they didn't write it in Objective-C, as this would probably make compilation on Linux much harder (I have no idea what the state of Linux support for Objective-C is). As for writing it in Swift itself, that's not possible until Swift is sufficiently stable and with enough library support. Which it may or may not have now, but certainly didn't have when they started ;)

Linux support for ObjC is great on the compiler side (GCC supports the full language), but none of the core libraries are available. You can get some stuff (NSString, NSDictionary and so on) through GNUstep, but last I checked it was an uphill battle to be truly productive with ObjC on Linux.

GCC doesn't support the full language anymore, since the stuff that Apple added after finishing the migration to Clang hasn't been ported to GCC (e.g. generics and array/dictionary literals) and there doesn't appear to be anyone interested in doing so.

It has hardly changed since the days I used AfterStep and WindowMaker (early 2000).

Testing the binaries on ubuntu decompressed to to $HOME/swift and trying to execute swift:

Welcome to Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 778f82939c). Type :help for assistance.

  1> help
opening import file for module 'SwiftShims': No such file or directory

I could not find any mention to environment variables that could be used to override default locations, like SWIFT_LIBRARY_PATH or something like it.

Type ":help". That is, type <colon>help. The : is used to differentiate between commands to the repl and swift code.

Thanks I didn't noticed the colon, my fault.

But even after copying all to the default location /usr it still doesn't work:

swift swifthello.swift

<unknown>:0: error: opening import file for module 'SwiftShims': No such file or directory


swift -I/usr/lib/swift swifthello.swift

<unknown>:0: error: opening import file for module 'Swift': No such file or directory

Run Systrace on it and you'll see what it is looking for.

I used ltrace and saw a call to getenv("SDKROOT") but pointing it to any of:

export SDKROOT=$HOME/swift/usr


export SDKROOT=$HOME/swift/usr/lib


export SDKROOT=$HOME/swift/usr/lib/swift

All the above do not work, maybe when github is up we can see how to do it.

It seems to want to find a `SwiftShims.swiftmodule`, fails, prints the error message and then loads the module from an alternate path but it is already too late.


The more I think about this, the more I wonder how existing third-party libraries will respond. Similar to Android and Java, I'd imagine we'll start seeing "vanilla" Swift libraries crop up that only use public/standard libraries and can work on iOS/OS X apps as well as open source projects.

There's one thing I can't understand about Apple's approach, and that is their pathnames.

As good as Swift is, putting it by default in asinine paths like "/Library/Developer/Toolchains/swift-latest.xctoolchain/usr/bin" doesn't help anybody (and a ton of stuff in OS X is like this).

A more Unixy way to do this would be /opt/swift-3.0/bin, where /opt/swift is a symlink to /opt/swift-3.0. Even Apple used to limit the path insanity to merely /Developer/usr/bin. Not sure what happened...

The paths are cumbersome, but I wouldn't call them asinine. Apple's toolchains are versioned by SDK. That's why they have xcrun, so you can do things like:

  # xcrun --sdk iphoneos clang [...]
On my system, clang's path is even worse than your example:

  # xcrun --sdk iphoneos --find clang

You're not supposed to remember those paths. Xcode and xcrun remembers them for you.

Apple doesn't touch the base OS folders for non-OS software, which is why stuff goes into /Library and /Applications. Besides, (Apple has never used /opt, and doesn't even document it, last I checked: "man hier" doesn't mention it.)

> A more Unixy way to do this would be /opt/swift-3.0/bin, where /opt/swift is a symlink to /opt/swift-3.0.

This could cause entertaining problems for people who routinely install both current and beta versions of dev tools (which is relatively common; if you're working on iOS10 features for your new app but still need to release iOS9 updates during the beta period you more or less _have_ to, for instance). I suspect that's why they changed it in the first place.

Not defending the practice, but you can use 'xcrun' to find and run these binaries. E.g. to find swiftc, you can use 'xcrun -f swiftc', and to run it, 'xcrun swiftc'.

I suppose, though it doesn't tab-complete. :) There's all kinds of reasons to want short paths. Having said that, I can create my own /opt symlink to a long path too.


It's not just you! http://swift.org looks down from here.

Such good news. I've bet my career on Scala, but Swift is sufficiently similar in style that it will be an easy transition.

A language to write native (not VM-based) apps for the desktop, iPhone, iPad, Apple Watch, CarPlay and Apple TV is becoming very compelling indeed.

It doesn't work like that, you can't "bet your career" on a language. Either you are interested in continuous learning or you aren't, and it's pretty clear which one is a better choice when choosing between multiple employee candidates.

It does actually work like that, for me. I'm in my mid thirties and have worked in financial software development for over a decade. Given the day rate I'm earning for Scala development, I will be able to retire comfortably long before Scala goes out of fashion.

Of course, I'll still be coding for fun after I've retired, so I'm looking forward to learning Swift in my spare time, alongside the other languages I code regularly in.

Nice to hear it has worked well for you! I'll then modify my statement a bit a say that I would never suggest "betting a career" on a single programming language, but to of course dive in if a good opportunity presents itself.

Why be your career on just one language? Shouldn't be such an issue to pick up new skills otherwise you become obsolete.

I would love to see Swift for Android programing. I'm already using Kotlin, a language very close to Swift, for programming our Android apps. But I find Swift niftier than Kotlin.

In what way? I've recently started writing in Swift and I find it to be less powerful than Kotlin. One such feature that's missing: extension expressions. Allows things like `let` and `with` from the kotlin stdlib

What exactly are extension expressions, do you mean extension methods? If so, Swift does support them. I actually miss interface extensions in Kotlin, but thats a java cross compatibility issue.

look at the signature for `with`

    inline fun <T, R> with(receiver: T, f: T.() -> R): R 
it takes a lambda that is scoped to the receiver type `T`. This means the lambda runs in the scope of whatever is passed in as a receiver.

    with(list) {
This essentially lets you create DSLs for whatever.

Another thing that's bit me in butt recently is that `Protocol`s aren't concrete types, unlike an `interface` in Java/Kotlin.

If you want Swift on Android, have a look at Eclipse Xtend: http://futurice.com/blog/android-development-has-its-own-swi...

I wonder if Apple is positionning it as a competitor to Google's Go? They are hinting at a usage beyond just iOS and OS X.

I'm much more thrilled about Swift the about Go. Sure Go has a head start in server-side department, but from what I know of Swift I'd much rather write webapps in it then in Go.

Many webapps have a kind of "highlevelness" to them, and Swift nicely addresses that with it's features. Go is somehow on a kind of feature diet that's just not my cup of tea. And in terms of low-high-level-ness it I put it somewhere in between Swift and the obviously low-level Rust.

Swift gives you nice syntax and Go provides you good abstraction for concurrency(channel and goroutines).

Honestly, there are some libraries for swift which are shockingly authentic clones of go's channel + routine syntax. Abstractions like that are not swifts problem.

Edit: also, look at https://github.com/apple/swift-corelibs-libdispatch so those libraries should be portable.

Yes, this library is listed on swift.org right now as a work in progress for Linux, so Apple is both aware and going to get it done.

I understand it more like: Go force one concurrency model on me (like Node.js or Erlang), and Swift is a general purpose language that --over time-- will allow me to use any kind of concurrency model (like C/C++/Haskell/etc.).

Oh, and syntax-wise I like both of 'm. I was not referring to syntax much, mostly to capabilities.

> I wonder if Apple is positionning it as a competitor to Google's Go?

They're giving themselves the option to get out of the computer hardware business if the car takes off without killing their phone business. Think about it. Right now if they killed off the MBP then most devs would switch to Android and they'd lose their iPhone monopoly. But if Swift gains traction as an open platform, they have the option to stop making hardware and open source or license OS X while still maintaining the dominant position in the smartphone market.

I'm not saying that Apple will definitely get out of hardware. But with Intel's rate of innovation slowing down and the R&D for each generation of chips getting exponentially more expensive, one possible future is that the business is not profitable enough to justify the resource drain.

I don't see that happening ever. It's not just that computers are the core of their business identity/culture, but there is too much cross culture of hardware ideas for them to want to ditch it. They're free to try some new widget idea in a MacBook then refine it if it works before adding it to the phone or scrap it if it's flawed without having millions of iPhone users get upset about it. Most of the other handset makers don't have this to test with.

There is at least already work being done on Swift for server-side development, and a developer behind this just commented that they are getting to work at this moment: https://www.perfect.org/ https://github.com/PerfectlySoft/Perfect

I ran into https://github.com/Zewo/Epoch the other day when I was look for a Swift web server and it looked very interesting.

I think they will co-exist as separate languages for separate problem-solving approaches. Go has first class support for channels and duck-type interfaces, for starters.

I would think Google should be more worried than Apple at this point, since Swift works on iOS but Go support in Android is second-class. In fact, there are significant efforts to run Swift on Android which places it at least on par with Go there (and, obviously, ahead on iOS).

I actually don't get the attraction of running Go on Android. I see it as a systems language.

IMHO, Dart is a much more interesting applications language. And it will soon run on iOS (see http://flutter.io)

Hope it's will have brighter future outside Apple ecosystem. It's nice to have more tools for server-side development, but wish it's will be better on desktop than ObjC / Cocoa / GNUstep was.

This is good news (hoping the github link etc will start working in a day or two)! One side effect of swift being open sourced is that more developers will start looking at it for server side development. However, I personally think that Swift will continue to have strong reliance on Apple (esp considering that most external Swift developers will come from iOS development). So, till I see Apple showing interest in Swift getting used on server side, I'll not use it there.

esp considering that most external Swift developers will come from iOS development

I am wondering about this. To me, it seems that there is still space for a modern, pragmatic language that compiles to native code. Coming from C and C++, I have been using Go recently for applications where garbage collection and some performance loss due to a relatively weak compiler is acceptable.

However, I still find the lack of parametric polymorphism tedious and annoying as well as other stuff you'd come to expect from a modern language (algebraic data types, non-nullable types, etc.).

Does anyone who has experience with Swift think that it could be a better language for the niches Go has gained traction? (Besides iOS/Mac development?)

I have worked extensively with both Swift and Go. The currently available Swift implementation in Xcode is fairly closely tied to Cocoa (and hence OS X); I think this would be a serious barrier to generic server-side usage of Swift, so I'm curious to see if they have done anything about that (and what).

Otherwise, it's a fairly decent language. It doesn't have Go's concurrency baked in to the language, but on OS X you can use Grand Central Dispatch (libdispatch) which is a very decent concurrency library and it works very well with Swift, I'm hoping it will be available in the Linux port of Swift as well.

Besides the more sophisticated type system, a major advantage (or disadvantage, depending on how you look at it) of Swift over Go is it's memory management mechanism: it uses Automatic Reference Counting, which makes garbage collection more deterministic and efficient, at the expense of a certain level of overhead in the developer's thought process (e.g. the developer has to be mindful of things such as reference cycles etc).

It's not ready for production in this release according to the site but libdispatch and Foundation are both being ported which should speed up server side development on Linux.

Thanks for this info. Did you try, by any chance, Perfect (the Swift web FW)?

I think Swift is a viable competitor for C++ and Nim.

D won't be fully a player in that space until the GC is fully optional - meaning no library code causes the GC to run unexpectedly.

I'm excited about Swift for desktop/simulation/gaming/embedded development. I'm sure there'll be a Windows port in the near term as well.

Have a look at dlang and nim-Lang. Both answer that

I experimented with D ~2008-ish. IMO it's definitely superior to Go. The problem is that D is probably not going to gain critical mass anymore (I expect the same for Nim). This has an impact on its future ecosystem.

Since Swift is pushed by Apple, it probably won't suffer from the same ecosystem problems.

> (I expect the same for Nim). This has an impact on its future ecosystem.

What do you expect from a future ecosystem?

Nim has seamless integration with C as it compiles to C anyway, so there should be no concerns about that.

It's amazing that really powerful languages are never mainstream. Lisp, Ada, Ocaml, D and Nim will go their way in the future, they are just not as much in the focus of public attention as modern trends like Rust and Swift which are advertised by big organizations like Mozilla and Apple.

Node.js made server side Javascript a reality, but it was done by outsiders using Google's V8 engine rather than by Google itself. What would be wrong with server side Swift being similarly pushed by a 3rd party?

One of the biggest things for me is that now I can draw upon the knowledge and knowhow of the people making Swift itself. Coming from Java, I'm used to reading the sources of all the things and now I can finally do it. So exciting, congrats to everyone involved!

This is pretty awesome. If all of the platform dependencies could be abstracted away, this could form the core of yet another cross-mobile-platform development framework, but with better performance and richer tooling.

I think it really depends on how much control Apple intends to exercise over the IP. Could someone fork it and use it to create a mobile platform that would be free from legal harassment if it competed with the iPhone?

> this could form the core of yet another cross-mobile-platform development framework

Why not bridge the "yet another cross-mobile-platform development framework(s)" that were written for Objective-C, the same way Apple did with their frameworks? There is no need to restart them all over again in Swift to access them in Swift.

Perhaps you were attempting to suggest that no quality cross-platform frameworks ever materialized for cross-platform development under Objective-C? (there were certainly attempts, including from big players) But if that is the case, I'm not sure an arguably better, but not dramatically different, language is going to change anything.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact