> - 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 discussions 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.
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.
Unfortunately, the free version of Foundation, the library that implements the features lacking in Swift's standard library is still dreadfully incomplete (eg. networking is unusable).
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.
I like Swift, but they have a pile of work in front of them to make Swift a reasonable proposition against those languages outside the Apple ecosystem.
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.
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.
Message passing unfortunately means everything is copied rather than pointed at. Which, in the case of a smartphone is always the beginning of performance or memory related problems.
I think rust approach of having strong guarantees over memory ownage, and thus being able to share memory in a safe way, is a better direction for swift.
From what I gathered from the email, first class concurrency won't be in swift 4 either way, just that they want to start talking about it in phase 2. Their separation of stage 1 (ABI-breaking changes) and stage 2 (non-ABI-breaking changes) was in regards to how they prioritize swift 4 tasks. (In other words, the discussion itself won't introduce any ABI-breaking changes, so there's no need to make sure it gets done in phase 1.)
> 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.
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?
So far, so good. In initial testing, I was able to plug into glfw just fine. Libc is available on both macOS and linux, and it has pretty good support for interfacing with C libraries. That provides a good basis for cross-platform development, IMO.
I haven't dug into testing Foundation support yet. From what understand, it's mostly implemented and they're working on finishing it. Also right now they only support 64bit OSes and only have prebuilt binaries for Ubuntu 15.10 and 14.04.
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?
Apple has no interest to provide Windows support. They support linux because it's the most used backend OS and on top of that it's Open Source. Fortunately Swift is open source so anyone can contribute and make Windows an official port. The same happened with Go.
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.
You're in the wrong place, but your argument doesn't make much sense either. The water also quickly ends up back in the ocean. Salt levels don't change.
(You could argue about a miniscule temporary rise in salt levels, but that's more than counteracted by drained reservoirs and melted glaciers, which means the plants are actually minusculely helping the environment be closer to where it was historically.)
[+] [-] dak1|9 years ago|reply
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.
[+] [-] gilgoomesh|9 years ago|reply
https://github.com/apple/swift/blob/master/docs/proposals/Co...
The news here is really an update that they're still thinking about it and it won't be in Swift 4.
[+] [-] DAddYE|9 years ago|reply
Chris and his crew are amazing and the vibrant community definitely helps/challenge them and will bring us things like:
Congrats![+] [-] paxcoder|9 years ago|reply
[+] [-] the_duke|9 years ago|reply
Got any links with more information?
[+] [-] spotman|9 years ago|reply
Can definitely see the use case for swift expand a bit with this in its wings.
[+] [-] jernfrost|9 years ago|reply
[+] [-] pjmlp|9 years ago|reply
[+] [-] dschiptsov|9 years ago|reply
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.
[+] [-] bsaul|9 years ago|reply
I think rust approach of having strong guarantees over memory ownage, and thus being able to share memory in a safe way, is a better direction for swift.
[+] [-] knocte|9 years ago|reply
[+] [-] ksec|9 years ago|reply
[+] [-] coldtea|9 years ago|reply
Well, theoretically you can add new syntax without altering/affecting existing syntax and programs, and similarly for ABI.
[+] [-] Garthex|9 years ago|reply
[+] [-] kibwen|9 years ago|reply
[+] [-] sitharus|9 years ago|reply
Third party vendors will have to adhere to the same requirements to be ABI compatible, because not all changes will be compatible.
[+] [-] ori_b|9 years ago|reply
[+] [-] mark_l_watson|9 years ago|reply
Does anyone who uses Swift on Linux have any comments, suggestions, use cases, etc.?
[+] [-] Garthex|9 years ago|reply
I haven't dug into testing Foundation support yet. From what understand, it's mostly implemented and they're working on finishing it. Also right now they only support 64bit OSes and only have prebuilt binaries for Ubuntu 15.10 and 14.04.
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] coldcode|9 years ago|reply
[+] [-] rsneekes|9 years ago|reply
[+] [-] drivebyops|9 years ago|reply
[+] [-] themihai|9 years ago|reply
[+] [-] joewillsher|9 years ago|reply
[+] [-] legulere|9 years ago|reply
You don't even need much css: http://bettermotherfuckingwebsite.com
[+] [-] smackfu|9 years ago|reply
[+] [-] NEDM64|9 years ago|reply
[+] [-] superswordfish|9 years ago|reply
Of course bettermotherfuckingwebsite.com uses #444 on white. bestestmotherfuckingwebsite.com probably dials it up to #777 with a light sans-serif.
[+] [-] alikhan82|9 years ago|reply
[+] [-] chrislattner|9 years ago|reply
-Chris
[+] [-] Dylan16807|9 years ago|reply
(You could argue about a miniscule temporary rise in salt levels, but that's more than counteracted by drained reservoirs and melted glaciers, which means the plants are actually minusculely helping the environment be closer to where it was historically.)
[+] [-] labrador|9 years ago|reply
[+] [-] boterock|9 years ago|reply
[+] [-] the_duke|9 years ago|reply
https://news.ycombinator.com/item?id=12191089