Hacker News Reader

Comment by SirensOfTitan | Hacker News Reader

I worked with Swift extensively for a year and a half, and I absolutely adore the language. I think it does a lot right while avoiding more of rust's complexities (I am a rust n00b, so grain of salt).

The problem with Swift (as of like 1.5 years ago when I stopped using the language daily) was its ecosystem. Swift package manager wasn't really used (at least for iOS apps), there was no real decent ecosystem outside the xcode world (no langserver, some server-side swift abstractions).

I think Swift would really thrive if Apple were to give it some room to breathe in the open source community, but until Swift decouples itself more from Apple's own needs, I couldn't imagine using it for anything other than iOS development.

View on HN

Two of my favorite languages are Swift and Kotlin. I basically always choose Kotlin, but I would actually like Swift more if it was supported more outside of Apple.

Swift has the benefit of actual value types, no GC, and IME it's much faster. But it only runs on Apple's OS (technically there's support for Linux but people say it isn't good). Kotlin has access to all Java packages and runs on the JVM, and with Kotlin multiplatform JetBrains is trying to make it run on almost anything.

Swift is currently reference counted, which is more or less GC but worse because it’s not tracing/cycle-detecting.

Every design decision has tradeoffs. RC has its own significant upsides, like deterministic deallocation and a much lower memory floor for preventing world-pauses during tracing.

How is RC deallocation deterministic?

Besides which I don't want to have to keep track of weak references, at that point I would rather just have a full ownership model: https://github.com/apple/swift/blob/main/docs/OwnershipManif...

I assume the grandparent was talking about how, as soon as the last reference to a refcounted object goes away, the object is deallocated. Pure Swift follows this rule though Objective-C code may not always do this due to things like autorelease pools.

Sure but that's nothing like deterministic destruction, where I can tell you the order that things will be deallocated just from looking at a block.

And possible stack overflow or freezing applications, when a domino effect of reference counting reaching 0 happens, and dealloc functions weren't properly written.

There is a Herb Sutter talk at CppCon about the downsides of reference counting.

Basically the solution to those problems is to make use of hazardous pointers or deferred destructions on background threads, which are a kind of lightweight tracing GC.

JetBrains will discover the pains of embracing multiple platforms.

Outside Android, Kotlin will always be playing catch-up with platform features, having two ways of doing the same thing for features introduced before the platform went their own way, FFI that only goes one way, the native variant is being redone due to the clever idea of being originally incompatible with JVM memory model, it is officially a way to sell InteliJ licenses.

No langserver? SourceKit LSP has been around for a while now: https://github.com/apple/sourcekit-lsp

Reply on news.ycombinator.com