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!
Looking back on Swift 3 and ahead to Swift 4
51–60 of 66 posts
Re: Looking back on Swift 3 and ahead to Swift 4
#52Kind 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
Re: Looking back on Swift 3 and ahead to Swift 4
#53Wouldn'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.
Re: Looking back on Swift 3 and ahead to Swift 4
#54Earlier quoted context omitted.
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.
doesn't copy on write + "immutable" solve the copying problem?
So copy on write ends up being copy.
Re: Looking back on Swift 3 and ahead to Swift 4
#55Earlier quoted context omitted.
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.
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…
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).
Re: Looking back on Swift 3 and ahead to Swift 4
#56Perhaps, 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.
I could maybe agree with you on the message-passing thing (was about to upvote you). But then you mentioned macros.
Re: Looking back on Swift 3 and ahead to Swift 4
#57Earlier quoted context omitted.
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's designed first and foremost for developers deploying on UNIX/Linux.
Re: Looking back on Swift 3 and ahead to Swift 4
#58I'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!
Can you expand on the memory model? Got any links with more information?
-Chris
Re: Looking back on Swift 3 and ahead to Swift 4
#59Earlier quoted context omitted.
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.
Re: Looking back on Swift 3 and ahead to Swift 4
#60Earlier quoted context omitted.
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.