Hacker News Reader

Comment by mring33621 | Hacker News Reader

I understand there may be some bias in this article, but the resource usage improvements are hard to ignore for a company that pays for cloud compute/memory usage.

I'm gonna look into server-side Swift.

Looks like it'll take some fiddling to find the right non-xcode tools approach for developing on linux.

I prefer Jetbrains tools over VSCode, if anyone has any hints in that direction.

View on HN

I don’t know that there’s anything that magical about Swift in particular, but rather the difference of running without the big runtime of the JVM and the advantages of memory management. Go will probably give improvements (and likely be an easier mental adjustment from a JVM language), and Rust, once you mentally adapt to its model will give even bigger improvements. Swift has the advantage of being object-oriented (if that’s an advantage in your mind), but I was thinking 10 years ago that with the move to microservices that Java/Spring apps were going to not work so great with the quick start-up/shut-down that the cloud/microservice model wants.

Will Rust really be better than Swift in such a context? Doesn’t that more or less depend on what kind of memory management is being used in Rust?

The memory management strategies in Rust and Swift are similar. The big performance hit in Swift would come in method dispatch where it’s following Objective C strategies which would result in indirect calls for object methods. This is possible in Rust (using Box(dyn trait)), but discouraged in critical paths in favor of either static dispatch by means of enums or reified calls through Rust generics. Swift has similar capabilities, of course, but with both languages, the best performance reqires consciously making choices in development.

> The big performance hit in Swift would come in method dispatch where it’s following Objective C strategies which would result in indirect calls for object methods.

While Swift can use Objective-C's message sending to communicate with Objective-C libraries, that isn't its primary dispatch mechanism. In the case of the service described in the article, it isn't even available (since it runs on Linux, which does not have an Objective-C runtime implementation).

Instead, like Rust, Swift's primary dispatch is static by default (either directly on types, or via reified generics), with dynamic dispatch possible via any (which is similar to Rust's dyn). Swift also has vtable-based dispatch when using subclassing, but again this is opt-in like any/dyn is.

Adding to what the sibling comment from airspeedswift said, there is not ever a need to use dynamic dispatch in Swift outside of iOS apps. Idiomatic apps will have many internal packages/targets that don't even import any Objective-C based libraries and can be compiled and run with just the swift toolchain. You can even inline all your frequent function calls. Idiomatic Swift also uses classes sparingly, and most are ideally declared final.

Sadly, Jetbrains no longer sells AppCode or supports their Swift plugins for CLion. I WISH they would open source the plugins, as CLion is far superior to Xcode. For now, though, we're really stuck with either Xcode (Mac) or VSCode (wherever). That said, I am really starting to love server-side Swift using Vapor. Swift, as a language, is great to develop in.

If resource usage improvement is entirely due to bias, it should be easy to ignore?

Reply on news.ycombinator.com