11 ms·

WWDC 2018 What's New in Swift Recap

75 points by jtbrown 8y ago

swyx 8y ago
has swift made the leap to server side yet? i keep hearing mumblings about that.
- dep_b 8y ago
  Vapor apparently gets favorable reviews by those who drank the Kool-Aid: https://vapor.codes/ https://vapor.codes/ Never tried it though. I don't select stacks primarily based on programming language.
  - willio58 8y ago
    I’ve used it for a few sites at this point. Haven’t used v3 but it’s been a great resource. It’s a cool experience coding a website with a compiled language, especially swift.
  - abalone 8y ago
    Vapor looks like the best so far but it's still early days. In theory it has the potential to be extremely fast and memory efficient, but for example they only just got a couple TechEmpower benchmarks up a couple days ago and they ranked very low (#162 on the json test).[1] It goes without saying simplistic benchmarks like this are flawed but at the same time, you have to start somewhere. [1] https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=json https://www.techempower.com/benchmarks/#section=data-r16&hw=...
    - dep_b 8y ago
      JSON performance is super important for a server, far more than for the usual macOS or iOS clients. JSON parsing might be based on the basic JSON parser found in Swift, which isn't fast at all, rather easy to use and secure instead. It's not super up-to-date but you can see there's definitely some competition even on Swift level in terms of JSON performance. https://github.com/bwhiteley/JSONShootout https://github.com/bwhiteley/JSONShootout Swift JSON encoding/decoding should approach C/C++ levels of performance when optimized for speed.
      - abalone 8y ago
        The plaintext benchmark was also slow, so the JSON implementation may not be the main cause here.
- thanatos_dem 8y ago
  In addition to Vapor which other commenters have mentioned, Apple itself released Swift-NIO, a port of Netty to Swift that they’re actively developing - https://github.com/apple/swift-nio https://github.com/apple/swift-nio It’s somewhat lower-level than web frameworks people may be used to coming from a Ruby/Node background, but it’s pretty powerful.
- wsc981 8y ago
  There's the Perfect [0] library that I recently used to develop a real-time multiplayer TicTacToe proof of concept for iOS. I used the Perfect web socket functionality on the server. Worked out well enough. --- [0]: https://perfect.org https://perfect.org
marvel_boy 8y ago
"Faster builds" How compares with Objective-C compile times?
- dep_b 8y ago
  Still not as fast and probably Objective-C got a speed boost as well. Objective-C is a very simple language and types are quite explicit. In Swift you have implied types like: let result = jsonList.map { Class(from: $0) }.filter { $0.isSelected }.map { T(from: $0 } Or worse: let myDict = ["key": 1, "key2": 0.2, "key3": "something"] It has to figure out it's not an int, not a number but an Any dict. Complexity to figure out the real type can quickly ramp up.
  - viraptor 8y ago
    Type inference, at least for variables doesn't really take that much time. In practice almost every language does it, they just don't expose it to the developer. For example you can do this in C: foo->bar()->baz() And the compiler has to get the type for the bar() result. That's one a small step from: let x = foo->bar() Also that dictionary is most likely parsed and assigned a type in the expression whether you specify the variable type or not.
    - hamstergene 8y ago
      That is way too oversimplified case of type inference. A huge lot of languages don't have this: let x = (f ? makeDerived1() : makeDerived2()); // no error, x is inferred to be Base let x = 1; x *= 2; x = sin(x) / x; // no error, x is inferred to be Float The problem is not just that extra computation is needed, it's language design. For example, you probably do not expect a dictionary of Floats and a zero to be a dictionary of Any, but how are you going to implement that in the compiler?
      - viraptor 8y ago
        The first example is simple. The only extra work is to find common parent class. And yes, the next example does need backtracking. I agree that it does need extra work in some cases. Most of the time though it's a very straightforward process.
asd 8y ago
Nice set of highlights. It's amazing to see how quickly Swift has evolved in four years.
dep_b 8y ago
Yessssss for the allCases property for enums!!! Enums are really the best feature of Swift. I enum all the things everywhere. This is kind of the finishing touch to it. Binary stability would be nice. I do care about the download sizes of my apps. What's really missing from the language is a way to add custom tags like @discardableResult @objc to define some kind of property. It's such a kludge to set up things like ViewModels while I really would like to have something like: @twoWayBinding[username] lazy var username: UILabel = { /* etc */ }()
- alexashka 8y ago
  It isn't too hard to setup two-way binding with KVO if you wanted to. You can have one way binding, you can have binding with a transformer function to go from a number to a string etc. Here's a playground where I did this a while back. You get type safety and nice syntax too. https://gist.github.com/desugaring/828e9880f747678ac5912a070bd32dce https://gist.github.com/desugaring/828e9880f747678ac5912a070...
  - dep_b 8y ago
    It might as well be KVO under the hood, no problem. It's just that annotations can be really handy to indicate a ton of stuff that would otherwise be lines of code. I use it in other languages all of the time.
    - jsgo 8y ago
      yeah, I'll agree here. Being able to slap an annotation on a method in C# is one of the major pluses. [Authorize] in ASP.NET MVC (Core as well I believe?), the various ones in Entity Framework, etc. Very useful.
jmull 8y ago
> Swift 5 (Early 2019): > binary compatibility with future Swift releases I bet this doesn't really happen, though it probably makes the day when it really happens closer. (I don't just mean they might miss the date, but that (1) they miss the date by a lot; and/or (2) they drop binary compatibility from Swift 5; and/or (3) they claim they've achieved binary compatibility but it doesn't out to be true for long, less than 5 years )
- Apocryphon 8y ago
  It was already promised in Swift 4 and delayed to 5, you think it will continue to slip?
  - s73v3r_ 8y ago
    Binary compatibility means a certain level of commitment to support that the Swift team seems to have avoided.
