Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift Static Linux SDK

swift.org

Post reply on HN
Print view View original

31–40 of 274 posts

Re: Swift Static Linux SDK

#31

Post by palata »

frankjr wrote: post #23
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…

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

I totally agree. Static linking is essentially easier for people who don't want to care. But ignoring security does not mean it solves it, on the contrary.

Static linking comes with a lot of issues, just like dynamic linking is not perfect. I really think it depends on the use-case, and that's why I want to have the choice.

Re: Swift Static Linux SDK

#32

Post by jkelleyrtp »

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".

Some people want generics and ADTs in Go. If you're using go because it's

1) fast

2) expressive

3) concurrent

4) compiles natively

then I think Swift is the better of the two.

If you just want a very simple language, then sure, Go is there. But I don't think that's necessarily what makes Go, Go.

Re: Swift Static Linux SDK

#33

Post by palata »

frankjr wrote: post #26
School-Cotton wrote: post #17

Earlier quoted context omitted.

Some distros do actually break out rust dependencies into separate packages (e.g. Guix does this). It's just that a lot of rust software isn't distributed primarily by distros.

Fedora and Debian do this too. That's why it sometimes takes longer for a project to be packaged - you literally have to recursively package all of the dependencies first.

Which is a feature, and not a bug: some of us want our distro maintainers to actually have a look at what they distribute.

Re: Swift Static Linux SDK

#34

Post by jkelleyrtp »

e63f67dd-065b wrote: post #16
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…

I'm primarily a C++ developer these days, and if the C++ interop is actually good then I'm very excited for the future. For app-dev type stuff it really does seem like it's better than Rust, and I can definitely see a world where we start migrating some code into Swift. Edit: back from watching the video, and a few observations: - Swift does not suffer from Rust's refusal to add things into the standard library. gasp…

The default testing framework made my jaw drop a bit - I have a very hard time seeing Rust have the enthusiasm or momentum to implement something like that right now.

Re: Swift Static Linux SDK

#35

Post by josephg »

frankjr wrote: post #23
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…

> 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.

Re: Swift Static Linux SDK

#36

Post by palata »

School-Cotton wrote: post #14
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…

Dynamic linking works fine for software that is distributed by distros, but lots of software isn't.

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!

Re: Swift Static Linux SDK

#37

Post by cube2222 »

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…

Agreed that Swift looks quite amazing. There’s some cool talks on how they’re trying to move FoundationDB to Swift and their approach.

I think the main problem, and this is a really big problem, is that based on a very shallow investigation I did a couple months back, the ecosystem for server-side stuff barely exists.

And in my opinion, the ecosystem is one of the deciding factors when picking a language.

Re: Swift Static Linux SDK

#38

Post by hbn »

e63f67dd-065b wrote: post #9
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.

The GP was asking specifically about non-Apple development

Re: Swift Static Linux SDK

#39

Post by palata »

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.

> It would make this sort of vulnerability scanning much easier to do.

Scanning, sure. Fixing... surely much harder than with shared libraries.

Re: Swift Static Linux SDK

#40

Post by glhaynes »

e63f67dd-065b wrote: post #16
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…

I'm primarily a C++ developer these days, and if the C++ interop is actually good then I'm very excited for the future. For app-dev type stuff it really does seem like it's better than Rust, and I can definitely see a world where we start migrating some code into Swift. Edit: back from watching the video, and a few observations: - Swift does not suffer from Rust's refusal to add things into the standard library. gasp…

I'm not a (direct) user of the C++ interop, but everything I've heard about it has been quite positive. A few hopefully relevant resources, first a couple of videos:

- "Introducing a Memory-Safe Successor Language in Large C++ Code Bases" (John McCall; CppNow 2023) https://www.youtube.com/watch?v=lgivCGdmFrw

- "Swift as C++ Successor in FoundationDB" (Konrad Malawski; Strange Loop 2023) https://www.youtube.com/watch?v=ZQc9-seU-5k

And then a series of blog posts by Doug Gregor:

- "Swift for C++ Practitioners" https://www.douggregor.net/posts/

And finally:

- "Mixing Swift and C++" (Swift.org) https://www.swift.org/documentation/cxx-interop/

Post reply on HN