Swift is Open Source
swift.org
swift.org
- 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!
Are new versions backwards compatible?
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....
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!
The Core Foundation stuff (included in swift-corelib-foundation) has been open for a while: http://www.opensource.apple.com/source/CF/
"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"
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.
First ever commit found here https://github.com/apple/swift/commit/afc81c1855bf711315b8e5...
EDIT: License/Header in each of files were apparently retroactively added.
(For simplicity, assume I am the only author of the repo, so I can always change the license arbitrarily whenever I want to.)
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.
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.
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?
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.
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).
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.
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?).
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).
Saved for posterity: https://archive.is/n8iIl
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.
Interesting that they started with git, instead of even a very small section of working code first
Edit: Also jckarter the creator of the Clay programming language is in there too!
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?
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.
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."
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?
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 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.
Then, shortly after Sun acquisition, Oracle closed the Solaris code and got away with all contributors' copyrights.
http://www.slideshare.net/bcantrill/fork-yeah-the-rise-and-d...
The direct link to the Oracle part:
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.
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.
Can you explain what's ridiculous about the part of my comment that you quoted?
A previous HN thread about the swift-compiler-crashes project: https://news.ycombinator.com/item?id=9020206
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.
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].
Cheers!
[1] https://developer.apple.com/spritekit
[2] http://www.raywenderlich.com/category/sprite-kit
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)
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.
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.
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.
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.
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?
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.
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.
They both solve a lot of the same problems, but lots of people will go for Kotlin just for static typing.
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.
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.
[1] https://twitter.com/mxcl/status/608682016205344768
[2] https://www.linkedin.com/in/maxhowell
[3] https://github.com/apple/swift-package-manager/graphs/contri...
[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'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
Both Cocoapods and Carthage should eventually be phased out with an official package manager.
https://github.com/apple/swift-package-manager/graphs/contri...
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.
They recruited me through the code jam, but hey.
[1] https://www.reddit.com/r/apple/comments/1xuzif/what_ever_hap...
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/...
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.
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.
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?
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?
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.
I guess that says it all.
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.
https://github.com/apple/swift/pulls?utf8=%E2%9C%93&q=is%3Ap...
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 :)
>I think we should use GPL v3 instead.
I really enjoy Github as a technology platform. As a social network, not so much.
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.
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 dangerous and wrong idea.
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.
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.
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).
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.
Particularly in combination with Web Assembly. I wouldn't be surprised if there is already an LLVM bitcode > WASL compiler in progress.
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.
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
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.
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.
That being said, C++ is probably a better choice, because dynamic dispatch sucks and there's better platform support.
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.
Saying it was "quite a pain" is the understatement of the year.
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.
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."
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
Welcome to Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 778f82939c). Type :help for assistance.
1> help
1>
export SDKROOT=$HOME/swift/usr
or
export SDKROOT=$HOME/swift/usr/lib
or
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.
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
Also
swift -I/usr/lib/swift swifthello.swift
<unknown>:0: error: opening import file for module 'Swift': No such file or directory
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...
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.
# xcrun --sdk iphoneos clang [...]
# xcrun --sdk iphoneos --find clangYou'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.)
It's not just you! http://swift.org looks down from here.
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.
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.
inline fun <T, R> with(receiver: T, f: T.() -> R): R
with(list) {
add(item)
add(item)
}
Another thing that's bit me in butt recently is that `Protocol`s aren't concrete types, unlike an `interface` in Java/Kotlin.
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.
Edit: also, look at https://github.com/apple/swift-corelibs-libdispatch so those libraries should be portable.
Oh, and syntax-wise I like both of 'm. I was not referring to syntax much, mostly to capabilities.
IMHO, Dart is a much more interesting applications language. And it will soon run on iOS (see http://flutter.io)
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 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?)
Since Swift is pushed by Apple, it probably won't suffer from the same ecosystem problems.
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.
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).
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.
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?
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.
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!".
You might really like Haskell :)
http://www.h4labs.com/dev/ios/swift.html
It can be viewed daily or weekly, if you're only interest in recent blogs:
http://www.h4labs.com/dev/ios/swift.html?date=0
http://www.h4labs.com/dev/ios/swift.html?week=0
Finally, all the data is on Github:
EDIT: Works at IBM. SORRY.
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
https://www.apple.com/pr/library/2014/07/15Apple-and-IBM-For...
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
apt-get install clang
echo 'deb http://ftp.us.debian.org/debian/ unstable main' >> /etc/apt/sources.list
apt-get update
apt-get install clang
<unknown>:0: error: opening import file for module 'SwiftShims': No such file or directoryI haven't gotten it to build yet, maybe I should read the manual, but I'm a man, damnit, so I'll do that once I've tried absolutely everything else.
https://swift.org/lldb/#why-combine-the-repl-and-debugger
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.
That will surely be taking up some of the dev't that would otherwise be done in Go.
https://github.com/apple/swift-package-manager/blob/master/D...
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?
func hello(name: String) -> String { }
rather than,
func hello(name: String) : String { }
I think, the function type :
(Int, Int) -> Int
may have been the main reason, but having
(Int, Int) : Int
func nameMe(name: String, calName: ((Int, Int) : Int))
would still have worked, and made the syntax more aesthetic.
var name : String
func nameMe(name: String) : String
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:
`1: Int`, `"hello": String`, `(λx => x) : a -> a`
BTW
Fat arrow looks more appealing than simple arrow.
All the other pieces look very well designed.
#if os(Linux)
import Glibc
#else
import Darwin.C
#endif
https://swift.org/source-code/ https://github.com/apple/swift
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.
But I wonder if it will fare better than Objective-C outside Apple eco-systems without the tools and OS libraries...
This organization has no public repositories.
Edit: Though I suppose the tools are only provided as binaries.
Since this has linux support i wonder if xcode or something similar will be ported to linux.
They already have support for swift in AppCode, but surely a community edition "SwiftStudio" can't be too much to wish for.
It worked wonders for Android development outside of Eclipse.
I really hope this boosts the widespread of Swift. I'd love to use it for back-end dev for instance.
commit 18844bc65229786b96b89a9fc7739c0fc897905e
Author: Chris Lattner <clattner@apple.com>
AuthorDate: Sat Jul 17 23:50:59 2010 +0000
Commit: Chris Lattner <clattner@apple.com>
CommitDate: Sat Jul 17 23:50:59 2010 +0000
initial swift testOpen Office for example had a long life as the proprietary "Star Office". Blender too IIRC.
And probably I am more excited not about the open-sourcing of it, but that there will be a package manager [0].
This might just be the thing to cross the "native" on my language learning checklist.
git clone git@github.com:apple/swift.git swift
but you can use:
git clone https://...../apple/.... swift
and the same for the remaining libraries.
git clone git@github.com:apple/swift.git swift
https://libdispatch.macosforge.org/post/libdispatch-is-open-...
Edit: And now it's on GitHub.
Its developer's way to say FIRST
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.
Exactly how is this inappropriate?
How could that not be considered inappropriate?
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
Feel free to correct me if I missed a point ;)
Pentium(R) Dual-Core CPU T4500 @ 2.30GHz × 2
WebKit.org, for instance, is registered with CSC Corporate Domains the same as apple.com, and is hosted on an Apple-owned IP block.
Perhaps a (further) indication this isn't ready for prime time yet?
Good grief, not everything is some mysterious conspiracy or some such nonsense.
No, I'd be saying that about any other vendor who released code under a proprietary open source license, too.
> Who cares that Apple controls GPL software installed on almost every GNU/Linux machine?
How exactly do you think they do that?