Live data from Hacker News

Packaging Swift Apps for Alpine Linux

mko.re

21–30 of 45 posts

Re: Packaging Swift Apps for Alpine Linux

#21
post #19
post #3

I was curious how large these static binaries would be since the last announcement. Being honest, 100MB is quite a bit larger than I was expecting. Probably fine for CI business apps and such, but kinda rules out a lot of linux util type things.

A big chunk (roughly a quarter) of it is the Unicode handling library. I think eventually the stdlib will be split up more so that it’s not one giant blob, but there’s a lot of areas that will be reducing in the future.

75M is still huge for this type of thing.

My smallest Go CLI is 1.6M. This is probably about as small as you can get in Go and still do something useful. Some of my other (larger) Go CLIs range from ~2.5M to ~6.5M. Go is not known for producing small binaries.

Re: Packaging Swift Apps for Alpine Linux

#22
post #3

I was curious how large these static binaries would be since the last announcement. Being honest, 100MB is quite a bit larger than I was expecting. Probably fine for CI business apps and such, but kinda rules out a lot of linux util type things.

[deleted]

Re: Packaging Swift Apps for Alpine Linux

#23
post #21
post #19

Earlier quoted context omitted.

A big chunk (roughly a quarter) of it is the Unicode handling library. I think eventually the stdlib will be split up more so that it’s not one giant blob, but there’s a lot of areas that will be reducing in the future.

75M is still huge for this type of thing. My smallest Go CLI is 1.6M. This is probably about as small as you can get in Go and still do something useful. Some of my other (larger) Go CLIs range from ~2.5M to ~6.5M. Go is not known for producing small binaries.

For fun, I made an executable hello world with SBCL and it came out weighing 40MB (no compression, of course); this also includes Unicode data and a complete compiler. Something's wrong here.

Re: Packaging Swift Apps for Alpine Linux

#25
post #24

There's no reason to use Swift outside of the Apple platform. Rust is much better option and more cross-platform. And they work hard on reducing the binary size as well.

Also self-inflicting Apple’s “what happens not a Mac” developer experience may not be what one wants to go through during the lifetime of an app.

Re: Packaging Swift Apps for Alpine Linux

#26
post #24

There's no reason to use Swift outside of the Apple platform. Rust is much better option and more cross-platform. And they work hard on reducing the binary size as well.

Well I for one appreciate Swift’s focus on ergonomics and progressive disclosure. I think Rust is great, but I don’t see it as a great application-level programming language.

I think it’s wonderful that Swift is trying to be more cross-platform. No need to shoot down the efforts of people trying to bring a language they like to more places.

Re: Packaging Swift Apps for Alpine Linux

#27
post #21
post #19

Earlier quoted context omitted.

A big chunk (roughly a quarter) of it is the Unicode handling library. I think eventually the stdlib will be split up more so that it’s not one giant blob, but there’s a lot of areas that will be reducing in the future.

75M is still huge for this type of thing. My smallest Go CLI is 1.6M. This is probably about as small as you can get in Go and still do something useful. Some of my other (larger) Go CLIs range from ~2.5M to ~6.5M. Go is not known for producing small binaries.

My point is that the issue is the stdlib is monolithic at the moment. As it gets split up in the near future, the binaries will reduce in size.

Re: Packaging Swift Apps for Alpine Linux

#28

Earlier quoted context omitted.

I seem to have missed the part where he explains why he's targeting Alpine Linux for his Swift app. Alpine isn't mainstream (the way Ubuntu or rhel are) and stands out mostly for being compact and clutter free. So... indeed... If you somehow end up with 100MB package for what is essentially just 250kB, I'd say something did not go right. Feels very square peg in round hole.

The Alpine Linux docker image is 7.8 MiB to Ubuntu's 76 MiB, so they get a savings of about 68 MiB in image size by using Alpine Linux over Ubuntu. From the stats in TFA it looks like about 43 MiB of the file size is the Swift runtime itself, which would need to be installed in any OS. This leaves ~57 MiB extra in their static binary approach vs what they'd get out of dynamic linking. 68 MiB (saved by using alpine) -…

Depending on how builds and deployments are done, there is a high likelihood that the lower userspace layers are much slower moving than the upper application layers. After your second build, dynamic linking wins and everything after that it pulls even further ahead.

Smart builds can make application deltas really small. I helped design a system where our several hundred MB monolith could be hot patches with a layer of a few thousand kilobytes and most builds were 10-20MB. Obviously this wouldn’t have worked for a statically linked app.

Re: Packaging Swift Apps for Alpine Linux

#29
post #24

There's no reason to use Swift outside of the Apple platform. Rust is much better option and more cross-platform. And they work hard on reducing the binary size as well.

This is like a C++ dev saying there’s no reason to use rust.

Swift offers a lot of ergonomic values over rust in ways that have made me switch over as my default choice.

Things like default argument values, lazy static initializers, computed properties, optional chaining. I’ve personally also come around to ref counting by default being a sensible choice for most programs.

Though the thing that won me over was the recent C++ interoperability. Rust doesn’t have a good story there yet that’s as comparable. Hours/days/months writing Rust bindings for a C++ library are often minutes in Swift.

Each language has its own place and own benefits, but to say there’s “no reason to use a language” feels short sighted and defensively dismissive

Re: Packaging Swift Apps for Alpine Linux

#30
post #29
post #24

There's no reason to use Swift outside of the Apple platform. Rust is much better option and more cross-platform. And they work hard on reducing the binary size as well.

This is like a C++ dev saying there’s no reason to use rust. Swift offers a lot of ergonomic values over rust in ways that have made me switch over as my default choice. Things like default argument values, lazy static initializers, computed properties, optional chaining. I’ve personally also come around to ref counting by default being a sensible choice for most programs. Though the thing that won me over was the re…

I would agree with you but in the case of Swift is largely confined to the Apple ecosystem with other platforms as an afterthought, while both C++ and Rust try to cover as many targets as possible.
Post reply on HN