Why should I use Swift instead of Rust?
Swift Static Linux SDK
51–60 of 274 posts
Re: Swift Static Linux SDK
#52Can I make Gtk GUI with this like you can with cocoa on macOS?
Re: Swift Static Linux SDK
#53Earlier quoted context omitted.
Swift and Go are on polar ends of the language complexity spectrum. Someone who enjoys Go for what it is, i.e. a dead simple, straightforward language, would not see Swift as being "better".
Some people want generics and ADTs in Go. If you're using go because it's 1) fast 2) expressive 3) concurrent 4) compiles natively then I think Swift is the better of the two. If you just want a very simple language, then sure, Go is there. But I don't think that's necessarily what makes Go, Go.
I would say that yes, in fact, simplicity is characteristic of Go. That is clear from how the go team considers the impact of every new language feature, often choosing not to do things that would've been considered obvious in other languages. Many parts of the community still resent generics, and there is widespread backlash to the new iterators proposal. Most Go enthusiasts wouldn't be fans of Swift and vice versa.
Re: Swift Static Linux SDK
#54Can I make Gtk GUI with this like you can with cocoa on macOS?
Re: Swift Static Linux SDK
#55> Additionally, a program built for a particular distribution, or even a particular major version of a particular distribution, would not necessarily run on any other distribution or in some cases even on a different major version of the same distribution. Not sure I understand that. Is it something specific to Swift, or is it exactly what is expected from using shared libraries? Say my Linux distribution distributes…
It's just classic dependency issues. I'm not familiar with swift specifics, but probably a combination of ABI instability and just plain version incompatibility from one distro to the next with your target program. My opinion is the opposite: I think the old paradigm of distros managing a giant set of system libraries is a bad one, and is how we ended up in the land of docker. Go and Rust made the right decisions her…
> the disaster that's python package management, that's not where you want to end up
The one where the only sane option is using distribution packages or conda and ignoring anything that the python community comes up with?
Re: Swift Static Linux SDK
#56Swift 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…
Given there is native C++ interop, is exporting a C ABI still a seemingly experimental/niche feature? Same question with interop between C and Swift.
Recently went with using Kotlin Native over Swift on macOS for this reason, the C ABI export and C interop were painless.
Re: Swift Static Linux SDK
#57Why should I use Swift instead of Rust?
The concurrency story is quite good now with Swift 6, and it’s arguably easier to handle than the borrow checker, but still very safe.
Re: Swift Static Linux SDK
#58Earlier quoted context omitted.
> Makes it easier for upstream and the distro. Until there's a vulnerability in one of the dependencies and now you have to rebuild all of the packages which use it. Specifically for Rust, there's also the fact that most projects use a lock file and if your build process respects it, you now have to wait for the upstream to update it and release a new version (or update it yourself). And if your build process doesn't…
> Until there's a vulnerability in one of the dependencies and now you have to rebuild all of the packages which use it. Packages get rebuilt all the time. This is fine. As for the rest, it would be cool if binaries shipped with a manifest of some sort naming all the versions of their statically included dependencies. A SBoM of sorts. It would make this sort of vulnerability scanning much easier to do.
> Packages get rebuilt all the time. This is fine.
You forgot to link the image with the dog sitting in the fire.
Re: Swift Static Linux SDK
#59Earlier quoted context omitted.
I'm primarily a C++ developer these days, and if the C++ interop is actually good then I'm very excited for the future. For app-dev type stuff it really does seem like it's better than Rust, and I can definitely see a world where we start migrating some code into Swift. Edit: back from watching the video, and a few observations: - Swift does not suffer from Rust's refusal to add things into the standard library. gasp…
The default testing framework made my jaw drop a bit - I have a very hard time seeing Rust have the enthusiasm or momentum to implement something like that right now.
Why do you think they wouldn't? (I don't keep up with Rust+its community closely enough to know.)
Re: Swift Static Linux SDK
#60Earlier quoted context omitted.
Dynamic linking works fine for software that is distributed by distros, but lots of software isn't.
Sure. It's great to have the possibility to link statically. My beef with the "static linking trend" is that many people (or languages, e.g. Rust) don't want to let me link dynamically, for some reason. Just let me choose!
But they do. They do let you choose.
Debian's build of rust packages are linked dynanically, for instance. It's a build setting, you can turn it on.