Live data from Hacker News

Looking back on Swift 3 and ahead to Swift 4

lists.swift.org

31–40 of 66 posts

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

#31

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.

Well, that was meant to go here I guess...

https://news.ycombinator.com/item?id=12191089

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

#33

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?

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

#34
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.

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

#35
post #28

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.

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

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

#36

Earlier quoted context omitted.

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)

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

#37

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

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.

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

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

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.

Post reply on HN