Packaging Swift Apps for Alpine Linux • Hacker News Board

Re: Packaging Swift Apps for Alpine Linux

#41

Post by philjohn » Mon, Jun 17, 2024, 11:59 AM UTC

yjftsjthsd-h wrote: post #12

repelsteeltje wrote: post #11

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.

Some of us are just using Alpine as our primary OS, and would need a compelling reason to do anything else.

Because as much as it is great, musl isn't a drop-in replacement for glibc and requires extra work from maintainers to get software working on it (see PyTorch, AWS CLI etc. etc.).

Re: Packaging Swift Apps for Alpine Linux

#42

Post by lenkite » Mon, Jun 17, 2024, 1:22 PM UTC

dagmx wrote: post #29

xvilka wrote: 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…

Wish Swift provided a way to use custom allocators. Then it would be really terrific. A fair number of middle-ware projects work well with strategies like arena allocation which significantly improve performance and also structural ergonomics. ARC adds a fair bit of performance burden - you can see dozens of examples of people refactoring continuously to reduce ARC time in the swift forums.

Re: Packaging Swift Apps for Alpine Linux

#43

Post by opless » Mon, Jun 17, 2024, 2:28 PM UTC

dagmx wrote: post #29

xvilka wrote: 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…

Indeed there's no compelling reason to use C++ or Rust. It comes down to user preferences.

Quite frankly if you can't track the lifetime of your own allocated memory, are you even a competent software developer?

Re: Packaging Swift Apps for Alpine Linux

#44

Post by wredue » Mon, Jun 17, 2024, 2:53 PM UTC

dagmx wrote: post #29

xvilka wrote: 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…

Is Linux still a fifth class citizen for swift?

The last time I used it (and I admit this was a couple years ago), silly expectations like “my program will behave the same on Linux as it does on Mac” were not being met.

Re: Packaging Swift Apps for Alpine Linux

#45

Post by bobajeff » Mon, Jun 17, 2024, 3:28 PM UTC

dagmx wrote: post #33

bobajeff wrote: post #32

Earlier quoted context omitted.

It remains to be seen weather Swift will break out of being just a language for programming Apple applications. There is still no way to make gui applications outside of Apple devices. Unless you want to make your own library or generate/maintain Swift bindings for an existing UI library. Maybe, it will be okay for console only programs or servers but why use that over Java/JVM, nodejs or go?

UI libraries are a poor reason to pick Rust over Swift, given that Rust has a very poor UI story. Doesn’t your comment apply very equally to Rust? There’s basically Slint and Tauri, and several bindings in various states of disarray. Not exactly very compelling. The Rust ecosystem has very many strengths, but UI is not one of them. Regardless, you’re incorrect about there being no way to make GUI applications Here’s…

My comment wasn't about comparing it to Rust at all. Adwaita for Swift sounds good an all but it still looks immature. Also, the win32 bindings look even more immature. I agree UI is not there yet for Rust and from what I see it's even worse for Swift (unless we're taking about Apple devices).

I'm still not sold on the idea of managing bindings to C++ UI libraries. I'd rather have either the Swift organization or the UI library authors themselves write, maintain and document the bindings. Otherwise, it just seems like fighting against the ecosystem.