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

Packaging Swift Apps for Alpine Linux

mko.re

Post reply on HN
Print view View original

31–40 of 45 posts

Re: Packaging Swift Apps for Alpine Linux

#31

Post by dagmx »

xvilka wrote: post #30
dagmx wrote: post #29

Earlier quoted context omitted.

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.

But that is exactly what is changing right now.

Foundation is being rewritten in Swift, Swift has moved out from under apples GitHub and is pushing more cross platform tooling for windows and Linux.

It’s not as flexible in terms of targets yet as Rust, but it’s also not just locked to Apple platforms.

And for a big chunk of developers, that trade off is fine.

Re: Packaging Swift Apps for Alpine Linux

#32

Post by bobajeff »

dagmx wrote: post #31
xvilka wrote: post #30

Earlier quoted context omitted.

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.

But that is exactly what is changing right now. Foundation is being rewritten in Swift, Swift has moved out from under apples GitHub and is pushing more cross platform tooling for windows and Linux. It’s not as flexible in terms of targets yet as Rust, but it’s also not just locked to Apple platforms. And for a big chunk of developers, that trade off is fine.

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?

Re: Packaging Swift Apps for Alpine Linux

#33

Post by dagmx »

bobajeff wrote: post #32
dagmx wrote: post #31

Earlier quoted context omitted.

But that is exactly what is changing right now. Foundation is being rewritten in Swift, Swift has moved out from under apples GitHub and is pushing more cross platform tooling for windows and Linux. It’s not as flexible in terms of targets yet as Rust, but it’s also not just locked to Apple platforms. And for a big chunk of developers, that trade off is fine.

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 a Gnome binding https://swift.org/blog/adwaita-swift/

The C++ interop allows easy binding to Qt https://github.com/qt/qtdeclarative/tree/dev/tests/manual/he...

Win32 https://github.com/compnerd/swift-win32

The fact that Swift has easier C++ interop than Rust makes the cross platform UI story much easier and more compelling than what I’ve found in Rust.

Bindings are much simpler to manage and can be handled by a single module map file with a single line in it most of the time.

Adding to that, many well established UI libraries depend on classes to implement them. Rusts lack of classes, while wonderful otherwise, makes binding to heavy class based libraries very onerous.

Don’t get me wrong, I really enjoy rust. It’s just, it’s very ill suited for UI work today itself. I almost always write my UI side in C++ if I have to and bind over when needed instead.

Re: Packaging Swift Apps for Alpine Linux

#34

Post by graboid »

dagmx wrote: post #31
xvilka wrote: post #30

Earlier quoted context omitted.

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.

But that is exactly what is changing right now. Foundation is being rewritten in Swift, Swift has moved out from under apples GitHub and is pushing more cross platform tooling for windows and Linux. It’s not as flexible in terms of targets yet as Rust, but it’s also not just locked to Apple platforms. And for a big chunk of developers, that trade off is fine.

I am quite curious about Swift as a "more ergonomic Rust". How would you say it fares for typical backend stuff?

Re: Packaging Swift Apps for Alpine Linux

#35

Post by dagmx »

graboid wrote: post #34
dagmx wrote: post #31

Earlier quoted context omitted.

But that is exactly what is changing right now. Foundation is being rewritten in Swift, Swift has moved out from under apples GitHub and is pushing more cross platform tooling for windows and Linux. It’s not as flexible in terms of targets yet as Rust, but it’s also not just locked to Apple platforms. And for a big chunk of developers, that trade off is fine.

I am quite curious about Swift as a "more ergonomic Rust". How would you say it fares for typical backend stuff?

Currently the state of server side dev is a bit here and there.

Vapor is the preferred framework and in general will seem familiar to anyone using any of the Rust server frameworks like actix web etc…

A tutorial for reference https://swift.org/getting-started/vapor-web-server/

From an ergonomics perspective, I write less code with Vapor than the equivalent Rust frameworks. It is slower today though but plenty for my needs, with some speed ups coming with Vapor refactors down the pipe.

I find that I need to spend less time managing shared resources with concurrency , and my code is clearer while being less verbose in general. Features like the trailing closure syntax are much easier to read for me.

I find it closer to how I’d write my Flask servers in the amount of code I need to do myself.

Re: Packaging Swift Apps for Alpine Linux

#36

Post by graboid »

dagmx wrote: post #35
graboid wrote: post #34

Earlier quoted context omitted.

I am quite curious about Swift as a "more ergonomic Rust". How would you say it fares for typical backend stuff?

Currently the state of server side dev is a bit here and there. Vapor is the preferred framework and in general will seem familiar to anyone using any of the Rust server frameworks like actix web etc… A tutorial for reference https://swift.org/getting-started/vapor-web-server/ From an ergonomics perspective, I write less code with Vapor than the equivalent Rust frameworks. It is slower today though but plenty for my…

Thanks for sharing.

Re: Packaging Swift Apps for Alpine Linux

#37

Post by JoeMattiello »

xvilka wrote: post #30
dagmx wrote: post #29

Earlier quoted context omitted.

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.

It really isn’t though. All my iOS swift code that doesn’t touch UIKit has been running unit tests with Linux Debian on GitHub actions for a few years now with almost no extra effort.

Any api or data model code, pretty much 80% of my app code works crosss platform

Re: Packaging Swift Apps for Alpine Linux

#40

Post by arp242 »

dagmx wrote: post #27
arp242 wrote: post #21

Earlier quoted context omitted.

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.

I thought Swift compiles to machine code? Can't it eliminate the unused stdlib code?

Well, I guess not if the statically linked binaries are so large, but this seems like the more major reason for these very large binaries instead of stdlib being monolithic? (Not entirely sure what that means in this context)

Post reply on HN