Looking back on Swift 3 and ahead to Swift 4(lists.swift.org)
lists.swift.org
Looking back on Swift 3 and ahead to Swift 4
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
65 comments
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...
The news here is really an update that they're still thinking about it and it won't be in Swift 4.
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.
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:
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
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).
Can you expand on the memory model?
Got any links with more information?
Got any links with more information?
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.
- 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.
Some more information is here:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...
-Chris
-Chris
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.
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.
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 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.
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.
Message passing, it seems, is the basis for implementation of protocols, be it communication between objects in a hierarchy or between actors/processes in a system or nodes in a network.
It is not coincidence that message passing is the core concept in the original OO paradigm and in design of fault-tolerant distributed systems. Cells do message passing too.
I am not sure what is being copied here. Messages are just structured data (a molecule) in otherwise share-nothing architecture.
It is not coincidence that message passing is the core concept in the original OO paradigm and in design of fault-tolerant distributed systems. Cells do message passing too.
I am not sure what is being copied here. Messages are just structured data (a molecule) in otherwise share-nothing architecture.
>It is not coincidence that message passing is the core concept in the original OO paradigm and in design of fault-tolerant distributed systems. Cells do message passing too.
This is not about "fault-tolerant distributed systems" though, but for "performance-first" for very CPU and memory expensive programs (video and audio processing, number crunching, etc).
This is not about "fault-tolerant distributed systems" though, but for "performance-first" for very CPU and memory expensive programs (video and audio processing, number crunching, etc).
Joe Armstrong thinks it is.
I doubt Joe Armstrong said anywhere that message passing can be as fast as shared memory for those kinds of applications.
He advocates "fail-fast" and "share-nothing" as fundamental principles - that's the point. With no sharing a failure of a single process affects no other, unlike threads with shared stack and state. For the same reasons Erlang is functional language with single bindings. Sharing of immutable data is OK, so message passing might be implemented using OS shared memory services.
>He advocates "fail-fast" and "share-nothing" as fundamental principles - that's the point.
He advocates those for totally different use cases.
He advocates those for totally different use cases.
[citation needed]
Wouldn't First class concurrency in a way breaks ABI and Stdlib as well? ( Otherwise it would be second class )
>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.
Well, theoretically you can add new syntax without altering/affecting existing syntax and programs, and similarly for ABI.
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.
I don't think so, it means that the stdlib team will adhere to the requirements for ABI compatibility and the compiler will support this.
Third party vendors will have to adhere to the same requirements to be ABI compatible, because not all changes will be compatible.
Third party vendors will have to adhere to the same requirements to be ABI compatible, because not all changes will be compatible.
Well, how will Swift enforce that nobody outside of Apple distributes libraries that don't break ABI or API?
While a compile can't enforce APIs, the ABI generated by compiler.
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.
So, for C++, a good document about keeping ABI compatibility: https://community.kde.org/Policies/Binary_Compatibility_Issu...
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.?
Does anyone who uses Swift on Linux have any comments, suggestions, use cases, etc.?
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.
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.
[deleted]
is offical Windows support planned?
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.
Would it not work under the new Linux subsystem for Windows at least?
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)
>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.
It's designed first and foremost for developers deploying on UNIX/Linux.
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?
There has been some community work on Windows, no official promises but IIRC there is already very basic support.
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
You don't even need much css: http://bettermotherfuckingwebsite.com
Yeah it amazes me that an Apple hosted page is unusable on an iPhone because they don't customize their installation.
Best website designe ever!
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.
Of course bettermotherfuckingwebsite.com uses #444 on white. bestestmotherfuckingwebsite.com probably dials it up to #777 with a light sans-serif.
> 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.
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.
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."
So your criticism seemed out of touch and (can't believe I'm quoting pg) "middlebrow."
If not anything else, it’s pain to read on mobile. That could be easily fixed without compromising any of the good parts.
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...
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.
I completely agree. Swift's lack of desalinization is a critical problem for users. :-)
-Chris
-Chris
When you add syntactic sugar, you don't need so much salt.
But it might cause cancer of the semicolon :)
[deleted]
You should do an IAMA.
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.)
(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.)
The people over at https://news.ycombinator.com/item?id=12191089 might have something to say about that!
oops I think you commented the wrong thread
This seems to happen enough that I'm curious if people are using funny clients (though alikhan82 is new as of 5 hours ago) or if there's a race in the HN code. It seems improbable that someone would be typing this desalination comment into this article and not the one about Israeli desalination projects. @alikhan82 are you using the standard web page or accessing HN through some other client?
I don't find it that improbable to think it may have been typed into the wrong page by the user. If you open a lot of HN discussion pages first and then open the articles they link to via the discussion pages in new tabs and you switch to read an article (like I do) and you then go back to comment on it, I can see how someone ends up commenting in the wrong thread. Especially, I think, it would be easy to make that mistake if you have a strong opinion about the matter of the article because if you get worked up and eager to say something about it, you might be more focused on the comment entry box and not notice that the title and other comments don't match.
Well, that was meant to go here I guess...
https://news.ycombinator.com/item?id=12191089
https://news.ycombinator.com/item?id=12191089
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.