What might a cross-platform GUI app look like with Swift? I'm assuming SwiftUI can't be used? Regardless, I'll definitely be reaching for Swift for one-off scripts. I've enjoyed the times I needed to use Swift for a React Native extension.
Swift Static Linux SDK
211–220 of 274 posts
Re: Swift Static Linux SDK
#212Earlier quoted context omitted.
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.
The way I view it as a Rust experienced programmer: Its kinda like if everything in your program was Arc and we didnt have the mess that are the async executors. But I might be wrong. Love rust but god that sometimes I curse the choices that were made and how slow it evolves.
And supposedly, the compiler transforms the Arc in Rc or even removes it entirely if it can prove to be fine. I still did not check if there is a tool that tells you what was optimized and the reason why something wasn't.
Re: Swift Static Linux SDK
#213Earlier quoted context omitted.
I hear the refrain "you'll have to rebuild your packages" a lot in these discussions, and I confess I don't see how this is a problem. Maybe it's a holdover from C and C++ veterans for whom figuring out how to build any given project is a Herculean effort, but for every other language with a first-class build system it's trivial.
It really sounds like you see it from the point of view of a developer who has never thought about how a Linux distribution works. Yes, for you as a user it's simpler to link statically and not learn about anything else. But distros are a bit more elaborate than that.
It sounds like you see it from the point of view of a disto maintainer and never thought about how awful the experience is for software developers. I want to just depend on some specific, latest version of a library. I don’t want to have to go look at which version of that library exists in 18 different Linux distributions. I don’t want to deal with bug reports because Debian patched one of my dependencies or replaced the version I depend on with something newer or older.
I’m happy for someone to update the version of my dependency if it has security patches. But the rest? A total nightmare. I’ll take cargo / npm / swift / etc style versioning every day.
Re: Swift Static Linux SDK
#214> Cons of static linking:
Not listed is that ASLR either doesn't work at all or you get just one object (the PIE's) randomized. For a memory safe language this may not be a con at all.
Also, when many executables can share common objects then there can be a reduction in I/O (reads) needed to load those the next time that one of those executables runs. In 2004 when the Solaris 10 (then a work in progress) unified process model delivered, and all system executables were dynamically linked, boot times went down by a lot.
Re: Swift Static Linux SDK
#215Earlier quoted context omitted.
Not to my knowledge. But consider something like crypto, libssl ... which is linked to almost everything, or libxz, zlib, etc. If there is a bug in a shared library, one can replace it with a interm one very easily, and the whole operating system will use it. One can even replace it with a different implementation assuming ABI compatibility, without having to do "much". Enclaves like Go, Rust, Swift (things that insi…
For what it's worth, Rust uses libc by default in Linux. On the other side, there are quite a few self-updating applications out there (browsers), and source control systems like Github will push notifications, and even pull requests for out of date dependencies. So pushing out a new version of a given application is pretty easy. If the application comes through Flathub or self-updates then it doesn't have to wait fo…
> then it doesn't have to wait for the distro maintainers
No, but it has to wait for each developer of each binary individually. Instead of relying on a team of maintainer, you now rely on all the developers.
"Self-update" isn't something magical: someone has to do build the new version and ship it. With static linking you still have to build and ship for every. single. binary. With dynamic linking you just build and ship the one library that everybody depends on.
Re: Swift Static Linux SDK
#216Earlier quoted context omitted.
It really sounds like you see it from the point of view of a developer who has never thought about how a Linux distribution works. Yes, for you as a user it's simpler to link statically and not learn about anything else. But distros are a bit more elaborate than that.
It sounds like you see it from the point of view of a disto maintainer and never thought about how awful the experience is for software developers. I want to just depend on some specific, latest version of a library. I don’t want to have to go look at which version of that library exists in 18 different Linux distributions. I don’t want to deal with bug reports because Debian patched one of my dependencies or replace…
> I don’t want to have to go look at which version of that library exists in 18 different Linux distributions.
If you make open source software, the solution is simply that you should not distribute your software [1]. Let distro maintainers do it, and suddenly it's a lot easier for you.
If you make proprietary software, then it's not exactly the problem of the Linux distros anymore so sure, feel free to link statically. I personally think you should do a mix of both: libraries like openssl you want to link dynamically from the system. Now some obscure dependency you may have that breaks compatibility randomly and is generally not distributed by major distros, probably you want to link them statically. But you should know that you are then responsible for them and the security issues they may bring (i.e. you should monitor them and update them regularly).
[1]: https://drewdevault.com/2019/12/09/Developers-shouldnt-distr...
Re: Swift Static Linux SDK
#217Earlier quoted context omitted.
In practice, it feels like everybody assumes that Rust is installed through Rustup and dependencies are statically linked from cargo. I have tried going the dynamic linking way, it's painful when it's not impossible.
Regardless of what "everybody assumes", you can in fact build rust binaries without using rustup or cargo. Distros do this. Yes, it's more painful for end users than just typing `cargo build`, but that's irrelevant to distro maintainers.
Some software (e.g. IDEs) will call `rustup` for some reason (yep, it happened to me and I therefore couldn't use that software).
> Yes, it's more painful for end users than just typing `cargo build`
Cargo is fine, I don't mind installing cargo. I just don't want my packages to be handled by my package manager. I don't want every project to ship their own custom package manager like rustup.
Re: Swift Static Linux SDK
#218What might a cross-platform GUI app look like with Swift? I'm assuming SwiftUI can't be used? Regardless, I'll definitely be reaching for Swift for one-off scripts. I've enjoyed the times I needed to use Swift for a React Native extension.
In iOS 18, there is now a SwiftUICore framework that's separate from SwiftUI, which I imagine consumes it. I don't see the new one on the documentation site. If that becomes public in a year or so, maybe you'd be able to replace one of the two frameworks to implement your own view system atop the attribute graph and data flow bits.
Re: Swift Static Linux SDK
#219Earlier quoted context omitted.
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.
Swift has its strengths against Go but it does not really beat Go at Go's own game. Where are channels and select? Why is async code special? Why do protocols have to be explicitly adopted? Why are errors "thrown" instead of returned?
The async question is actually really interesting - and gets at a few things Swift does very differently from some other languages.
Normal languages just sort of call functions on threads - and use locks when there is contention. You certainly can write the same sort of code in Swift - but that is not how async functions work.
The issue with locks is that waiting on a lock could be expensive - depending on the type of lock. And it also ties up the thread. If you have a thread pool you could end up with a lot of threads getting tied up in locks.
Async functions are suspendible. When they encounter a data hazard - the thread is released and allowed to go work on something else. When the conflict clears the function is picked back up and execution continues. Note: the way this is designed means that a _different_ thread may continue execution of the async function, and async functions should assume that they may change threads during execution. But this does prevent stalled threads just waiting on some condition. The compiler needs to extra notation to know your function has been designed around this sort of operation.
Basically: Async functions are not normal functions - they're allowed to be suspendible and may change threads mid execution - hence the extra notation. This improves both performance and safety.
Re: Swift Static Linux SDK
#220Earlier quoted context omitted.
How’s the compilation speed?If it’s going to replace Go, that’s gotta be sub second for a medium sized project on my clunky old laptop.
Assuming my experience with Swift 5 is still accurate, compilation speed is at least an order of magnitude slower than Go. It’s a much more powerful language. In my opinion slower compilation is worth it for all of its great features. (Does Go even have parametric enums?). But its definitely a trade off.
Ocaml makes me wonder if we really do need the trade off. It’s a fairly advanced language, and compiles super fast. I wonder why it’s such an outlier among advanced languages?