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

161–170 of 274 posts

Re: Swift Static Linux SDK

#161

Post by stephen_g »

This is awesome, and I believe opens up what I and a bunch of people were wanting which is the ability to run Swift binaries in Alpine containers! I'd seen work on musl support going in but I didn't realise it would all be going so soon. Cross compilation is very nice too to not need your runtime platform to necessarily support the whole toolchain.

I'm really glad there's finally support for vanilla Debian and from what I've seen it looks like there are initial Swift packages finally being added in the Debian testing version, which will be nice. Debian is more and more my go-to for development VMs where Ubuntu used to be, so I'm excited for official support!

With all this and embedded, I'm really excited about Swift! I've done a lot of embedded in C and I'm super keen to try out Swift on my STM dev boards!

Re: Swift Static Linux SDK

#162

Post by glhaynes »

wg0 wrote: post #133
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…

> 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. This is a great assessment. There are some shortcomings in go that I wish weren't and I'm kind surprised that people having decades of language design experience under their belt ended up designing go. I'm looking for a way to generate server stubs from OpenAPI specs. If that, I'm al…

I'm looking for a way to generate server stubs from OpenAPI specs

I don't have experience with OpenAPI, but is this what you're looking for? https://www.swift.org/blog/introducing-swift-openapi-generat...

Re: Swift Static Linux SDK

#163

Post by JackYoustra »

gh123man wrote: post #110
JackYoustra wrote: post #90

Swift tooling has some really! Sharp! Edges!!! If you need something quick and easier than rust or have some reason to want to take your swift code and run it elsewhere I guess this is good but I don't see why you'd use it besides that.

I'd love to hear some specific examples. Ive built several iOS apps and a whole backend (on linux) with Swift and other than lack of OSS library support for some SaaS APIs, it's been quite nice. Sure Swift itself has some sharp edges, but not any more (or worse) than many other popular languages.

Sure! I love talking about this stuff :) here's a few:

- if you want to manager your Package.swift target, you mostly have to deal with .target enum (can't figure out how to paste the URL)

You can really only do a define or unsafeFlags, which leads to a couple issues...

1) There's only Debug and Release configurations! What if you want more? What if you want a nice flow where you emit and consume pgo data and re-ingest it?

2) What if you want to use a define for another language managed by SPM, such as metal?

3) What if you want to put in a portable path into a linker argument? SPM blocks use of build-time environment variables, so you can't do that either.

All of these things seem contrived, but I ran into all three of them at my current job (shameless NanoFlick plug). All of these can be handled by cmake or xcodebuild (although probably better to use rules_xcodeproj).

- Swift compiler feedback and performance in builders is absolutely atrocious, to the point where binary searching a view to find the actual source of a type error over ~30 second build times isn't very unusual!

- It's very overly conservative with build times, and because there's only module-level import, it's very easy to accidentally have a long dependency chain which makes building one file imply building many files, further tanking your build time. There are some forum posts I can dig up on this if you're curious more on this point.

- POD structs are default-Sendable at module-level visibility, but lose that if they're public, which means if you try modularizing your app into different small packages to restore some notion of compilation units to fight against the above two points, you end up having to go around and mark all of your different classes with default protocols (usually just Sendable) to reimplement!

- Not a huge deal, but no way to have macro_rules! like you can in rust: macros are kinda hard to use and have to be in another package.

This is just my thoughts on tooling, I have many more thoughts about the language itself that I'd be happy to share.

Honestly though it's much better with vscode. I do hope that it makes progress in the right direction, Swift has a lot of things going for it!

Re: Swift Static Linux SDK

#165

Post by JackYoustra »

rescripting wrote: post #104
JackYoustra wrote: post #90

Swift tooling has some really! Sharp! Edges!!! If you need something quick and easier than rust or have some reason to want to take your swift code and run it elsewhere I guess this is good but I don't see why you'd use it besides that.

Could you elaborate?

