Swift Static Linux SDK

#1

Post by mannuch » Tue, Jun 11, 2024, 8:25 PM UTC

Re: Swift Static Linux SDK

#2

Post by palata » Tue, Jun 11, 2024, 8:51 PM UTC

> Additionally, a program built for a particular distribution, or even a particular major version of a particular distribution, would not necessarily run on any other distribution or in some cases even on a different major version of the same distribution.

Not sure I understand that. Is it something specific to Swift, or is it exactly what is expected from using shared libraries?

Say my Linux distribution distributes some Swift runtime, then the corresponding Swift packages should have been built for this runtime as well. Just like when my Linux distribution distributes a libc, the corresponding packages need to be built for this libc. Right?

Still, it's cool that Swift provides static linking. But like in any language, the best IMHO is when the Linux distribution can choose how it wants to distribute a package. I tend to like shared libraries, and already Rust seems to be interfering and imposing its preferences. I am happy if Swift doesn't.

Re: Swift Static Linux SDK

#3

Post by e63f67dd-065b » Tue, Jun 11, 2024, 9:03 PM UTC

palata wrote: post #2

> Additionally, a program built for a particular distribution, or even a particular major version of a particular distribution, would not necessarily run on any other distribution or in some cases even on a different major version of the same distribution. Not sure I understand that. Is it something specific to Swift, or is it exactly what is expected from using shared libraries? Say my Linux distribution distributes…

It's just classic dependency issues. I'm not familiar with swift specifics, but probably a combination of ABI instability and just plain version incompatibility from one distro to the next with your target program.

My opinion is the opposite: I think the old paradigm of distros managing a giant set of system libraries is a bad one, and is how we ended up in the land of docker. Go and Rust made the right decisions here: vendor all the dependencies, and distros can't mess with them. Makes it easier for upstream and the distro.

Modern languages are not like C/C++: a single non-trivial rust program can easily depend on 100+ crates, and re-creating crates.io in your package manager is just a bad idea, even putting aside that there's probably major version incompatibilities the moment you go beyond a handful of programs. Look at the disaster that's python package management, that's not where you want to end up.

Re: Swift Static Linux SDK

#4

Post by mshockwave » Tue, Jun 11, 2024, 9:05 PM UTC

palata wrote: post #2

> Additionally, a program built for a particular distribution, or even a particular major version of a particular distribution, would not necessarily run on any other distribution or in some cases even on a different major version of the same distribution. Not sure I understand that. Is it something specific to Swift, or is it exactly what is expected from using shared libraries? Say my Linux distribution distributes…

> Not sure I understand that. Is it something specific to Swift, or is it exactly what is expected from using shared libraries?

More of a shared library issue I believe.

> Say my Linux distribution distributes some Swift runtime, then the corresponding Swift packages should have been built for this runtime as well. Just like when my Linux distribution distributes a libc, the corresponding packages need to be built for this libc. Right?

That's correct

Re: Swift Static Linux SDK

#5

Post by manmal » Tue, Jun 11, 2024, 9:06 PM UTC

palata wrote: post #2

> Additionally, a program built for a particular distribution, or even a particular major version of a particular distribution, would not necessarily run on any other distribution or in some cases even on a different major version of the same distribution. Not sure I understand that. Is it something specific to Swift, or is it exactly what is expected from using shared libraries? Say my Linux distribution distributes…

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://www.swift.org/blog/abi-stability-and-apple/), but this would close the door on new features that need runtime support (need an OS update then, or the OS must come with multiple runtimes).

Re: Swift Static Linux SDK

#6

Post by Vt71fcAqt7 » Tue, Jun 11, 2024, 9:06 PM UTC

Genuine question: is there any reason to use Swift without iOS/SwiftUI? (Outside of devs who are primarily Swift developers that want to use something they already know for a small project or similar.)

Re: Swift Static Linux SDK

#7

Post by autoexecbat » Tue, Jun 11, 2024, 9:06 PM UTC

I guess this means it can compete with golang on ease of distribution. Pushes all the complexity away from the end user

Re: Swift Static Linux SDK

#8

Post by Mandelmus » Tue, Jun 11, 2024, 9:08 PM UTC

Vt71fcAqt7 wrote: post #6

Genuine question: is there any reason to use Swift without iOS/SwiftUI? (Outside of devs who are primarily Swift developers that want to use something they already know for a small project or similar.)

It's a beautiful language that's a joy to write. It's safe and ergonomic, and has an extremely powerful type system. I'd say those are good reasons to use Swift.

Re: Swift Static Linux SDK

#9

Post by e63f67dd-065b » Tue, Jun 11, 2024, 9:09 PM UTC

Vt71fcAqt7 wrote: post #6

Genuine question: is there any reason to use Swift without iOS/SwiftUI? (Outside of devs who are primarily Swift developers that want to use something they already know for a small project or similar.)

The main reason is that Apple has effectively deprecated Objective-C for ios/macos development going forward. It's not going away for probably another decade+, but all documentation is now in Swift, new APIs are written with Swift in mind, etc.

Think of it this way: in 5-10 years, ObjC will be the python2 of Apple development.

Re: Swift Static Linux SDK

#10

Post by jkelleyrtp » Tue, Jun 11, 2024, 9:11 PM UTC

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 primitives to nix platforms

- Distributed actors for concurrency that run on distant machines

- Data-race free by default

- non-copy RAII generic types

Watch the video on Swift 6: https://developer.apple.com/videos/play/wwdc2024/10136/.

IMO Swift 6 is a better Go and than Go, and a better Rust for app-dev type stuff, which seems to be what people want to use Rust for.

Swift has shipped stuff that Rust has been sitting on its hands over for years:

- Anonymous enums/structs in parameters/match statements

- Named function arguments

- A type of `Send` bound that allows Rcs to be sent between threads (not Arcs)

- Swift preview hotreloading

- autoclones (without GC)

Swift also took a bunch of goodies from Rust *[1]

- No garbage collector

- Traits via "protocol"

- ADT for Option/Result

- macros

- non-copy types enforcing RAII

I really really wish Rust had been keeping up with Swift's ergonomics because it's looking like Swift is going to catch up to Rust's cross-platform story much faster. Swift really could end up as the "do it all" language for frontend/backend/app dev.

[1] By "took" I mean if you like these things in Rust you'll see them in Swift