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 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"
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.
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.
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.
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 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!
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.
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.
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).
"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.
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.
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).
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.
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".
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.
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.
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].
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.
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.
> 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.
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.
>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 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.
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.
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.
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.
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
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)!
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.
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].
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.
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.
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.
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)
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.
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.
> 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?
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.
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.
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 :)
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.
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
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.
> 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.
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.
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.
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.
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.
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."
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.
> 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).
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.
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 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:
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 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.
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.
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.
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.
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.
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).
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.
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.
No. Swift the language is not to be confused with the iOS framework or tools. While more and more of iOS (and I presume XCode) is written in Swift, that all continues to be closed sourced code and is Mac specific.
I can't comment on Swift as I've not used it but I can say that Go is more than just a language. It's the embodiment of Google's experience running large engineering teams. So many of the decisions in Go--its simplicity, the formatter, the opinionated directory structure, static linking, no special build tools--make life a lot easier for teams. Again, I haven't used Swift, but I don't get the sense that this was one of its design priorities. I've been wrong before though :)
Swift is a very nice language.
And it's pretty easy to learn too - it took me about 2 weeks to get the basics of it and in 1 month I was producing code at the same speed as with Objective-C.
After a couple of months of Swift-ing, I now started a project in C++ and while it's nice to be back home (in the C++ world), I immediately feel like I'm on my own - C++ doesn't make any attempt to protect me from myself (although it feels like I have more power to do what I want).
The Swift compiler, on the other hand, will obsessively stop me from fitting a square into a circle and will only allow me to do that if I declare loud and clear that "I know what I'm doing!".
I find package management unscaleable (ie, it becomes more and more of headache as you pull in dependencies), but the language is much, much nicer to work with and read than Objective-C
I've been developing on iOS since it came out. It is better than ever. Swift is a great language in my opinion – feels very familiar to Objective-C, but is much lighter-weight, and I find that I can spin up projects much more quickly. The type-safety took some getting used to, but pays dividends and has made programs easier to expand and maintain. Plus, I get to pull in ideas from the functional programming community which is great.
Congrats to Chris Lattner and the others at Apple who were promoting this! I've been watching Swift develop from the initial announcement because it would be a bit like C#. A great backend language that gives you first-class access on one of the most popular platforms.
He may have heard it direct from Apple. They have a close partnership for developing enterprise iOS apps, and have been for almost two years.
I had no idea myself until I went to interview at IBM. I haven't had the opportunity to work with Swift professionally though, so they went with someone else. Possibly the OP :P
I'm hoping to see builds for other distros and Windows as well. I'm curious what GUI applications would be like for Swift on Linux. I hope we see a great new platform for development with Swift :)
If you just want to play with the REPL (usr/bin/swift in the Ubuntu 14.04 snapshot), all you have to do is:
apt-get install python-dev
If you want to actually compile swift files (usr/bin/swiftc in the Ubuntu 14.04 snapshot), it appears extremely basic programs will compile with jessie's clang-3.5, so all you have to do is:
apt-get install clang
Note that the swift.org instructions claim you need clang-3.6, and you probably do for more complex programs. For that, you'll need to temporarily add a sid/unstable source and upgrade clang:
And slightly more specific, Swift on Android :) LLVM compiles some code I'm working on to be part of an Android app; so it should not be too hard (as LLVM is Swift compiler backend).
I like that it's open source now, but until they remove the need to mark certain references as weak or unknown, it still just feels like Apple doesn't get modern languages. Until the automatic memory management is more automatic, I will avoid swift if I can. I know many will say it is "not a big deal", but that is not true. It is an extra thing the developer needs to keep track of and to get right if they want to prevent bugs in their code. It makes programming more stressful and less fun. It is something that is very easy make a mistake with. It is a step backwards from other technologies. I know ARC is supposed to be faster than other automatic memory management techniques, but that is just an excuse. Yes, lower performance could be a problem with fully automatic memory management. But problems were meant to be solved, not dumped onto the users of your language. I'm sure it is possible to get it fast enough for most projects. There should at least be a compiler option to enable fully automatic memory management for projects that don't need that extra bit of speed. Computers, including mobile devices, are getting faster and faster. This is especially true for the iPhone and iPad.
The Swift port for Linux seems to only support x86-64 for now. https://swift.org/blog/swift-linux-port/ I would like to see how swift could run on Linux ARM devices (Raspberry Pi 2/Beagleboard/etc) and other platforms; given that the runtime is already on iOS devices. Kudos to Apple for open-sourcing Swift.
Right now there is!: https://github.com/apple/swift Also, the dependencies to build swift looks fine to build it on other architectures. I'll try to build it for the Raspberry Pi 2 to see.
I don't know any other repl that can do that. I know you can debug in (some) lisps and smalltalk, but I don't know if you can set breakpoints too. Still a nice and welcome feature.
it is not there. https://github.com/apple is accessible .
i guess OP somehow found this website and put it into HN. I don't even see any press release by Apple related to this thing yet.
GNUstep developers stated several times that they'll implement bindings for Swift if it's released as open source. Though from my personal (and very limited) experience I may suggest that you won't use it for cross platform development. It's works on Linux reasonable well, but support for Windows is limited or at least it's was few years ago.
As a sometime Apple developer I do welcome this. Hopefully it will legitimise some of the grey (non-official) toolchains and support the development of tools and community that much of the rest of the software development world enjoys, and people won't be tied solely to Apple's own dev tools.
Does anybody else think it's a little strange though? To have open source tools solely to target a closed platform? I haven't used Swift myself but from what I've seen it seems to be something like Javascript with libraries for iOS, perhaps with a few semantic adjustments. Would that be a fair assessment?
I can't imagine it being used for much else beyond developing for iOS devices. Perhaps Macs. So while it's free as in "beer", but could it truly be said to be free as in "speech" in any substantial fashion?
It seems pretty consistent with functions in a set-notation sense, with functions that map a tuple of stuff to something else. The mapping being indicated by an arrow instead of a colon.
I was half-thinking the same, but types and sets feel interchangeable on an intuitive level in such cases.
Having both `: String` and `: String` seems to suggest that they are the same type, which they are not. `nameMe(_)` is a function type, while `name` is a "plain value", so to speak. I think that using arrows more clearly indicates that it's a mapping from something to something else -- in the case of Swift, I guess a mapping from a tuple to something else.
And think about anonymous functions, in general since I haven't looked into Swift anonymous functions. If you indicate a function like this:
`func nameMe(name: String) : String`
How are you supposed to indicate an anonymous function? Like this:
`(name: String) : String`
Then it seems to say that name is a type of String, which in turn is a type of String. I guess you could add something like a lambda to distinguish it:
`(λ name => name): String`
But now you've still effectively said that both `name` (a value of type string) is the same type as the anonymous function (a function with one argument). That's clearly wrong.
Using arrows for functions seems to be better when you start to want to talk about types and values by themselves, like:
Linux support was officially announced as part of the open source announcement, and Linux downloads are explicitly listed on the site. No need for hints.
EDIT: I'm joking of course. More likely, they realized they accidentally forgot to excise some incredibly sensitive private information from the repo's history and are working fast on it before they make the repo public again.
It's WAY too slow to load and most pages time-out for me... I understand the hug of death coming from HN and twitter and reddit (and God where from) but this is Apple-backed right?!
Now that swift is opensource i'm looking forward to some better tools being released for it. Right now xcodes support of swift is pretty lacking. No refactoring, and compile errors are fairly ambiguous sometimes.
Since this has linux support i wonder if xcode or something similar will be ported to linux.
I love this! I got say, that I've been a fan of Swift since the day Apple announced it. It's a such a beautiful language, with so many new paradigms implemented, safe and easy to learn.
I really hope this boosts the widespread of Swift. I'd love to use it for back-end dev for instance.
A number that I've seen thrown around: it takes 5 years to create a language. Probably less nowadays since we have all the tooling. It might make sense to wait until the language has settled-down before open-sourcing.
They're releasing the source code to libdispatch? I thought that was one of Apple's trade secrets, and more applicable than just Swift apps since it's a C lib?
It isn't necessary for iOS. It's still possible to write every part of an app in only Objective-C, as there are no Swift-only APIs. AFAIK, there are no indications of that changing any time soon.
At least read the ObjC interop document. You may be able to get away without writing any ObjC, but most of the libraries you'll be using, including Cocoa, are ObjC.
No, it uses "automatic reference counting"—it keeps a reference count of memory usage and frees it when it's no longer being referenced. And (for the most part) it automatically inserts the reference counting into your code during compilation. There are still some hints that you need to give it (like telling it about weak references to avoid reference loops, etc.)
Potentially mired in rights issues (since they originally acquired it from Macromedia, who may have not owned 100% of the codebase), or written so badly that vulnerabilities will be made very obvious by its open-sourcing.
No. This is a childish joke, and inappropriate. As a community of professionals, we should do everything we can to discourage this kind of crap.
Joe Cumbo (mooman219), I hope you never apply for a job I'm the hiring manager for, because I would never hire you after seeing this kind of unprofessionalism in your Github profile.
I likely agree with your sentiment, but I'm afraid I'm too ignorant to even realize there is any attempt at a joke. For my understanding of the culture, would someone mind explaining?
A company that is traditionally hostile to open source gets as one of its first "contributions" to a newly opened project a troll, confirming a bad stereotype of the open source community.
Well i'm by far not an expert. But a lot of people consider that GPL is an open but maybe too restrictive licence.
Notably, "derived works" using GPL copylefted code must be redistributed under same licence. So basicaly if you consider that Swift is a key component of OSX... This is just not something Apple can accept right now.
Beside I'm not even sure a Licence switch from Apache2 is possible without consent of all contributors. And most definitively a Licence switch can in no way be decided via a Pull Request :P
Doesn't work in x86, ubuntu 15.10,
bash: /home/user/Descargas/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu15.10/usr/bin/swift: no puede ejecutar el archivo binario: Formato de ejecutable incorrecto
So because Apple did some things one way 8 years ago, they need to do it exactly the same today or someone screwed up? Really??? Nothing changes in the modern world?
Fair enough. For my part, I would need to see a wider community supporting the language before I depended on it on non-Apple systems. I'll have to wait and see on that point. But that is a plausible outcome - and (in my opinion) more likely because they chose an open source license rather than a free software license.
yeah, very self consistent, pretend you care about the GPL, then decide it is the vendor you really care about. Who cares that Apple controls GPL software installed on almost every GNU/Linux machine?
- 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!