Yes! See my reply above

Re: Swift Static Linux SDK

#166

Post by LtWorf »

kibwen wrote: post #127
LtWorf wrote: post #67

Earlier quoted context omitted.

No, crates will be statically linked anyway in general.

Rust supports dynamic linking, it's just not the default, so you need to configure a given crate to use it at build time.

Rust supports compiling each crate as a separate .so and then linking all of them?

That's not at all how debian packages written in rust are linked. So the person I replied to is incorrect.

I suspect you're incorrect as well and what you claim doesn't exist at all, but you're claiming a different thing.

Re: Swift Static Linux SDK

#167

Post by LtWorf »

kibwen wrote: post #124
palata wrote: post #97

Earlier quoted context omitted.

> It should be pretty easy to programmatically update a lock file, run the tests, and rebuild a package. You still fundamentally need to rebuild (or at least relink) and re-distribute all the packages, whereas with shared libraries... well you just update that one package.

I hear the refrain "you'll have to rebuild your packages" a lot in these discussions, and I confess I don't see how this is a problem. Maybe it's a holdover from C and C++ veterans for whom figuring out how to build any given project is a Herculean effort, but for every other language with a first-class build system it's trivial.

For distributions, it costs a lot of money they don't have to just be rebuilding stuff all the time.

For randomly downloaded binaries from the internet it means you will most likely keep using it with the vulnerabilities for years to come.

Re: Swift Static Linux SDK

#168

Post by amszmidt »

kibwen wrote: post #157
amszmidt wrote: post #154

Earlier quoted context omitted.

Debian has about 59000 packages. Even rebuilding 1k of that is a significant pain on build infrastructure, specially in one go, if say a vulnerable library is found. You also now get a huge set of users who will now download these 1k of updated packages. Not to mention the utter fun of trying to understand why your system just requires maybe 100 packages to be updated… Compare to upgrading a single shared library.

The distro repositories are being continuously rebuilt, because packages are receiving continuous updates. In the meantime, as far as I'm concerned dynamic linking is itself a security failure, because if I run a binary I want to know exactly what code is being run, without having to worry about dynamic linking and loading nonsense inserting itself into my process.

They aren’t being rebuilt with that kind of frequency as you might think.

They get rebuilt when a change in the package is made, not when a change in a dependency is made — which is a huge difference.

There are plenty of packages that might not get an update for a long time (month, half year, … whatever their release cadence might be).

Dynamic linking makes it _easier_ to handle security, including checking if your program is linking to a broken library — static linking does not have the same means.

Statically linked programs don’t mean you know what is being run either, you can always dlopen() and all kind of shenanigans like Go and Rust do.

What is a security nightmare is statically linked binaries, you have no clue what they are linked against.

Re: Swift Static Linux SDK

#169

Post by arthur-st »

manmal wrote: post #69
arthur-st wrote: post #61

Earlier quoted context omitted.

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

Have you checked out the static linking option announced yesterday? Portability has increased a lot.

I have, and I am indeed very hopeful about the WWDC 2024-related Swift announcements. My comment was meant to illustrate my thinking circa a year or two ago.

Re: Swift Static Linux SDK

#170

Post by eviks »

amszmidt wrote: post #154
kibwen wrote: post #124

Earlier quoted context omitted.

I hear the refrain "you'll have to rebuild your packages" a lot in these discussions, and I confess I don't see how this is a problem. Maybe it's a holdover from C and C++ veterans for whom figuring out how to build any given project is a Herculean effort, but for every other language with a first-class build system it's trivial.

Debian has about 59000 packages. Even rebuilding 1k of that is a significant pain on build infrastructure, specially in one go, if say a vulnerable library is found. You also now get a huge set of users who will now download these 1k of updated packages. Not to mention the utter fun of trying to understand why your system just requires maybe 100 packages to be updated… Compare to upgrading a single shared library.

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?
Post reply on HN