Live data from Hacker News

Looking back on Swift 3 and ahead to Swift 4

lists.swift.org

51–60 of 66 posts

Re: Looking back on Swift 3 and ahead to Swift 4

#51
post #13

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!

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

Re: Looking back on Swift 3 and ahead to Swift 4

#52

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

You should do an IAMA.

Re: Looking back on Swift 3 and ahead to Swift 4

#53
post #9

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.

Re: Looking back on Swift 3 and ahead to Swift 4

#54
post #28

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

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

So copy on write ends up being copy.

Re: Looking back on Swift 3 and ahead to Swift 4

#55
post #28

Earlier 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…

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

Re: Looking back on Swift 3 and ahead to Swift 4

#56
post #12

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.

I could maybe agree with you on the message-passing thing (was about to upvote you). But then you mentioned macros.

The macros he mentioned is the same the Swift team mentions -- hygienic modern macros, not some C-like crude text replacement system.

Re: Looking back on Swift 3 and ahead to Swift 4

#57

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

#58
post #13

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!

Can you expand on the memory model? Got any links with more information?

Some more information is here: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...

-Chris

Re: Looking back on Swift 3 and ahead to Swift 4

#59
post #29
post #24

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

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.

Re: Looking back on Swift 3 and ahead to Swift 4

#60
post #59
post #29

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

So, for C++, a good document about keeping ABI compatibility: https://community.kde.org/Policies/Binary_Compatibility_Issu...
Post reply on HN