Hacker News Reader

Comment by tigershark | Hacker News Reader

F# and Kotlin seem better to me, and don’t have that hideous syntax for the closures. But it’s for sure another world compared to the awful objective c.

View on HN

I wouldn't say Kotlin is significantly better than Swift in terms of syntax, they are largely similar to the point you sometimes think: someone copied this from the other, I wonder who was the first.

To me personally though the showstopper for Kotlin is that it runs on Java VM. That was the design goal of course, i.e. to become a major "upgrade" of Java esp. on Android. Java VM (with its GC) is a creation of the pre-mobile era when all we had was desktop computers, ever growing processing power and an assumption that you have infinite supply of electric power. It's a different philosophy and design. I think Google's choice of using it on a mobile platform was unfortunate, though at the time (i.e. before the iPhone) many popular mobile platforms did run on Java VM so it seemed like a natural choice.

what about kotlin native https://kotlinlang.org/docs/reference/native-overview.html ?

Kotlinc takes 10 seconds to compile Hello World, 30 seconds with wasm target. Seems almost conceptually unfixable.

swiftc isn't also not that blazing fast.

For me Delphi, .NET Native, D are some of the targets to beat in compilation time.

They all share a common trait though, not built on top of LLVM.

I would say Rust is a better point of comparison for Swift given the emphasis both languages have on strong type systems and static analysis. Neither one is super fast, but 10 seconds for a hello world is insanely slow.

And both are slowed down by LLVM.

F#, Standard ML, OCaml and Haskell also have such strong type systems.

Swift's ARC implementation has a little bit of performance catchup to do in regards to tracing GCs.

https://github.com/emmericp/ixy

IMO this example should be taken with a grain of salt, since at a cursory glance it looks like they are leaning heavily on reference-types, which is not really idiomatic swift, and is a worst-case for tightly-looping code which this is. I would love to spend even a half hour trying to optimize this code to see what the results could be, but there is specialized hardware required to run the benchmark, so it's not really practical for 3rd parties to attempt to achieve a better result.

It's fair to say that ARC has performance issues, but the story is a bit more complex than that. By relying heavily on value types, it's possible to write Swift code which carries very little ARC cost (although there are additional issues with copy-on-write performance). Also ARC is more memory efficient than most GC solutions, so there are tradeoffs involved.

Languages with tracing GC implementations also have value types, thus they would keep winning.

Top performance reference counting implementations are tracing GC in disguise.

Swift was out before kotlin.

Dunno about F# as I’ve never written it, but Kotlin, while not a bad language, to me mostly feels like Swift with extra syntactic friction points. Among other things, its property getter/setter syntax feels awkward compared to those Swift.

What’s hideous about Swift closures (though I guess everything has always room for improvement) and how are F# and Kotlin better?

This puzzled me too. Ok, blocks in Obj-C do look, err… interesting, but closures in Swift are totaly fine.

Maybe the use of "in"?

(s1: String, s2: String) -> Bool in return s1 > s2 } In nested closures you can’t use the $0 syntax, swift type inference is pretty poor compared to F# and so a lot of time I have to explicitly specify the types and the in is much less clear than => or ->. To make it even more frustrating I have to specify the @escaping attribute in a lot of methods that accept closures as an argument.

yes, because of memory management. It's a good thing.

> the awful objective c

Reply on news.ycombinator.com