6 ms·
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.
by tigershark 7y ago
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.
- saagarjha 7y ago> the awful objective c :(
- mojuba 7y agoI 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.
- algerd 7y agowhat about kotlin native https://kotlinlang.org/docs/reference/native-overview.html https://kotlinlang.org/docs/reference/native-overview.html ?
- singularity2001 7y agoKotlinc takes 10 seconds to compile Hello World, 30 seconds with wasm target. Seems almost conceptually unfixable.
- pjmlp 7y agoswiftc 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.
- skohan 7y agoI 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.
- pjmlp 7y agoAnd both are slowed down by LLVM. F#, Standard ML, OCaml and Haskell also have such strong type systems.
- pjmlp 7y agoSwift's ARC implementation has a little bit of performance catchup to do in regards to tracing GCs. https://github.com/emmericp/ixy https://github.com/emmericp/ixy
- skohan 7y agoIMO 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.
- pjmlp 7y agoLanguages with tracing GC implementations also have value types, thus they would keep winning. Top performance reference counting implementations are tracing GC in disguise.
- jbverschoor 7y agoSwift was out before kotlin.
- Razengan 7y agoWhat’s hideous about Swift closures (though I guess everything has always room for improvement) and how are F# and Kotlin better?
- rimliu 7y agoThis puzzled me too. Ok, blocks in Obj-C do look, err… interesting, but closures in Swift are totaly fine.
- saagarjha 7y agoMaybe the use of "in"?
- tigershark 7y ago(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.
- jbverschoor 7y agoyes, because of memory management. It's a good thing.
- kitsunesoba 7y agoDunno 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.