> - First class concurrency: Actors, async/await, atomicity, memory model, and related topics. This area is highly desired by everyone, as it will open the door for all sorts of new things on the client, server and more. We plan to start formal <i>discussions</i> about this in Phase 2, but it is unfortunately crystal clear that a new concurrency model won’t be done in time for the Swift 4 release. This is simply because it will take more than a 12 months to design and build, and we want to make sure to take time to do it right. It also makes sense for the memory ownership model to be better understood before taking this on.<p>It's great to hear planning and discussion on this is beginning, and that they're being honest upfront about the timeline to see it implemented.
I'm very happy that Apple open sourced Swift.<p>Chris and his crew are amazing and the vibrant community definitely helps/challenge them and will bring us things like:<p><pre><code> - concurrency (at least planned)
- cyclone/rust memory model!
- scripting
- syntactic sugras
</code></pre>
Congrats!
Wow quite intriguing and exciting that swift 4 may have a rust inspired memory model!<p>Can definitely see the use case for swift expand a bit with this in its wings.
Awesome things in store for Swift. With Rust like memory model as alternative and async/await I think it will massively broaden the appeal of Swift. I can start to see Swift taking over as the main mainstream language in the future. Java and C# has just accumulated too much cruft, they will be the new C++ languages. You can do anything but you have to accept a lot of complexity and awkward syntax to do that.
Perhaps, one should borrow message-passing as a standard language idiom, actors and pattern matching on receive from Erlang, the way Akka did, instead of copying hat async/await ugly hacks.<p>Message passing as a core concept of a language is fundamental and necessary (given that interlop with ObjC is important), and having that and macros gives related control structures for free.
<p><pre><code> > For Swift 4, the primary goals are to deliver on the
> promise of source stability from 3.0 on, and to provide
> ABI stability for the standard library.
</code></pre>
Hm, does this imply that only the stdlib will have the benefit of a stable ABI? IOW, that it won't be possible to distribute compiled artifacts built with different versions of the compiler and expect them to link properly?
The question I still have, is when will Swift 3.0 release be available in Xcode and for Linux use? The comment of Swift 3.X release in spring 2017 can't be 3.0, or am I missing something?
Why does mailing list archival software not contain basic css? Long lines make it hard to read the text.<p>You don't even need much css:
<a href="http://bettermotherfuckingwebsite.com" rel="nofollow">http://bettermotherfuckingwebsite.com</a>
Kind of an incomplete article as there is no mention of the environmental cost. Desalination is not a magic solution. Everything is a trade off. Desalination means pumping salt back into the ocean which just compounds the problem.