10 ms·
Swift 3.0 Release Process
- tormeh 10y agoAnyone know how Swift performance compared to Scala? Those are pretty similar, I've heard. I'm pretty familiar with Scala, but not Swift. Is there any reason to switch to Swift?
- stepanhruda 10y agoI haven't seen any data. Scala has been around for a while, which means more time to spend on optimization, so it's probably faster at this point. Because of garbage collection on JVM, Swift has the potential to be more performant though. Unless you are trying to build some really high performance shit, what really matters is developer productivity, which is abysmal for server-side Swift right now. Getting better every day though. Source: built and deployed a service in Swift
- lennelpennel 10y agoI know you did not mean to say that scala code is non-performent. Well written jvm is highly performant and with GC algos like concurrent mark and sweep or garbage first and a good allocation of eden, tenured (etc) space you should really never have a stop the world because of GC'ing anymore.
- chillacy 10y agoWhile it's true you should never stop the world for CMS in a server-side program where you can control memory tuning, newgen collection is still stop-the-world, and can cause multi-millisecond pauses on ~8GB heaps.
- hocuspocus 10y agoThey aren't so similar. Feature-wise, Swift is much closer to Kotlin, which is (on purpose) significantly simpler than Scala. Also if you're using Scala, there's a huge ecosystem of libraries and frameworks that just doesn't exist in Swift. If you want native compilation, just wait for http://www.scala-native.org/ http://www.scala-native.org/
- proyb2 10y agoThat will rely on LLVM?
- fauigerzigerk 10y agoThe main thing to know about Swift performance is that it varies hugely depending on what you're trying to do. I think it will take some time for the implementation to mature to a point where it becomes less hit and miss performance-wise. Swift as a language has all it takes to create a consistently fast implementation. The wildcard is probably the decision to go with reference counting over a tracing GC. We'll see how that works out. There are good arguments on either side.
- igouy 10y ago> Swift performance compared to Scala? Depends how you write the code :-) http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=swift&lang2=scala http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
- bsaul 10y agoI've had a quick look on 3.0 changes and didn't find major features related to protocols. I'm thinking of things like more complex generic type constraints, or a mechanism to better code against protocols ( see all videos that talk about swift protocol oriented in "real life" and how annoying those limitations). Did i miss something ?
- gilgoomesh 10y agoThat was discussed by Apple Dev Douglas Gregor in a massive post here: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011666.html https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo... It's not clear what the schedule would be but I suspect a number of the constraints changes will be in Swift 3.
- kev009 10y agoIt looks like a really well thought out language, and the willingness to break some things that looked like C holdovers in 3.0 for future clarity is also interesting. I'm wondering if Swift will hit a sweeter spot than Go (GC, weird takes or delay on things like packaging, generics) and Rust (complexity) for userland systems software.
- Scarbutt 10y agoI'm wondering if Swift will hit a sweeter spot than Go I think Swift will be a Go killer.
- spriggan3 10y agoHow does Swift handles concurrency ? does it have CSP with channels, and a select statement ? because if it doesn't it's not going to kill anything.
- chrisamanse 10y agoSwift has Grand Central Dispatch (GCD) for running concurrent code
- wlesieutre 10y ago(But only on OS X and iOS)
- chrisamanse 10y agoYes, currently. But in the link, it states that "For Linux, Swift 3 will also be the first release to contain the Swift Core Libraries." And GCD (or libdispatch) is part of the Swift Core Libraries :)
- lobster_johnson 10y agoIsn't libdispatch fully implemented on Linux and *BSD?
- perfectstorm 10y agoMaybe I'm too old school but the removal of for loop is quite surprising. for-in doesn't tell you the index of the current object so you'd have to manually keep track of the index. Also, x++ is a common syntax in many languages and I think a new developer looking at Swift would try that first before using the other syntax (x += 1).
- fauigerzigerk 10y agoI think what a new developer would try first isn't a particularly good yardstick for language design. But I also think that the removal of ++ causes some problems. For instance, now I have this code mutating func next() -> Element? { //... pos += 1 return data[pos-1] } or alternatively mutating func next() -> Element? { //... let e = data[pos] pos += 1 return e } where previously I had mutating func next() -> Element? { //... return data[pos++] }
- chrisamanse 10y agoIMHO, ++ is not readable. A beginner would think that data[pos++] is the same as data[pos+1] when it's actually, data[pos]; pos = pos + 1;.
- fauigerzigerk 10y agoI don't care what beginners might think. I care about the mental load for professional developers. Beginners can learn.
- kartickv 10y agoA beginner should be made to learn something only if they get an advantage out of it in readability or type safety or performance or something else. I don't see that being the case for pre- and post-increment. If anything, I find: i += 1; String name = names[i]; more readable than String name = names[++i]; where I have to pause and remind myself of pre- and post- increment and which one is being used here and mentally translate the code into the above version. Imperative languages already have a way of specifying execution order: it's the order of statements in your file. Let's reuse that rather than making things more complex.
- fauigerzigerk 10y agoIt's good that they are making these breaking changes now. I like the language and the changes they are making. The next focus should be on performance in my view. String processing in particular is too slow to be usable for server-side tasks. Also, I wonder what to do with Foundation in the long run. It's huge but its design is extremely antiquated. At some point Apple will have to shed that past where URL manipulation and file system operations are methods on a string class.
- stepanhruda 10y agoFoundation is being completely rewritten in Swift in https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-foundation The first proposal for bringing Foundation APIs to this decade has already been accepted for Swift 3: https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md https://github.com/apple/swift-evolution/blob/master/proposa...
- fauigerzigerk 10y agoThese are small adaptations to Swift's semantics and naming guidelines. There is nothing in these documents that hints at the sort of root and branch redesign of the APIs that I think is necessary. Cocoa as a whole is obsolete and needs to be replaced by something better. It is the epitome of everything that is wrong with 1980s/1990s style object oriented design: Huge classes, massive coupling, very little cohesion.
- stevetrewick 10y agoWhile it's true that "the implementation of [all but 3 of] these types will use the existing reference type API", this means (AIUI) that there will now be a swifty shim between swift and Foundation rather than the types being bridged directly. I would expect that would make the job of replacing Foundation with something appropriately modern easier in several dimensions.
- kartickv 10y ago
- zerr 10y agoAny talks about Windows port?
- tp101 10y agoYou could take a look at http://www.elementscompiler.com/elements/silver/ http://www.elementscompiler.com/elements/silver/
- proyb2 10y agoMicrosoft staff have recently did a preview ported at Codeplex https://swiftforwindows.codeplex.com https://swiftforwindows.codeplex.com Disappointed, only for Windows 10.
- proyb2 10y agoToday I have submitted a proposal for "memorization", "memo", "memorize" keyword for a function that allows to run only once through out the lifecycle in Swift 3. Repeatedly execute the function will only return the same result without having to rerun the function everytime. As far as, I don't see my submission is being visible for discussion. memo func hello(fname: String, lname: String) { return fname.lname }
- seanalltogether 10y agoIs this not better suited to GCD operations? dispatch_once handles this exact use case.
- johndifool 10y agoHow about using `lazy` for a memoized function?
- proyb2 10y agoHaven't had experience in GCD, looks interesting, are there any tutorials I can read up other than Apple resources?
- Propen 10y agoI would love it if Swift could become the next-gen C++ for cross-platform development. The Apple platforms/Linux advances are great but is it ever going to be adopted on other platforms? I don't think Apple would care, it's mostly Lattner & the team behind pushing the language. (bless 'em :))
- proyb2 10y agoSwift is more like Java ecosystem than Rust is ideal as the next gen C++. Otherwise, Obj-C would have been popular when it tried to compete with C/C++. There was an article mentioning.
- chillacy 10y ago> compiles to native code, specific to a platform > deterministic runtime performance (no GC, no JIT) > lightweight "exceptions" Seems way more similar to C++ than java. Also Obj-C's success or failure as a C replacement (I can't imagine using it as one... it's not going to run well on embedded devices) has little to do with swift's future path besides that both languages are heavily used at apple. The key difference may be that Chris Lattner is basically a compiler superstar, and I think he could make it happen if he chose to.
- rzhikharevich 10y agoWhat I really miss is a proper compiler for Swift. I've encountered two bugs in the last few days: one in the IRGen and the other one in the TypeChecker. That can be really annoying. And that error "expression is too complex to evaluate" is just ridiculous.
- shrugger 10y agoI did not realize that we were this close to Swift 3?! This is really awesome news. I'm pretty excited to see what they do in 3.0, I'd love to have another language under my belt without fooling around with NS-nonsense. That they might actually take Linux desktop seriously is really exciting to me also. I'd love to see a widely-used tool where games and popular apps that would traditionally be put out on Win/Mac are able to be used seamlessly on Linux also. On top of that, I definitely don't want to write Java, I definitely don't want to write ObjC, etc. Interestingly enough, I think this might even compete with Dart, which I suspect will end up getting Wasm support and ultimately replacing Java for android development... (Just a wild shot in the dark...) So I can't wait to see what the Swift starts brewing up in the Concurrency department. How exciting!
- plorkyeran 10y ago> I did not realize that we were this close to Swift 3?! WWDC is June 13-17, so they basically have to have something ready by then. Not so coincidentally, June 13 is "4-6 weeks later" from the May 12 date for making the release branch. Similarly, the late 2016 release for the final version of Swift 3.0 is probably actually mid September, since the version of Xcode with iOS 10 support has to ship before the next iPhone model. Hurrah for marketing-driven release schedules.
- bla2 10y agoIt'd be nice if they stopped breaking the language at some point. I don't want to rewrite my program every year. I would have called that future stable version 1.0 (like, say, Go and Rust did).
- donut2d 10y agoVersion 3.0 is supposed to have a much stabler API going forward. They've been making a lot of changes even since 2.2 that really clean up the standard library.
- jorgeleo 10y agoI really don't like the way that objective c express everything, so i was looking forward to Swift. This tells me that Swift is not ready for prime time 3 versions later: "Swift 3.0 is a major release that is not source-compatible with Swift 2.2. It contains fundamental changes to the language and Swift Standard Library. A comprehensive list of implemented changes for Swift 3.0 can be found on the Swift evolution site." Fundamental changes??? Let me know when is stable across versions.
- danappelxx 10y agoThe reason there are so many fundamental changes right now is because they want to stuff all breaking changes into Swift 3, and be stable after that (naturally with new features going onwards, though). Once Swift 3 comes out the language will be very stable.
- chillacy 10y agoSince apps include the swift runtime library though, changes won't interfere with your current apps.
- hetman 10y agoI was hoping to see some changes to the error handling. The extensive use of implicitly unwrapped properties always makes me nervous because basically we still have the null pointer dereference problem. Also, optional chaining seems really well geared to the use case where silent failures area OK, but things get ugly quickly when trying to handle individual errors. Maybe I've just been spoilt by Rust, which I've been learning at the same time, but their approach to error handling seems much more holistic and less tacked on than in Swift. I'd definitely like to see more done with this because that feels like the only complaint I have with the language.
- proyb2 10y agoI was hoping all Swift professional are motivated to contribute patches, features and tuning performance to Swift 3.0 in a swift pace instead of until 2017. Release Process is such a lengthy discussion that could have been shorten and spending more time on improving code. Why not using JIRA?