- Osmium 8y ago
  They do provide a public dashboard for tracking progress to ABI stability: https://swift.org/abi-stability/ https://swift.org/abi-stability/ Whether it turns out there are things missing from that list, who knows, but they're definitely getting closer.
ssvss 8y ago
Is there a plan for c++ Interop in swift. Or have they decided that using the obj-c bridging layer is enough.
- kitsunesoba 8y ago
  AFAIK it’s still in the cards but it’ll come after ABI stability. I have at least one project that’ll make use of this — can’t wait to drop the ObjC layer in it entirely.
- favorited 8y ago
  It's on the list of things that would be nice someday, but it will take a lot of time to get right, and it's not a high enough priority right now. There's a handful of other significant features that will come first, like ABI stability, Ceylon/Rust style ownership checking, first-class concurrency/atomics (async/await, etc.). That said, Swift's C interop will work if you write an `extern "C"` interface to your C++. Obviously it's not ideal, but people have done projects like llvm-swift[0], with LLVM obviously being a C++ project. [0]https://github.com/llvm-swift/LLVMSwift https://github.com/llvm-swift/LLVMSwift
selljamhere 8y ago
>>New hashing algorithm >>Hash values vary from run to run (so don’t depend on hash values or order) I must be reading this wrong. One of the requirements for a good hash function is determinism - specifically that any given value in the input space maps to exactly one value in the output space.
- bbatha 8y ago
  The hashing algorithm can be deterministic however hashing relies on a seed. In most cases you want that to be random to prevent certain side channel attacks. For swift, hashing will be deterministic for the lifetime of the program.
  - selljamhere 8y ago
    That makes sense. I was thinking in terms of global lookup keys, which would require hashes to persist across runs. When thinking in terms of object equality, the hashes need only live as long as the objects themselves. Namely, for the lifetime of the program.
  - samueloph 8y ago
    wait, hashing relies on a seed?! isn't that a salt/pepper? to be "deterministic for the lifetime of the program" sounds like a pepper is being applied, not that the hash algorithm is different.
    - bbatha 8y ago
      This is a more accurate description. The hashing algorithm is 100% deterministic, but the inputs include a random seed from the start of the program to prevent various side channel attacks and to prevent folks from erroneously relying on hashmap ordering.
