Swift Static Linux SDK

Post by arthur-st » Tue, Jun 11, 2024, 9:49 PM UTC

square_usual wrote: post #25

jkelleyrtp wrote: post #10

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…

Swift and Go are on polar ends of the language complexity spectrum. Someone who enjoys Go for what it is, i.e. a dead simple, straightforward language, would not see Swift as being "better".

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

lynndotpy wrote: post #28

e63f67dd-065b wrote: post #3

Earlier quoted context omitted.

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 her…

I feel the same. A huge part of the pleasure of Go and Rust are that I never run into dependency problems. I'm happy to pay the "Hello World is 4MB" tax.

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

josephg wrote: post #35

frankjr wrote: post #23

Earlier quoted context omitted.

> Makes it easier for upstream and the distro. Until there's a vulnerability in one of the dependencies and now you have to rebuild all of the packages which use it. Specifically for Rust, there's also the fact that most projects use a lock file and if your build process respects it, you now have to wait for the upstream to update it and release a new version (or update it yourself). And if your build process doesn't…

> Until there's a vulnerability in one of the dependencies and now you have to rebuild all of the packages which use it. Packages get rebuilt all the time. This is fine. As for the rest, it would be cool if binaries shipped with a manifest of some sort naming all the versions of their statically included dependencies. A SBoM of sorts. It would make this sort of vulnerability scanning much easier to do.

    go version -m $(which go)
    go install golang.org/x/vuln/cmd/govulncheck@latest
    go version -m $(which govulncheck)
    govulncheck -mode=binary $(which govulncheck)
    for b in $(go env GOPATH)/bin/*; do govulncheck -mode=binary "$b"; done

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

tux3 wrote: post #60

palata wrote: post #36

Earlier quoted context omitted.

Sure. It's great to have the possibility to link statically. My beef with the "static linking trend" is that many people (or languages, e.g. Rust) don't want to let me link dynamically, for some reason. Just let me choose!

But they do. They do let you choose. Debian's build of rust packages are linked dynanically, for instance. It's a build setting, you can turn it on.

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

arthur-st wrote: post #61

square_usual wrote: post #25

Earlier quoted context omitted.

Swift and Go are on polar ends of the language complexity spectrum. Someone who enjoys Go for what it is, i.e. a dead simple, straightforward language, would not see Swift as being "better".

I think it depends on the person. My anecdotal experience is that I'm using Go for hobby projects because with Python at my day job, I wanted a modern language with fancy-ish static typing. Additionally, I wanted it to be equally practical on Win/Mac/Linux, and to not run inside a VM. The obvious first candidate was Rust, but the low-level features were unnecessary overhead. A "higher-level Rust" is literally Swift,…