Earlier quoted context omitted.
I completely agree. Swift's lack of desalinization is a critical problem for users. :-) -Chris
When you add syntactic sugar, you don't need so much salt.
[deleted]
Looking back on Swift 3 and ahead to Swift 4
21–30 of 66 posts
Re: Looking back on Swift 3 and ahead to Swift 4
#22is 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.
Re: Looking back on Swift 3 and ahead to Swift 4
#23Wouldn't First class concurrency in a way breaks ABI and Stdlib as well? ( Otherwise it would be second class )
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.)
Re: Looking back on Swift 3 and ahead to Swift 4
#24> 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?
Well, how will Swift enforce that nobody outside of Apple distributes libraries that don't break ABI or API?
Re: Looking back on Swift 3 and ahead to Swift 4
#25I 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.?
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.
Re: Looking back on Swift 3 and ahead to Swift 4
#26Earlier quoted context omitted.
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.
Re: Looking back on Swift 3 and ahead to Swift 4
#27Why 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
Re: Looking back on Swift 3 and ahead to Swift 4
#28Perhaps, 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.
Re: Looking back on Swift 3 and ahead to Swift 4
#29> 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?
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
#30I'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?