
Looking back on Swift 3 and ahead to Swift 4 - dalbin
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
======
dak1
> \- 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.

~~~
gilgoomesh
Discussion on this issue began at least 10 months ago, according to the
"Concurrency" proposal in the repository:

[https://github.com/apple/swift/blob/master/docs/proposals/Co...](https://github.com/apple/swift/blob/master/docs/proposals/Concurrency.rst)

The news here is really an update that they're still thinking about it and it
won't be in Swift 4.

------
DAddYE
I'm very happy that Apple open sourced Swift.

Chris and his crew are amazing and the vibrant community definitely
helps/challenge them and will bring us things like:

    
    
      - concurrency (at least planned)
      - cyclone/rust memory model!
      - scripting 
      - syntactic sugras
    

Congrats!

~~~
the_duke
Can you expand on the memory model?

Got any links with more information?

~~~
dolguldur
I assume you read this from the post:

\- Memory ownership model: Adding an (opt-in) Cyclone/Rust inspired memory
ownership model to Swift is highly desired by systems programmers and folks
who want predictable and deterministic performance (for example, in real time
audio processing code). More pertinent to the goals of Swift 4, this feature
is important because it fundamentally shapes the ABI. It informs code
generation for “inout", how low-level “addressors” work in the ABI, impacts
the Swift runtime, and will have a significant impact on the type system and
name mangling.

------
spotman
Wow quite intriguing and exciting that swift 4 may have a rust inspired memory
model!

Can definitely see the use case for swift expand a bit with this in its wings.

------
jernfrost
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.

~~~
pjmlp
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.

------
dschiptsov
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.

~~~
bsaul
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.

~~~
nielsbot
doesn't copy on write + "immutable" solve the copying problem?

~~~
coldtea
The whole problem is that for speed you DO need the "write".

So copy on write ends up being copy.

------
ksec
Wouldn't First class concurrency in a way breaks ABI and Stdlib as well? (
Otherwise it would be second class )

~~~
coldtea
> _Wouldn 't First class concurrency in a way breaks ABI and Stdlib as well? (
> Otherwise it would be second class )_

Well, theoretically you can add new syntax without altering/affecting existing
syntax and programs, and similarly for ABI.

------
kibwen

      > 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?

~~~
ori_b
Well, how will Swift enforce that nobody outside of Apple distributes
libraries that don't break ABI or API?

~~~
omeid2
While a compile can't enforce APIs, the ABI generated by compiler.

~~~
ori_b
The ABI is generated by the compiler in response to the code it is given. If
you don't control the code, you can't guarantee an ABI. If you change the
types of function arguments -- for example, adding fields to structs that are
passed by value -- you will break ABI, even if the compiler doesn't change.

~~~
ori_b
So, for C++, a good document about keeping ABI compatibility:
[https://community.kde.org/Policies/Binary_Compatibility_Issu...](https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#Note_about_ABI)

------
mark_l_watson
I just run Ubuntu now but I like the features of Swift.

Does anyone who uses Swift on Linux have any comments, suggestions, use cases,
etc.?

~~~
Garthex
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.

------
coldcode
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?

~~~
rsneekes
It's available in the Xcode 8 betas, so probably with the release of the
iOS10/macOS GMs.

------
drivebyops
is offical Windows support planned?

~~~
themihai
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.

~~~
mozumder
Would it not work under the new Linux subsystem for Windows at least?

~~~
themihai
I don't know. From the microsoft docs I understand that it has some
limitations so most likely it won't work without some patching. Why would you
use a linux subsystem instead of "native" linux anyway? It seems designed for
sys admins who don't like windows (quite funny)

~~~
coldtea
> _It seems designed for sys admins who don 't like windows (quite funny)_

It's designed first and foremost for developers deploying on UNIX/Linux.

~~~
themihai
I don't know what that means. Deploying on UNIX/Linux usually means uploading
the code somewhere using a standard protocol (i.e. ftp ) or proprietary API.
Part of that you need to execute a program so I'm wondering, what makes
deploying more special than any other program?

------
legulere
Why does mailing list archival software not contain basic css? Long lines make
it hard to read the text.

You don't even need much css:
[http://bettermotherfuckingwebsite.com](http://bettermotherfuckingwebsite.com)

~~~
superswordfish
Have you seriously never seen mailman before? You must've taken a wrong turn
getting here.

Of course bettermotherfuckingwebsite.com uses #444 on white.
bestestmotherfuckingwebsite.com probably dials it up to #777 with a light
sans-serif.

~~~
legulere
> Have you seriously never seen mailman before?

Sure I have, and every time I'm annoyed by the archive site layout.

> You must've taken a wrong turn getting here.

No need to get personal, take a step back cool down and don't take things so
serious.

> Of course bettermotherfuckingwebsite.com uses #444 on white.

Yeah it's also a bit too bright for my taste, but the general point still
holds.

~~~
superswordfish
Fair enough, I saw it as an attack on no-frills developer-oriented content in
favor of some notion of beauty. Mailman pages, like most GNU HTML, are simple
and excellent. They're accessible, resize predictably, readable, and they fill
the window. They're light and download quickly. They have high information
density. It's sort of baffling how narrowing the content, reducing contrast
and increasing line height are an improvement over browser defaults. And if
you want pages to look like that by default, you can put
bestmotherfuckingwebsite.com's CSS in your browser's default stylesheet.

So your criticism seemed out of touch and (can't believe I'm quoting pg)
"middlebrow."

~~~
zoul
If not anything else, it’s pain to read on mobile. That could be easily fixed
without compromising any of the good parts.

~~~
superswordfish
Worth noting that that is best fixed with a "viewport" <META> tag rather than
CSS: [https://developer.mozilla.org/en-
US/docs/Mozilla/Mobile/View...](https://developer.mozilla.org/en-
US/docs/Mozilla/Mobile/Viewport_meta_tag)

------
alikhan82
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.

~~~
chrislattner
I completely agree. Swift's lack of desalinization is a critical problem for
users. :-)

-Chris

~~~
agildehaus
When you add syntactic sugar, you don't need so much salt.

~~~
signa11
But it might cause cancer of the semicolon :)

