Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WWDC 2018 What's New in Swift Recap

roadfiresoftware.com

Post reply on HN
Print view View original

21–30 of 45 posts

Re: WWDC 2018 What's New in Swift Recap

#21

Post by Someone »

selljamhere wrote: post #13

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

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)

Re: WWDC 2018 What's New in Swift Recap

#22

Post by s73v3r_ »

selljamhere wrote: post #13

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

During a particular run of the app, this is still true. However, the hash function uses a seed, which gets changed every time you run the app.

Re: WWDC 2018 What's New in Swift Recap

#23

Post by s73v3r_ »

Apocryphon wrote: post #20
jmull wrote: post #10

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

It was already promised in Swift 4 and delayed to 5, you think it will continue to slip?

Binary compatibility means a certain level of commitment to support that the Swift team seems to have avoided.

Re: WWDC 2018 What's New in Swift Recap

#24

Post by rokob »

selljamhere wrote: post #13

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

The hasher in the standard library is defined here: https://github.com/apple/swift/blob/master/stdlib/public/cor...

with some explanation for where the seed comes from here:

https://github.com/apple/swift/blob/master/stdlib/public/cor...

Within that code you will see references to Core which by default is this:

https://github.com/apple/swift/blob/82226642c2459c0f5d2054fe...

So you can see the hash function itself is deterministic given the seed it is initialized with. And the seed is generated at process start time during static initialization in C++ so it is effectively a constant for the lifetime of the process.

You can see in the code that there is a way to make hashing fully deterministic by making the seed generation not use random numbers, but it is ill-advised for a variety of security reasons.

Re: WWDC 2018 What's New in Swift Recap

#25

Post by dep_b »

viraptor wrote: post #8
dep_b wrote: post #7

Earlier quoted context omitted.

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

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

You don't understand the problem. It's the possibility of types versus the types declared. Swift will always try to go with the most exact type it can find. C doesn't have types. C is just a bunch of numbers. Swift always has types, even if you don't type them. In case of a large dictionary with multiple types for keys and values it has a ton of possibilities to test for before the real type is determined.

Could be 2 seconds to compile a very large (like 20 items) untyped dictionary declaration in the days of yore. If you would put:

    let dict: [String: Any] = [ /* bunch of confusing key-values */ ]
The compile time would go down to 100ms or less. Because it would only check if all of the keys were Strings and all of the values conformed to Any.

Re: WWDC 2018 What's New in Swift Recap

#26

Post by dep_b »

alexashka wrote: post #15
dep_b wrote: post #6

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…

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/828e9880f747678ac5912a070...

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.

Re: WWDC 2018 What's New in Swift Recap

#27

Post by abalone »

dep_b wrote: post #3
swyx wrote: post #2

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

Vapor apparently gets favorable reviews by those who drank the Kool-Aid: https://vapor.codes/ Never tried it though. I don't select stacks primarily based on programming language.

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

Re: WWDC 2018 What's New in Swift Recap

#29

Post by wsc981 »

swyx wrote: post #2

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

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

Re: WWDC 2018 What's New in Swift Recap

#30

Post by jayrhynas »

masonicb00m wrote: post #28

What was bad about arc4random?

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.

Post reply on HN