Live data from Hacker News

Swift Static Linux SDK

swift.org

261–270 of 274 posts

Re: Swift Static Linux SDK

#261
post #215

Earlier quoted context omitted.

> then it doesn't have to wait for the distro maintainers No, but it has to wait for each developer of each binary individually. Instead of relying on a team of maintainer, you now rely on all the developers. "Self-update" isn't something magical: someone has to do build the new version and ship it. With static linking you still have to build and ship for every. single. binary . With dynamic linking you just build an…

Of course... and I'm not suggesting that every app in a linux distro should be as such. You can dynamically link with Rust, Go, etc. That said, for one of the 3-4 GUI apps that most people use, the distro process tends to leave people with relatively old versions missing critical bug fixes or features. I tend to keep my host OS pretty bare, and most of my runtime apps in Flatpak and the stuff I'm working on in Docker…

> You can dynamically link with Rust

Do you have experience with that, or do you say it because you believe it's possible? Genuinely interested, because I have been looking into it and my conclusion was that it does not really do what I expect from "dynamic linking".

See e.g. https://news.ycombinator.com/item?id=40665343 and https://news.ycombinator.com/item?id=40661874

Re: Swift Static Linux SDK

#262
Swift for all its niceties still suffers from a habit of inherently tying its conventions to Apple and its "appleisms" when coding. Tasks that should be relatively straightforward to do e.g. iterating through a file line-by-line still requires an awkward amount of code. It's especially noticeable when compared to languages like Go or Python:

https://forums.swift.org/t/text-streaming-in-standard-librar...

While these things are not difficult to solve with some minor additions to the standard library and documentation that emphasizes some basic conventions, the fact that we're on Swift6 and things like this aren't just available speaks to how much further the community needs to evolve to get the language ergonomics right for non apple-y things.

Re: Swift Static Linux SDK

#263
post #170

Earlier quoted context omitted.

Do you know whether someone has made an estimate based on the history of actual vulnerabilities of how much rebuilding would need to be done in a non-shared library approach?

Not to my knowledge. But consider something like crypto, libssl ... which is linked to almost everything, or libxz, zlib, etc. If there is a bug in a shared library, one can replace it with a interm one very easily, and the whole operating system will use it. One can even replace it with a different implementation assuming ABI compatibility, without having to do "much". Enclaves like Go, Rust, Swift (things that insi…

Go is the only one of the three that directly uses syscalls. Rust and Swift both go through libc. Swift never even had the option of directly using syscalls, since it was originally designed for MacOS, and syscalls are so unstable there that they've changed in minor version updates.

Re: Swift Static Linux SDK

#264
post #5

Earlier quoted context omitted.

A Swift program for a particular distribution will dynamically link some system libraries from the distro, and these libs might change on every distro update. They mention in the post that dynamic linking can cause versioning issues. > Say my Linux distribution distributes some Swift runtime That runtime would need to be compatible with the Swift program. Nowadays that’s not a big issue due to ABI stability ( https:/…

AFAIK they claim ABI stability only for Apple platforms, explicitly neither Linux, nor Windows. Has that changed?

Nope. For the foreseeable future, stable ABI on other platforms is basically only going to happen if a distro starts supporting an ABI stable standard library on their own.

Re: Swift Static Linux SDK

#265

Swift 6 is amazing - I say this as a big Rust person. It seems like Swift is now its own entity outside the Apple bubble and has a few very interesting features: - An "embedded" mode that turns off reflection for kilobyte-sized binaries - An upcoming WASM target - An LSP for VSCode - Native C++ interop - Typed "throws" - Static linking on linux and the linux sdk - Porting a number of "core foundation" / foundation pr…

- Anonymous enums/structs in parameters/match statements

I'm not sure what you mean by this, could you elaborate?

Re: Swift Static Linux SDK

#267

What might a cross-platform GUI app look like with Swift? I'm assuming SwiftUI can't be used? Regardless, I'll definitely be reaching for Swift for one-off scripts. I've enjoyed the times I needed to use Swift for a React Native extension.

In iOS 18, there is now a SwiftUICore framework that's separate from SwiftUI, which I imagine consumes it. I don't see the new one on the documentation site. If that becomes public in a year or so, maybe you'd be able to replace one of the two frameworks to implement your own view system atop the attribute graph and data flow bits.

It's unlikely this will ever be made public. It's probably just there for organizational reasons, just like UIKit got made an umbrella framework for UIKitCore a while back.

Re: Swift Static Linux SDK

#268
post #262

Swift for all its niceties still suffers from a habit of inherently tying its conventions to Apple and its "appleisms" when coding. Tasks that should be relatively straightforward to do e.g. iterating through a file line-by-line still requires an awkward amount of code. It's especially noticeable when compared to languages like Go or Python: https://forums.swift.org/t/text-streaming-in-standard-librar... While these…

What's wrong with

  for try await line in file.lines

?

Re: Swift Static Linux SDK

#270
post #95

Earlier quoted context omitted.

I have a slight inkling that Apple internally is using Swift for backend stuff somewhere, especially with all the ML stuff they just shipped. Word on the street is their datacenters are full of M-series chips. I could see those servers running Swift + distributed actors + mlx. The move to make swift run on Linux could be part of that work - their sysadmins, devops, and backend folks probably use Vim/VSCode and deploy…

Apple deploys a ton of their server stuff on Linux. Plus they appear to be doing all new code in Swift and moving old code over slowly. They’re also using embedded Swift in the Secure Enclaves and other small processors due to its safety, though I think they have an extra layer of automated security checking that they use internally that doesn’t exist in the public builds. But in short, yes. I believe they’re trying…

Most server code Apple writes is Java. They are slowly trying out Swift, but it's not really correct to say that all new code is Swift.
Post reply on HN