- Someone 8y ago
  I think the intended reading of ”so don’t depend on hash values or order” is “do not have your code depend on hash values or iteration order of items sorted by hash value”. So, what you shouldn’t do is: - storing a hash value on disk, assuming it to be valid in a later run. - assume that a hash map that has the same content as a hash map of a previous run has the same iteration order (not even if the calls used to construct them are 100% identical, and not even if both were constructed from the same literal). I expect this was added to thwart DoS attacks (http://ocert.org/advisories/ocert-2011-003.html http://ocert.org/advisories/ocert-2011-003.html)
masonicb00m 8y ago
What was bad about arc4random?
- jayrhynas 8y ago
  Nothing inherently wrong with it, but it's not available on all platforms that support Swift. The new Random APIs use arc4random() under the hood on Darwin IIRC. There's also no direct equivalent to arc4random() in the new API - you always have to pass a range, which discourages people from using % to reduce the range and introduce modulo bias.
  - masonicb00m 8y ago
    Ah. Like Linux, I guess. Thanks for the info.
  - Someone 8y ago
    ”but it's not available on all platforms that support Swift” I think that’s a weak argument. arc4random’s source code isn’t platform specific, complex or large and is available under a permissive license, so they could easily put it in the runtime. I would think they added this because of the modulo argument you give and to give it a better name (there’s nothing wrong with ‘arc4random’ for _a_ random number generator, but _the_ random number generator on a platform should have a simpler name)
st3fan 8y ago
I hear Firefox compiles twice as fast with the new compiler.

75 points by jtbrown 8y ago

swyx 8y ago

has swift made the leap to server side yet? i keep hearing mumblings about that.

dep_b 8y ago
Vapor apparently gets favorable reviews by those who drank the Kool-Aid: https://vapor.codes/ https://vapor.codes/ Never tried it though. I don't select stacks primarily based on programming language.
- willio58 8y ago
  I’ve used it for a few sites at this point. Haven’t used v3 but it’s been a great resource. It’s a cool experience coding a website with a compiled language, especially swift.
- abalone 8y ago
  Vapor looks like the best so far but it's still early days. In theory it has the potential to be extremely fast and memory efficient, but for example they only just got a couple TechEmpower benchmarks up a couple days ago and they ranked very low (#162 on the json test).[1] It goes without saying simplistic benchmarks like this are flawed but at the same time, you have to start somewhere. [1] https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=json https://www.techempower.com/benchmarks/#section=data-r16&hw=...
  - dep_b 8y ago
    JSON performance is super important for a server, far more than for the usual macOS or iOS clients. JSON parsing might be based on the basic JSON parser found in Swift, which isn't fast at all, rather easy to use and secure instead. It's not super up-to-date but you can see there's definitely some competition even on Swift level in terms of JSON performance. https://github.com/bwhiteley/JSONShootout https://github.com/bwhiteley/JSONShootout Swift JSON encoding/decoding should approach C/C++ levels of performance when optimized for speed.
    - abalone 8y ago
      The plaintext benchmark was also slow, so the JSON implementation may not be the main cause here.
thanatos_dem 8y ago
In addition to Vapor which other commenters have mentioned, Apple itself released Swift-NIO, a port of Netty to Swift that they’re actively developing - https://github.com/apple/swift-nio https://github.com/apple/swift-nio It’s somewhat lower-level than web frameworks people may be used to coming from a Ruby/Node background, but it’s pretty powerful.
wsc981 8y ago
There's the Perfect [0] library that I recently used to develop a real-time multiplayer TicTacToe proof of concept for iOS. I used the Perfect web socket functionality on the server. Worked out well enough. --- [0]: https://perfect.org https://perfect.org

marvel_boy 8y ago

"Faster builds" How compares with Objective-C compile times?

dep_b 8y ago
Still not as fast and probably Objective-C got a speed boost as well. Objective-C is a very simple language and types are quite explicit. In Swift you have implied types like: let result = jsonList.map { Class(from: $0) }.filter { $0.isSelected }.map { T(from: $0 } Or worse: let myDict = ["key": 1, "key2": 0.2, "key3": "something"] It has to figure out it's not an int, not a number but an Any dict. Complexity to figure out the real type can quickly ramp up.
- viraptor 8y ago
  Type inference, at least for variables doesn't really take that much time. In practice almost every language does it, they just don't expose it to the developer. For example you can do this in C: foo->bar()->baz() And the compiler has to get the type for the bar() result. That's one a small step from: let x = foo->bar() Also that dictionary is most likely parsed and assigned a type in the expression whether you specify the variable type or not.
  - hamstergene 8y ago
    That is way too oversimplified case of type inference. A huge lot of languages don't have this: let x = (f ? makeDerived1() : makeDerived2()); // no error, x is inferred to be Base let x = 1; x *= 2; x = sin(x) / x; // no error, x is inferred to be Float The problem is not just that extra computation is needed, it's language design. For example, you probably do not expect a dictionary of Floats and a zero to be a dictionary of Any, but how are you going to implement that in the compiler?
    - viraptor 8y ago
      The first example is simple. The only extra work is to find common parent class. And yes, the next example does need backtracking. I agree that it does need extra work in some cases. Most of the time though it's a very straightforward process.

asd 8y ago

Nice set of highlights. It's amazing to see how quickly Swift has evolved in four years.

dep_b 8y ago

Yessssss for the allCases property for enums!!! Enums are really the best feature of Swift. I enum all the things everywhere. This is kind of the finishing touch to it. Binary stability would be nice. I do care about the download sizes of my apps. What's really missing from the language is a way to add custom tags like @discardableResult @objc to define some kind of property. It's such a kludge to set up things like ViewModels while I really would like to have something like: @twoWayBinding[username] lazy var username: UILabel = { /* etc */ }()

alexashka 8y ago
It isn't too hard to setup two-way binding with KVO if you wanted to. You can have one way binding, you can have binding with a transformer function to go from a number to a string etc. Here's a playground where I did this a while back. You get type safety and nice syntax too. https://gist.github.com/desugaring/828e9880f747678ac5912a070bd32dce https://gist.github.com/desugaring/828e9880f747678ac5912a070...
- dep_b 8y ago
  It might as well be KVO under the hood, no problem. It's just that annotations can be really handy to indicate a ton of stuff that would otherwise be lines of code. I use it in other languages all of the time.
  - jsgo 8y ago
    yeah, I'll agree here. Being able to slap an annotation on a method in C# is one of the major pluses. [Authorize] in ASP.NET MVC (Core as well I believe?), the various ones in Entity Framework, etc. Very useful.

jmull 8y ago

> Swift 5 (Early 2019): > binary compatibility with future Swift releases I bet this doesn't really happen, though it probably makes the day when it really happens closer. (I don't just mean they might miss the date, but that (1) they miss the date by a lot; and/or (2) they drop binary compatibility from Swift 5; and/or (3) they claim they've achieved binary compatibility but it doesn't out to be true for long, less than 5 years )

Apocryphon 8y ago
It was already promised in Swift 4 and delayed to 5, you think it will continue to slip?
- s73v3r_ 8y ago
  Binary compatibility means a certain level of commitment to support that the Swift team seems to have avoided.
Osmium 8y ago
They do provide a public dashboard for tracking progress to ABI stability: https://swift.org/abi-stability/ https://swift.org/abi-stability/ Whether it turns out there are things missing from that list, who knows, but they're definitely getting closer.

ssvss 8y ago

Is there a plan for c++ Interop in swift. Or have they decided that using the obj-c bridging layer is enough.

kitsunesoba 8y ago
AFAIK it’s still in the cards but it’ll come after ABI stability. I have at least one project that’ll make use of this — can’t wait to drop the ObjC layer in it entirely.
favorited 8y ago
It's on the list of things that would be nice someday, but it will take a lot of time to get right, and it's not a high enough priority right now. There's a handful of other significant features that will come first, like ABI stability, Ceylon/Rust style ownership checking, first-class concurrency/atomics (async/await, etc.). That said, Swift's C interop will work if you write an `extern "C"` interface to your C++. Obviously it's not ideal, but people have done projects like llvm-swift[0], with LLVM obviously being a C++ project. [0]https://github.com/llvm-swift/LLVMSwift https://github.com/llvm-swift/LLVMSwift

selljamhere 8y ago

>>New hashing algorithm >>Hash values vary from run to run (so don’t depend on hash values or order) I must be reading this wrong. One of the requirements for a good hash function is determinism - specifically that any given value in the input space maps to exactly one value in the output space.

bbatha 8y ago
The hashing algorithm can be deterministic however hashing relies on a seed. In most cases you want that to be random to prevent certain side channel attacks. For swift, hashing will be deterministic for the lifetime of the program.
- selljamhere 8y ago
  That makes sense. I was thinking in terms of global lookup keys, which would require hashes to persist across runs. When thinking in terms of object equality, the hashes need only live as long as the objects themselves. Namely, for the lifetime of the program.
- samueloph 8y ago
  wait, hashing relies on a seed?! isn't that a salt/pepper? to be "deterministic for the lifetime of the program" sounds like a pepper is being applied, not that the hash algorithm is different.
  - bbatha 8y ago
    This is a more accurate description. The hashing algorithm is 100% deterministic, but the inputs include a random seed from the start of the program to prevent various side channel attacks and to prevent folks from erroneously relying on hashmap ordering.
Someone 8y ago
I think the intended reading of ”so don’t depend on hash values or order” is “do not have your code depend on hash values or iteration order of items sorted by hash value”. So, what you shouldn’t do is: - storing a hash value on disk, assuming it to be valid in a later run. - assume that a hash map that has the same content as a hash map of a previous run has the same iteration order (not even if the calls used to construct them are 100% identical, and not even if both were constructed from the same literal). I expect this was added to thwart DoS attacks (http://ocert.org/advisories/ocert-2011-003.html http://ocert.org/advisories/ocert-2011-003.html)

masonicb00m 8y ago

What was bad about arc4random?

jayrhynas 8y ago
Nothing inherently wrong with it, but it's not available on all platforms that support Swift. The new Random APIs use arc4random() under the hood on Darwin IIRC. There's also no direct equivalent to arc4random() in the new API - you always have to pass a range, which discourages people from using % to reduce the range and introduce modulo bias.
- masonicb00m 8y ago
  Ah. Like Linux, I guess. Thanks for the info.
- Someone 8y ago
  ”but it's not available on all platforms that support Swift” I think that’s a weak argument. arc4random’s source code isn’t platform specific, complex or large and is available under a permissive license, so they could easily put it in the runtime. I would think they added this because of the modulo argument you give and to give it a better name (there’s nothing wrong with ‘arc4random’ for _a_ random number generator, but _the_ random number generator on a platform should have a simpler name)

st3fan 8y ago

I hear Firefox compiles twice as fast with the new compiler.