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.
If you’re wanting to containerise the program, maybe it’s less resource intensive to add those things to Alpine than to run another distro with more support? Obviously only speculation
Just from reading HN it seems like Alpine had a brief fad a few years ago but never got much traction.
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) - 57 MiB (lost to static linking) = 11 MiB (net gains from Alpine), so their Alpine Linux solution is actually about 10% smaller than the equivalent that uses an Ubuntu image.
Is that worth the extra work they put into it? It probably depends on the application.
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.
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.
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.
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)
But I think for a distribution it makes more sense to link swift programs dynamically against the runtime libraries, like it's the case for e.g. the C standard library, OpenSSL etc., as you can assume they all work with the same version and are ABI-compatible.
I tested it with a nearly static build (Still links against glibc and friends): 55MB get stripped to 44MB, so not that much. 27MB of that is icudt_swift65_dat, so I guess you would have to optimise that first
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
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.
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?
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.
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.
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.
Any api or data model code, pretty much 80% of my app code works crosss platform
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.
Quite frankly if you can't track the lifetime of your own allocated memory, are you even a competent software developer?
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.