Live data from Hacker News

Swift is like Kotlin

nilhcem.com

61–70 of 364 posts

Re: Swift is like Kotlin

#64

One has structures, ARC, proper extensions, good protocols/interfaces, flexible enums, and runs natively. The other one doesn't. I think I'll choose the former.

Yes, I know about Kotlin Native, but it's not quite there yet.

Still doesn't make up for Swift's language superiority.

Re: Swift is like Kotlin

#65

One has structures, ARC, proper extensions, good protocols/interfaces, flexible enums, and runs natively. The other one doesn't. I think I'll choose the former.

Excellent C and Objective C interoperability too.

As for the post, it's ridiculously fanboyish.

The same comparison could be made with other older languages towards Kotlin. Microsoft F# comes to mind, for example.

Re: Swift is like Kotlin

#66

Pretty good list. I don't think the tuple comparison is accurate though, I thought a data class is basically a value type (like Swift's struct) except with some stuff like equals, hashcode, and toString calculated for you. Minor nit: the sort example needlessly uses two lines for the Swift version.

[deleted]

Re: Swift is like Kotlin

#67
post #40

Earlier quoted context omitted.

Ugh, I know it's something that literally every programmer on earth can and often does bikeshed, but Swift just got string interpolation syntax wrong . Parentheses are something that are often part of the interpolated expression... they shouldn't be part of the interpolation syntax itself.

Yes, agreed. IMO, curly braces would have made much more sense. It's not even bikesheding, really. It's just a fact that curly braces are less used in most written languages. I would also argue that curly braces are a better signal to the programmer that "something programmatic is happening here", due to their prevalence as scope delimiters in most popular languages. Swift's string interpolation doesn't catch my eye…

I definitely think a general guideline for language designers could be "when in doubt, make it look like Ruby". The language has its issues, sure, but damn if it didn't get syntax just right.

Re: Swift is like Kotlin

#68
post #42
post #23

Earlier quoted context omitted.

Swift has both external and internal parameter names for functions. This is to make API design more readable, easier to parse through. For example, you can have a function like so: func greet(with greeting: String, to personName: String) { print("\(greeting), \(personName)!") } In the above code, "with" and "to" are external names, and are only available when calling the function but are not available inside the func…

Having never used Swift, it feels like the syntax is being optimized for the less-common case; are named parameters considered the "default" choice in Swift, and is using different external names so common that it's worth cluttering the syntax for functions without external parameters in order to make the their own syntax easier?

Named parameters are very much the default in Swift. Positional parameters are rare exceptions.

The internal/external name divide often works out beautifully. For example, let's equip Double with a multiply-add. An idiomatic Swift signature:

    extension Double {
      func multiply(by multiplier:Double, adding summand:Double) -> Double {
        return self * multiplier + summand
      }
    }

    print(3.multiply(by:4, adding:5))
Erase punctuation and you have:

    func multiply by multiplier adding summand

    print 3 multiply by 4 adding 5
The caller sees an action (multiply by, adding), the callee sees nouns (multiplier, summand). It's fantastically readable.

Re: Swift is like Kotlin

#69
post #52

Earlier quoted context omitted.

Yes, but the corresponding design decision would be "0..=n". Swift's "0...n" is a bit less obvious. Also, exclusivity is almost always what you want, so "0..n" should just default to exclusivity and "0...n" could be inclusive.

This is the exact opposite to ruby, which uses `0..n` as inclusive, and `0...n` as exclusive http://stackoverflow.com/questions/9690801/difference-betwee... I always remembered it as "the third dot makes it bigger so it pushes the range and the last item falls off". I can't remember where that came from, perhaps related to the poignant guide: http://poignant.guide/book/chapter-3.html#section2 I actually find in pract…

[deleted]
Post reply on HN