IIRC Arch does as well (or at least tries to).","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:25:00.000Z","created_at_i":1718141100,"id":40651689,"options":[],"parent_id":40651617,"points":null,"story_id":40651054,"text":"Fedora and Debian do this too. That's why it sometimes takes longer for a project to be packaged - you literally have to recursively package all of the dependencies first.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:18:33.000Z","created_at_i":1718140713,"id":40651617,"options":[],"parent_id":40651439,"points":null,"story_id":40651054,"text":"Some distros do actually break out rust dependencies into separate packages (e.g. Guix does this). It's just that a lot of rust software isn't distributed primarily by distros.","title":null,"type":"comment","url":null},{"author":"frankjr","children":[{"author":"palata","children":[],"created_at":"2024-06-11T21:27:17.000Z","created_at_i":1718141237,"id":40651722,"options":[],"parent_id":40651659,"points":null,"story_id":40651054,"text":"I totally agree. Static linking is essentially easier for people who don't want to care. But ignoring security does not mean it solves it, on the contrary.
Static linking comes with a lot of issues, just like dynamic linking is not perfect. I really think it depends on the use-case, and that's why I want to have the choice.","title":null,"type":"comment","url":null},{"author":"josephg","children":[{"author":"palata","children":[{"author":"josephg","children":[{"author":"palata","children":[{"author":"kibwen","children":[{"author":"amszmidt","children":[{"author":"kibwen","children":[{"author":"comex","children":[],"created_at":"2024-06-12T03:53:38.000Z","created_at_i":1718164418,"id":40654293,"options":[],"parent_id":40654037,"points":null,"story_id":40651054,"text":"> The distro repositories are being continuously rebuilt, because packages are receiving continuous updates.
At large timescales, yes. But not at timescales relevant for rapid security updates.","title":null,"type":"comment","url":null},{"author":"amszmidt","children":[{"author":"kibwen","children":[{"author":"palata","children":[{"author":"kibwen","children":[{"author":"amszmidt","children":[],"created_at":"2024-06-13T05:03:16.000Z","created_at_i":1718254996,"id":40666132,"options":[],"parent_id":40665889,"points":null,"story_id":40651054,"text":"I don\u2019t see how Nix is close to your dream, Nix is just like any other system and links things like any other system.. I.e. mostly avoids static linking.
Debian did the strongest push for reproducible builds, and is 100% source available.","title":null,"type":"comment","url":null}],"created_at":"2024-06-13T04:19:29.000Z","created_at_i":1718252369,"id":40665889,"options":[],"parent_id":40660454,"points":null,"story_id":40651054,"text":"That's the dream. I want a system that's 100% source-available, 100% reproducible, and 100% statically-defined. Nix looks like the closest thing to that right now.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T17:07:37.000Z","created_at_i":1718212057,"id":40660454,"options":[],"parent_id":40657849,"points":null,"story_id":40651054,"text":"So all your binaries are statically linked on your system? 100%?","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T13:22:15.000Z","created_at_i":1718198535,"id":40657849,"options":[],"parent_id":40654642,"points":null,"story_id":40651054,"text":"I'm against dlopen as well. If something makes use of LD_LIBRARY_PATH, rest assured that I want it excised from my system. Reproducibly-built, fully-static binaries are what I want, ideally with an accessible SBOM embedded.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T04:50:26.000Z","created_at_i":1718167826,"id":40654642,"options":[],"parent_id":40654037,"points":null,"story_id":40651054,"text":"They aren\u2019t being rebuilt with that kind of frequency as you might think.
They get rebuilt when a change in the package is made, not when a change in a dependency is made \u2014 which is a huge difference.
There are plenty of packages that might not get an update for a long time (month, half year, \u2026 whatever their release cadence might be).
Dynamic linking makes it _easier_ to handle security, including checking if your program is linking to a broken library \u2014 static linking does not have the same means.
Statically linked programs don\u2019t mean you know what is being run either, you can always dlopen() and all kind of shenanigans like Go and Rust do.
What is a security nightmare is statically linked binaries, you have no clue what they are linked against.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T03:04:10.000Z","created_at_i":1718161450,"id":40654037,"options":[],"parent_id":40653878,"points":null,"story_id":40651054,"text":"The distro repositories are being continuously rebuilt, because packages are receiving continuous updates. In the meantime, as far as I'm concerned dynamic linking is itself a security failure, because if I run a binary I want to know exactly what code is being run, without having to worry about dynamic linking and loading nonsense inserting itself into my process.","title":null,"type":"comment","url":null},{"author":"eviks","children":[{"author":"amszmidt","children":[{"author":"tracker1","children":[{"author":"amszmidt","children":[],"created_at":"2024-06-12T19:49:06.000Z","created_at_i":1718221746,"id":40662245,"options":[],"parent_id":40661679,"points":null,"story_id":40651054,"text":"That is a very, very tiny subset of things that are installed on any GNU or BSD system, and that need to get security fixes. Just recall the xz/sshd/system debacle, to patch your system all you needed was to replace libxz / libzma -- a DSO! This obviously ignores lots of other work -- but that work would have ballooned if standard practise was to statically link everything.
The amount of work spent finding usages of static linkage, and figuring out which version of libxz (or whatever it was called) just to be very sure that one wasn't using the compromised version was atrocious, no thanks.","title":null,"type":"comment","url":null},{"author":"palata","children":[{"author":"tracker1","children":[{"author":"palata","children":[],"created_at":"2024-06-14T11:59:05.000Z","created_at_i":1718366345,"id":40679998,"options":[],"parent_id":40670478,"points":null,"story_id":40651054,"text":"> You can dynamically link with Rust
Do you have experience with that, or do you say it because you believe it's possible? Genuinely interested, because I have been looking into it and my conclusion was that it does not really do what I expect from "dynamic linking".
See e.g. https://news.ycombinator.com/item?id=40665343 and https://news.ycombinator.com/item?id=40661874","title":null,"type":"comment","url":null}],"created_at":"2024-06-13T14:54:30.000Z","created_at_i":1718290470,"id":40670478,"options":[],"parent_id":40663262,"points":null,"story_id":40651054,"text":"Of course... and I'm not suggesting that every app in a linux distro should be as such. You can dynamically link with Rust, Go, etc. That said, for one of the 3-4 GUI apps that most people use, the distro process tends to leave people with relatively old versions missing critical bug fixes or features.
I tend to keep my host OS pretty bare, and most of my runtime apps in Flatpak and the stuff I'm working on in Docker.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T21:22:34.000Z","created_at_i":1718227354,"id":40663262,"options":[],"parent_id":40661679,"points":null,"story_id":40651054,"text":"> 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.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T19:00:49.000Z","created_at_i":1718218849,"id":40661679,"options":[],"parent_id":40660524,"points":null,"story_id":40651054,"text":"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 for the distro maintainers to get the update out.","title":null,"type":"comment","url":null},{"author":"cesarb","children":[{"author":"amszmidt","children":[],"created_at":"2024-06-12T19:36:40.000Z","created_at_i":1718221000,"id":40662081,"options":[],"parent_id":40661992,"points":null,"story_id":40651054,"text":"The aversion to static linkage predates that, back many years static linkage also had other issues that have been solved today (ALSR ..). Many of the very basic points that Ulrich Drepper made some odd 20 years back (https://akkadia.org/drepper/no_static_linking.html) still hold.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T19:29:13.000Z","created_at_i":1718220553,"id":40661992,"options":[],"parent_id":40660524,"points":null,"story_id":40651054,"text":"> But consider something like crypto, libssl ... which is linked to almost everything, or libxz, zlib, etc.
AFAIK, the reason most Linux distributions have an allergic reaction to static linking is because of zlib. There was a vulnerability in zlib some time ago, and it required the distributions to find every single program which had its own copy of zlib (vendoring zlib used to be common back then), update these copies with the security fix (not necessarily trivial, since the vendored copy might be a customized variant of an older zlib release), and rebuild all these packages (which is a lot of "fun" when some of the packages are in a "failed to build from source" aka FTBFS state). The distributions learned their lesson back then.","title":null,"type":"comment","url":null},{"author":"BodkinsOdds","children":[],"created_at":"2024-06-15T17:34:10.000Z","created_at_i":1718472850,"id":40691208,"options":[],"parent_id":40660524,"points":null,"story_id":40651054,"text":"Go is the only one of the three that directly uses syscalls. Rust and Swift both go through libc. Swift never even had the option of directly using syscalls, since it was originally designed for MacOS, and syscalls are so unstable there that they've changed in minor version updates.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T17:13:33.000Z","created_at_i":1718212413,"id":40660524,"options":[],"parent_id":40655534,"points":null,"story_id":40651054,"text":"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 insist on using direct sys calls, and eschewing system libraries) would need to implement their own versions, or use FFI, and then you're SOL anyway if you really insist to use static linking... And who knows what kind of bugs might crop up there that don't match whatever anything anyone else uses.
Shrug :-)","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T07:32:18.000Z","created_at_i":1718177538,"id":40655534,"options":[],"parent_id":40653878,"points":null,"story_id":40651054,"text":"Do you know whether someone has made an estimate based on the history of actual vulnerabilities of how much rebuilding would need to be done in a non-shared library approach?","title":null,"type":"comment","url":null},{"author":"tracker1","children":[],"created_at":"2024-06-12T18:57:11.000Z","created_at_i":1718218631,"id":40661638,"options":[],"parent_id":40653878,"points":null,"story_id":40651054,"text":"Most USERS only run a handful of applications any given month. I think upgrading 1-2 applications is easier to reason with over even a hundred packages.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T02:28:58.000Z","created_at_i":1718159338,"id":40653878,"options":[],"parent_id":40653312,"points":null,"story_id":40651054,"text":"Debian has about 59000 packages. Even rebuilding 1k of that is a significant pain on build infrastructure, specially in one go, if say a vulnerable library is found.
You also now get a huge set of users who will now download these 1k of updated packages. Not to mention the utter fun of trying to understand why your system just requires maybe 100 packages to be updated\u2026
Compare to upgrading a single shared library.","title":null,"type":"comment","url":null},{"author":"LtWorf","children":[],"created_at":"2024-06-12T04:43:57.000Z","created_at_i":1718167437,"id":40654610,"options":[],"parent_id":40653312,"points":null,"story_id":40651054,"text":"For distributions, it costs a lot of money they don't have to just be rebuilding stuff all the time.
For randomly downloaded binaries from the internet it means you will most likely keep using it with the vulnerabilities for years to come.","title":null,"type":"comment","url":null},{"author":"palata","children":[{"author":"josephg","children":[{"author":"palata","children":[],"created_at":"2024-06-12T21:37:52.000Z","created_at_i":1718228272,"id":40663450,"options":[],"parent_id":40662796,"points":null,"story_id":40651054,"text":"> I don\u2019t 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...","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T20:35:55.000Z","created_at_i":1718224555,"id":40662796,"options":[],"parent_id":40657430,"points":null,"story_id":40651054,"text":"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\u2019t want to have to go look at which version of that library exists in 18 different Linux distributions. I don\u2019t 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\u2019m happy for someone to update the version of my dependency if it has security patches. But the rest? A total nightmare. I\u2019ll take cargo / npm / swift / etc style versioning every day.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T12:40:10.000Z","created_at_i":1718196010,"id":40657430,"options":[],"parent_id":40653312,"points":null,"story_id":40651054,"text":"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.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T00:47:03.000Z","created_at_i":1718153223,"id":40653312,"options":[],"parent_id":40652604,"points":null,"story_id":40651054,"text":"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.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T22:53:33.000Z","created_at_i":1718146413,"id":40652604,"options":[],"parent_id":40651890,"points":null,"story_id":40651054,"text":"> It should be pretty easy to programmatically update a lock file, run the tests, and rebuild a package.
You still fundamentally need to rebuild (or at least relink) and re-distribute all the packages, whereas with shared libraries... well you just update that one package.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:40:29.000Z","created_at_i":1718142029,"id":40651890,"options":[],"parent_id":40651777,"points":null,"story_id":40651054,"text":"Only because the build tooling is less mature.
It should be pretty easy to programmatically update a lock file, run the tests, and rebuild a package. For rust crates that are compiled and packaged straight from git, you could probably automate that today.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:31:32.000Z","created_at_i":1718141492,"id":40651777,"options":[],"parent_id":40651744,"points":null,"story_id":40651054,"text":"> It would make this sort of vulnerability scanning much easier to do.
Scanning, sure. Fixing... surely much harder than with shared libraries.","title":null,"type":"comment","url":null},{"author":"LtWorf","children":[],"created_at":"2024-06-11T21:47:55.000Z","created_at_i":1718142475,"id":40651977,"options":[],"parent_id":40651744,"points":null,"story_id":40651054,"text":"> Packages get rebuilt all the time. This is fine.
You forgot to link the image with the dog sitting in the fire.","title":null,"type":"comment","url":null},{"author":"dolmen","children":[],"created_at":"2024-06-11T21:54:07.000Z","created_at_i":1718142847,"id":40652034,"options":[],"parent_id":40651744,"points":null,"story_id":40651054,"text":"> 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.
Go binaries have that. You can apply "go version -m" to any recent Go binary.
Also "govulncheck".
Examples:
go version -m $(which go)\n go install golang.org/x/vuln/cmd/govulncheck@latest\n go version -m $(which govulncheck)\n govulncheck -mode=binary $(which govulncheck)\n for b in $(go env GOPATH)/bin/*; do govulncheck -mode=binary "$b"; donePackages 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.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:22:17.000Z","created_at_i":1718140937,"id":40651659,"options":[],"parent_id":40651439,"points":null,"story_id":40651054,"text":"> 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 respect the lock file (or the project doesn't use it) and you just fetch the latest compatible dependencies at the time of build, you now have no idea if you're affected or not by the vulnerability because you don't have the exact resolved versions stored anywhere (https://github.com/rust-lang/rfcs/pull/2801).","title":null,"type":"comment","url":null},{"author":"palata","children":[{"author":"akira2501","children":[],"created_at":"2024-06-11T21:36:56.000Z","created_at_i":1718141816,"id":40651845,"options":[],"parent_id":40651691,"points":null,"story_id":40651054,"text":"You're not forced to with Go. CGO exists and requires dynamic linking.","title":null,"type":"comment","url":null},{"author":"newZWhoDis","children":[{"author":"palata","children":[],"created_at":"2024-06-12T12:44:07.000Z","created_at_i":1718196247,"id":40657464,"options":[],"parent_id":40652920,"points":null,"story_id":40651054,"text":"I couldn't disagree more.
> Everything about the shared lib model is stupid
I don't think we can discuss if that's you're stance. But also I don't think you understand the shared lib model if you think like that.","title":null,"type":"comment","url":null},{"author":"lmz","children":[{"author":"palata","children":[],"created_at":"2024-06-12T15:37:01.000Z","created_at_i":1718206621,"id":40659298,"options":[],"parent_id":40658208,"points":null,"story_id":40651054,"text":"Honestly a problem is that most developers just don't understand how it works. Docker / static linking solves a lack of understanding, mostly. That's why they are popular.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T13:55:54.000Z","created_at_i":1718200554,"id":40658208,"options":[],"parent_id":40652920,"points":null,"story_id":40651054,"text":"Dynamic linking seems to work fine for Windows or OSX. Maybe it's open source + dynamic linking that's the problem.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T23:38:20.000Z","created_at_i":1718149100,"id":40652920,"options":[],"parent_id":40651691,"points":null,"story_id":40651054,"text":"More software should \u201cenforce\u201d their preferences, many decisions are objectively superior and this \u201canything goes\u201d attitude has done nothing but hurt OSS/Linux adoption.
Everything about the shared lib model is stupid, and has contributed to poor Linux market share to date.","title":null,"type":"comment","url":null},{"author":"kibwen","children":[{"author":"palata","children":[{"author":"umanwizard","children":[{"author":"palata","children":[],"created_at":"2024-06-12T21:39:57.000Z","created_at_i":1718228397,"id":40663481,"options":[],"parent_id":40661634,"points":null,"story_id":40651054,"text":"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.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T18:56:42.000Z","created_at_i":1718218602,"id":40661634,"options":[],"parent_id":40657453,"points":null,"story_id":40651054,"text":"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.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T12:42:50.000Z","created_at_i":1718196170,"id":40657453,"options":[],"parent_id":40653320,"points":null,"story_id":40651054,"text":"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.","title":null,"type":"comment","url":null},{"author":"glandium","children":[{"author":"kibwen","children":[{"author":"glandium","children":[],"created_at":"2024-06-13T04:40:57.000Z","created_at_i":1718253657,"id":40666018,"options":[],"parent_id":40665881,"points":null,"story_id":40651054,"text":"The keyword is "arbitrary". Say you have dependencies on reqwest and clap, want to dynamically link against them? Not gonna happen. That's what people talk about most of the time for static vs. dynamic linking, at least in my circles.","title":null,"type":"comment","url":null}],"created_at":"2024-06-13T04:17:38.000Z","created_at_i":1718252258,"id":40665881,"options":[],"parent_id":40665343,"points":null,"story_id":40651054,"text":"> It doesn't support dynamically linking arbitrary dependencies
I don't understand why one would think this. You make it sound as though Rust only supports dynamic linking for glibc, but that's certainly not true.","title":null,"type":"comment","url":null}],"created_at":"2024-06-13T02:27:50.000Z","created_at_i":1718245670,"id":40665343,"options":[],"parent_id":40653320,"points":null,"story_id":40651054,"text":"That's kind of a disingenuous take. Rust supports producing dynamically loadable libraries. It doesn't support dynamically linking arbitrary dependencies, which is what most people would understand from "Rust supports dynamic linking" in a discussion about static linking.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T00:48:10.000Z","created_at_i":1718153290,"id":40653320,"options":[],"parent_id":40651691,"points":null,"story_id":40651054,"text":"> I just don't want you to force me.
Rust supports dynamic linking, and has since well before 1.0.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:25:03.000Z","created_at_i":1718141103,"id":40651691,"options":[],"parent_id":40651439,"points":null,"story_id":40651054,"text":"As you say, a typical Rust program can easily depend on hundreds of crates that nobody really checks. That's a security issue.
The whole point of a distro is that someone distributes them, so you can choose which distro you want to trust.
What I don't like about Rust and Go is that they enforce their preference. I am fine if you want to link everything statically. I just don't want you to force me.","title":null,"type":"comment","url":null},{"author":"lynndotpy","children":[{"author":"LtWorf","children":[],"created_at":"2024-06-11T21:52:52.000Z","created_at_i":1718142772,"id":40652018,"options":[],"parent_id":40651697,"points":null,"story_id":40651054,"text":"And the "I now have to evaluate thousands of libraries instead of 10 well established framework" tax?
I've seen plenty of bad go libraries. For example their authors will be unaware of isatty() so they will output control codes when piped.
If you factor in the time to find a competently written library (and quite possibly write one yourself) it starts to be less convenient.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:25:32.000Z","created_at_i":1718141132,"id":40651697,"options":[],"parent_id":40651439,"points":null,"story_id":40651054,"text":"I feel the same. A huge part of the pleasure of Go and Rust are that I never run into dependency problems. I'm happy to pay the "Hello World is 4MB" tax.","title":null,"type":"comment","url":null},{"author":"LtWorf","children":[{"author":"j1elo","children":[{"author":"icedchai","children":[{"author":"j1elo","children":[{"author":"icedchai","children":[{"author":"j1elo","children":[{"author":"icedchai","children":[],"created_at":"2024-06-12T23:27:51.000Z","created_at_i":1718234871,"id":40664295,"options":[],"parent_id":40656273,"points":null,"story_id":40651054,"text":"Yeah, they should just define a new command line option (and perhaps a new command that defaults to this behavior, say vpip or vpython or something.) The virtualenvs take some getting use to. I've been using python for over 15 years so it's second nature.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T09:41:14.000Z","created_at_i":1718185274,"id":40656273,"options":[],"parent_id":40653842,"points":null,"story_id":40651054,"text":"They are so close, though! I think one lesson Python took is that it's better, even mandatory, to use venv and install stuff in isolated containment.
This is exactly what Node/NPM does: "npm instal" creates a new dir, "./node_modules" and installs stuff there, and next "npm" commands will transparently refer to that subdir. This is, in effect, the same thing as a Python's venv! to the point that in my scripts I always name them "python_modules", to give other unfamiliar devs a clue of what it is.
If "pip install" just did this transparently, without introducing the whole concept of venvs to the user, it would be a huge step forward. I cannot imagine how it would suck if NPM didn't make its node_module dir, and instead it forced you to first learn all the idiosyncrasies of module isolation.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T02:20:43.000Z","created_at_i":1718158843,"id":40653842,"options":[],"parent_id":40652739,"points":null,"story_id":40651054,"text":"You are right. It's not a good experience for new developers, especially given how long Python has been around.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T23:12:51.000Z","created_at_i":1718147571,"id":40652739,"options":[],"parent_id":40652511,"points":null,"story_id":40651054,"text":"I just knew the basics. So I was just following commands from stack overflow or similar. Silly me, thinking that it would work logically like other languages do! Later I ended up learning about all that stuff with venvs and whatnot, not to mention it's not even a unified solution but there are multiple alternatives, adding to the confusion... All this, no doubt, is a consequence of how terrible the Python packaging story is. Rust, Go, Ruby, Node, and more, I had used without remotely similar hassles.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T22:43:12.000Z","created_at_i":1718145792,"id":40652511,"options":[],"parent_id":40652430,"points":null,"story_id":40651054,"text":"Were you using a virtualenv? Or were you pip installing into your distro / system python, like a true savage?","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T22:34:04.000Z","created_at_i":1718145244,"id":40652430,"options":[],"parent_id":40651946,"points":null,"story_id":40651054,"text":"I had my Python and pip installed from distribution packages. One day I needed to build something from source, but it needed Meson...
Ok installed Meson also from my distro packages! But no, the project required a newer Meson version.
Ok let's install Meson with pip! But no, it turns out pip packages themselves can require a minimum pip version!! Go figure.
So I couldn't build that program without first pip-installing Meson, and I couldn't pip-install Meson without first pip-installing a more modern version of pip itself.
Guess how well it worked when I upgraded pip. Spoiler: not a smooth way to discover that Python packaging is a joke.","title":null,"type":"comment","url":null},{"author":"icedchai","children":[{"author":"LtWorf","children":[{"author":"icedchai","children":[],"created_at":"2024-06-12T02:21:12.000Z","created_at_i":1718158872,"id":40653844,"options":[],"parent_id":40652598,"points":null,"story_id":40651054,"text":"I'm curious what problems you ran into with it?","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T22:53:05.000Z","created_at_i":1718146385,"id":40652598,"options":[],"parent_id":40652457,"points":null,"story_id":40651054,"text":"Yes. Having tried it led me to write that comment.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T22:37:39.000Z","created_at_i":1718145459,"id":40652457,"options":[],"parent_id":40651946,"points":null,"story_id":40651054,"text":"Have you tried "poetry"?","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:45:04.000Z","created_at_i":1718142304,"id":40651946,"options":[],"parent_id":40651439,"points":null,"story_id":40651054,"text":"> 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?","title":null,"type":"comment","url":null},{"author":"OKThatWillDo","children":[{"author":"PaulDavisThe1st","children":[{"author":"OKThatWillDo","children":[{"author":"mkl","children":[{"author":"OKThatWillDo","children":[{"author":"mkl","children":[],"created_at":"2024-06-13T04:57:52.000Z","created_at_i":1718254672,"id":40666103,"options":[],"parent_id":40665433,"points":null,"story_id":40651054,"text":"That's a different verb, with a different meaning.","title":null,"type":"comment","url":null},{"author":"spacechild1","children":[],"created_at":"2024-06-13T09:42:18.000Z","created_at_i":1718271738,"id":40667650,"options":[],"parent_id":40665433,"points":null,"story_id":40651054,"text":"Did you read the link?","title":null,"type":"comment","url":null}],"created_at":"2024-06-13T02:49:04.000Z","created_at_i":1718246944,"id":40665433,"options":[],"parent_id":40664330,"points":null,"story_id":40651054,"text":""Vendor" isn't the verb. The verb is "vend."","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T23:33:44.000Z","created_at_i":1718235224,"id":40664330,"options":[],"parent_id":40664140,"points":null,"story_id":40651054,"text":"It's the verb vendor: https://en.wiktionary.org/wiki/vendor#Verb","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T23:02:49.000Z","created_at_i":1718233369,"id":40664140,"options":[],"parent_id":40653689,"points":null,"story_id":40651054,"text":"Thanks. Not an appropriate use of the noun "vendor," so I would never have guessed that.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T01:51:25.000Z","created_at_i":1718157085,"id":40653689,"options":[],"parent_id":40652386,"points":null,"story_id":40651054,"text":"It means "add the source for your dependencies to your own codebase and build them with your build system".","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T22:29:56.000Z","created_at_i":1718144996,"id":40652386,"options":[],"parent_id":40651439,"points":null,"story_id":40651054,"text":""vendor all the dependencies"
What does that mean?","title":null,"type":"comment","url":null},{"author":"PaulDavisThe1st","children":[{"author":"palata","children":[{"author":"PaulDavisThe1st","children":[{"author":"palata","children":[{"author":"PaulDavisThe1st","children":[{"author":"palata","children":[],"created_at":"2024-06-12T17:08:58.000Z","created_at_i":1718212138,"id":40660478,"options":[],"parent_id":40660087,"points":null,"story_id":40651054,"text":"I don't see that in Kotlin for instance.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T16:38:58.000Z","created_at_i":1718210338,"id":40660087,"options":[],"parent_id":40659317,"points":null,"story_id":40651054,"text":"I would suggest that this caused more by ideas about the appropriate scope and scale of libraries in the 2020s than anything specifically connected to the language in use.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T15:38:08.000Z","created_at_i":1718206688,"id":40659317,"options":[],"parent_id":40657820,"points":null,"story_id":40651054,"text":"> What is it that makes you think that C/C++ does not do this also?
My experience. I haven't worked in a single C++ project that had hundreds of dependencies, but I encounter those regularly in Rust/npm.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T13:19:30.000Z","created_at_i":1718198370,"id":40657820,"options":[],"parent_id":40657498,"points":null,"story_id":40651054,"text":"> My feeling is that making it super easy to pull 50 transitive dependencies without realizing it does not help
What is it that makes you think that C/C++ does not do this also?
[ EDIT: this also has something to do with the typical size and scope of C/C++ libraries ]","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T12:48:19.000Z","created_at_i":1718196499,"id":40657498,"options":[],"parent_id":40653682,"points":null,"story_id":40651054,"text":"I started a small project both in C++ and Rust.
When in C++ I had 2 direct dependencies it resulted in 6 total dependencies (direct + transitive).
In Rust I had 5 direct dependencies (because some standard stuff is not in the standard lib) and it resulted in... 300 total dependencies.
> but it is by no means determined by language or even context.
Not sure what you mean there. My feeling is that making it super easy to pull 50 transitive dependencies without realizing it does not help. If you have to manually handle every single dependency, first it forces you to look at them (that's a good thing), and second it encourages you to minimize them.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T01:50:38.000Z","created_at_i":1718157038,"id":40653682,"options":[],"parent_id":40651439,"points":null,"story_id":40651054,"text":"> Modern languages are not like C/C++
I think there's a bit of a misconception here.
Ardour is written in C++ and depends on 80+ other libraries.
The dependency situation may be exacerbated by packaging culture that encourages the use of lots of relatively small dependencies, but it is by no means determined by language or even context.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:03:11.000Z","created_at_i":1718139791,"id":40651439,"options":[],"parent_id":40651323,"points":null,"story_id":40651054,"text":"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 here: vendor all the dependencies, and distros can't mess with them. Makes it easier for upstream and the distro.
Modern languages are not like C/C++: a single non-trivial rust program can easily depend on 100+ crates, and re-creating crates.io in your package manager is just a bad idea, even putting aside that there's probably major version incompatibilities the moment you go beyond a handful of programs. Look at the disaster that's python package management, that's not where you want to end up.","title":null,"type":"comment","url":null},{"author":"mshockwave","children":[],"created_at":"2024-06-11T21:05:34.000Z","created_at_i":1718139934,"id":40651469,"options":[],"parent_id":40651323,"points":null,"story_id":40651054,"text":"> Not sure I understand that. Is it something specific to Swift, or is it exactly what is expected from using shared libraries?
More of a shared library issue I believe.
> Say my Linux distribution distributes some Swift runtime, then the corresponding Swift packages should have been built for this runtime as well. Just like when my Linux distribution distributes a libc, the corresponding packages need to be built for this libc. Right?
That's correct","title":null,"type":"comment","url":null},{"author":"manmal","children":[{"author":"Longhanks","children":[{"author":"BodkinsOdds","children":[],"created_at":"2024-06-15T17:38:09.000Z","created_at_i":1718473089,"id":40691245,"options":[],"parent_id":40662420,"points":null,"story_id":40651054,"text":"Nope. For the foreseeable future, stable ABI on other platforms is basically only going to happen if a distro starts supporting an ABI stable standard library on their own.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T20:02:24.000Z","created_at_i":1718222544,"id":40662420,"options":[],"parent_id":40651485,"points":null,"story_id":40651054,"text":"AFAIK they claim ABI stability only for Apple platforms, explicitly neither Linux, nor Windows. Has that changed?","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:06:28.000Z","created_at_i":1718139988,"id":40651485,"options":[],"parent_id":40651323,"points":null,"story_id":40651054,"text":"A Swift program for a particular distribution will dynamically link some system libraries from the distro, and these libs might change on every distro update. They mention in the post that dynamic linking can cause versioning issues.
> Say my Linux distribution distributes some Swift runtime
That runtime would need to be compatible with the Swift program. Nowadays that\u2019s not a big issue due to ABI stability (https://www.swift.org/blog/abi-stability-and-apple/), but this would close the door on new features that need runtime support (need an OS update then, or the OS must come with multiple runtimes).","title":null,"type":"comment","url":null},{"author":"umanwizard","children":[{"author":"palata","children":[{"author":"tux3","children":[{"author":"LtWorf","children":[{"author":"kibwen","children":[{"author":"LtWorf","children":[{"author":"umanwizard","children":[{"author":"whytevuhuni","children":[],"created_at":"2024-06-12T19:18:39.000Z","created_at_i":1718219919,"id":40661874,"options":[],"parent_id":40656438,"points":null,"story_id":40651054,"text":"Due to the lack of ABI stability, the resulting dynamic library is tied to the exact binary hash of the Rust compiler (which includes the dependencies rustc was built from).
Those dynamic libraries will also not remain ABI stable if their code changes (because Rust's semver specifically applies to the public API, but the public API is free to pass around structs with private fields, which may alter the layout drastically even for minor semver-compatible changes).
So this helps with some aspects (such as libraries being reused between binaries, reducing disk usage).
But it does not help with the issue most discussed in this thread: that of security updates (all libraries have to be rebuilt whenever rustc changes or a dependency changes, all programs (potentially the entire operating system) have to be redownloaded by all users, etc).","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T10:16:06.000Z","created_at_i":1718187366,"id":40656438,"options":[],"parent_id":40654594,"points":null,"story_id":40651054,"text":"> Rust supports compiling each crate as a separate .so and then linking all of them?
Yes, by passing crate-type=dylib to the compiler.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T04:40:35.000Z","created_at_i":1718167235,"id":40654594,"options":[],"parent_id":40653335,"points":null,"story_id":40651054,"text":"Rust supports compiling each crate as a separate .so and then linking all of them?
That's not at all how debian packages written in rust are linked. So the person I replied to is incorrect.
I suspect you're incorrect as well and what you claim doesn't exist at all, but you're claiming a different thing.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T00:51:02.000Z","created_at_i":1718153462,"id":40653335,"options":[],"parent_id":40652087,"points":null,"story_id":40651054,"text":"Rust supports dynamic linking, it's just not the default, so you need to configure a given crate to use it at build time.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:59:10.000Z","created_at_i":1718143150,"id":40652087,"options":[],"parent_id":40651980,"points":null,"story_id":40651054,"text":"No, crates will be statically linked anyway in general.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:48:14.000Z","created_at_i":1718142494,"id":40651980,"options":[],"parent_id":40651755,"points":null,"story_id":40651054,"text":"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.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:30:03.000Z","created_at_i":1718141403,"id":40651755,"options":[],"parent_id":40651593,"points":null,"story_id":40651054,"text":"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!","title":null,"type":"comment","url":null},{"author":"PaulDavisThe1st","children":[],"created_at":"2024-06-12T01:52:56.000Z","created_at_i":1718157176,"id":40653698,"options":[],"parent_id":40651593,"points":null,"story_id":40651054,"text":"For decades, Unix-y software has been distributed with dynamic linking made possible by the use of a startup script that also sets LD_LIBRARY_PATH (which means the dynamic linker will find the libs that come with the software in preference to system-provided ones.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:16:50.000Z","created_at_i":1718140610,"id":40651593,"options":[],"parent_id":40651323,"points":null,"story_id":40651054,"text":"Dynamic linking works fine for software that is distributed by distros, but lots of software isn't.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T20:51:27.000Z","created_at_i":1718139087,"id":40651323,"options":[],"parent_id":40651054,"points":null,"story_id":40651054,"text":"> 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 some Swift runtime, then the corresponding Swift packages should have been built for this runtime as well. Just like when my Linux distribution distributes a libc, the corresponding packages need to be built for this libc. Right?
Still, it's cool that Swift provides static linking. But like in any language, the best IMHO is when the Linux distribution can choose how it wants to distribute a package. I tend to like shared libraries, and already Rust seems to be interfering and imposing its preferences. I am happy if Swift doesn't.","title":null,"type":"comment","url":null},{"author":"Vt71fcAqt7","children":[{"author":"Mandelmus","children":[{"author":"oddevan","children":[{"author":"_mlbt","children":[{"author":"OKThatWillDo","children":[{"author":"potatolicious","children":[{"author":"Redoubts","children":[{"author":"OKThatWillDo","children":[{"author":"_mlbt","children":[],"created_at":"2024-06-13T13:40:57.000Z","created_at_i":1718286057,"id":40669519,"options":[],"parent_id":40664118,"points":null,"story_id":40651054,"text":"In this instance they're talking about implementing network protocols, such as HTTP, where one end is the client and the other end of the connection is the server.
It's confusing because the Swift language also has the concept of "protocols" which are basically the equivalent of Java and C#'s interfaces if you're familiar with those languages.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T22:58:40.000Z","created_at_i":1718233120,"id":40664118,"options":[],"parent_id":40655997,"points":null,"story_id":40651054,"text":"That's right. I did a search but this term does not seem to have a trendy or thorough definition.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T08:56:35.000Z","created_at_i":1718182595,"id":40655997,"options":[],"parent_id":40652657,"points":null,"story_id":40651054,"text":"I'm guessing they clicked onto the Built with SwiftNIO link and saw this at https://github.com/apple/swift-nio.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T23:01:06.000Z","created_at_i":1718146866,"id":40652657,"options":[],"parent_id":40652434,"points":null,"story_id":40651054,"text":"Not a super-expert but I've used Vapor on some personal projects. Do you have a link to the mention for "protocol server"? I'm not familiar with the concept but might be able to help.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T22:34:10.000Z","created_at_i":1718145250,"id":40652434,"options":[],"parent_id":40652137,"points":null,"story_id":40651054,"text":"Thanks. What is a "protocol server?"","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T22:03:58.000Z","created_at_i":1718143438,"id":40652137,"options":[],"parent_id":40651818,"points":null,"story_id":40651054,"text":"I haven't used it yet, but I've heard really good things about Vapor as far as server side Swift goes...
https://vapor.codes","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:34:59.000Z","created_at_i":1718141699,"id":40651818,"options":[],"parent_id":40651503,"points":null,"story_id":40651054,"text":"I'm really interested in exploring it for building web app backends because of this. Being able to have a drag-and-drop distribution is even better.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:08:31.000Z","created_at_i":1718140111,"id":40651503,"options":[],"parent_id":40651486,"points":null,"story_id":40651054,"text":"It's a beautiful language that's a joy to write. It's safe and ergonomic, and has an extremely powerful type system. I'd say those are good reasons to use Swift.","title":null,"type":"comment","url":null},{"author":"e63f67dd-065b","children":[{"author":"hbn","children":[],"created_at":"2024-06-11T21:31:31.000Z","created_at_i":1718141491,"id":40651776,"options":[],"parent_id":40651510,"points":null,"story_id":40651054,"text":"The GP was asking specifically about non-Apple development","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:09:19.000Z","created_at_i":1718140159,"id":40651510,"options":[],"parent_id":40651486,"points":null,"story_id":40651054,"text":"The main reason is that Apple has effectively deprecated Objective-C for ios/macos development going forward. It's not going away for probably another decade+, but all documentation is now in Swift, new APIs are written with Swift in mind, etc.
Think of it this way: in 5-10 years, ObjC will be the python2 of Apple development.","title":null,"type":"comment","url":null},{"author":"righthand","children":[{"author":"criddell","children":[{"author":"righthand","children":[],"created_at":"2024-06-12T14:37:41.000Z","created_at_i":1718203061,"id":40658684,"options":[],"parent_id":40651803,"points":null,"story_id":40651054,"text":"CPP","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:33:58.000Z","created_at_i":1718141638,"id":40651803,"options":[],"parent_id":40651556,"points":null,"story_id":40651054,"text":"Out of curiosity, which language works best for you and your use case?","title":null,"type":"comment","url":null},{"author":"josephg","children":[{"author":"boffinAudio","children":[{"author":"josephg","children":[{"author":"boffinAudio","children":[],"created_at":"2024-06-13T07:37:20.000Z","created_at_i":1718264240,"id":40666987,"options":[],"parent_id":40658474,"points":null,"story_id":40651054,"text":"In this case, the question is whether to use Swift for a backend server on a Linux machine, or something else. That's the environment. I'd prefer Lua, simply because its a very proven language for that application.
Sure, Swift has sexy features that make it appealing to developers. But the ecosystem for server infrastructure on Lua is formidable.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T14:19:42.000Z","created_at_i":1718201982,"id":40658474,"options":[],"parent_id":40656567,"points":null,"story_id":40651054,"text":"Lua is nice, but it\u2019s a bit of a weird comparison for Swift. Swift is compiled and lua is interpreted. Swift is statically typed. Swift uses ref counting to Lua\u2019s runtime GC. And Swift has non nullable types by default, classes, enums, ADTs, match expressions and so on.
Lua is nice. But it\u2019s chalk and cheese comparing the languages. I can\u2019t think of many cases where you\u2019re trying to decide between lua and Swift.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T10:41:06.000Z","created_at_i":1718188866,"id":40656567,"options":[],"parent_id":40651810,"points":null,"story_id":40651054,"text":"Lua, I would say. Far easier to get it everywhere, and a very nice language, also.","title":null,"type":"comment","url":null},{"author":"Tainnor","children":[{"author":"sureglymop","children":[],"created_at":"2024-06-16T11:02:15.000Z","created_at_i":1718535735,"id":40696147,"options":[],"parent_id":40667468,"points":null,"story_id":40651054,"text":"I agree. Honestly a really nice and productive language.","title":null,"type":"comment","url":null}],"created_at":"2024-06-13T09:05:49.000Z","created_at_i":1718269549,"id":40667468,"options":[],"parent_id":40651810,"points":null,"story_id":40651054,"text":"Kotlin","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:34:32.000Z","created_at_i":1718141672,"id":40651810,"options":[],"parent_id":40651556,"points":null,"story_id":40651054,"text":"Which languages do you think are both better and have better cross platform support?","title":null,"type":"comment","url":null},{"author":"petereddy","children":[{"author":"pzo","children":[],"created_at":"2024-06-12T02:33:45.000Z","created_at_i":1718159625,"id":40653903,"options":[],"parent_id":40652060,"points":null,"story_id":40651054,"text":"maybe not far better as a language but on the same league but with far better cross-platform ecosystem that would be kotlin (native) or java (this days). You have great ecosystem for e.g. backend (Spring Boot) and modern java is also looking better every year.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:56:25.000Z","created_at_i":1718142985,"id":40652060,"options":[],"parent_id":40651556,"points":null,"story_id":40651054,"text":"There are definitely languages with better cross platform support. But far better languages? I think Swift is a pretty good language and I like to know what you think is far better than it.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:13:19.000Z","created_at_i":1718140399,"id":40651556,"options":[],"parent_id":40651486,"points":null,"story_id":40651054,"text":"Not really no, there are far better languages with better cross platform support.","title":null,"type":"comment","url":null},{"author":"airstrike","children":[],"created_at":"2024-06-11T21:21:37.000Z","created_at_i":1718140897,"id":40651651,"options":[],"parent_id":40651486,"points":null,"story_id":40651054,"text":"No language feels more pleasurable to write in. It's incredibly expressive and things are just dead simple 99% of the time
It's not perfect, but I hope it continues to flourish because it gets a lot right","title":null,"type":"comment","url":null},{"author":"jimbobthrowawy","children":[{"author":"robertjpayne","children":[],"created_at":"2024-06-12T22:42:24.000Z","created_at_i":1718232144,"id":40663997,"options":[],"parent_id":40652938,"points":null,"story_id":40651054,"text":"You can implement the same syntax for a renderer on other platforms but all of SwiftUI is closed source. So the diffing engine etc\u2026 all would need to be re-created from the ground up.
SwiftUI, like react uses some language constructs to make it look really fancy but in reality it's really simple nested data structs.
The real hard part is what the "DOM" provides for React and likewise what UIKit/iOS is doing with those data structs.","title":null,"type":"comment","url":null},{"author":"BodkinsOdds","children":[],"created_at":"2024-06-23T12:07:21.000Z","created_at_i":1719144441,"id":40766825,"options":[],"parent_id":40652938,"points":null,"story_id":40651054,"text":"There's a couple:
https://github.com/stackotter/swift-cross-ui (Linux + Windows)
https://github.com/TokamakUI/Tokamak (WASM + MacOS + some Ubuntu support)
They both had to rewrite the entire backend from scratch, because SwiftUI is very, very closed source. But Tokamak does have an import that just forwards to SwiftUI on Apple platforms.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T23:40:33.000Z","created_at_i":1718149233,"id":40652938,"options":[],"parent_id":40651486,"points":null,"story_id":40651054,"text":"Has nobody made a polyfill for swiftUI on other platforms yet? Or is it too tied to apple OS-level APIs? The language itself is pretty nice, last I used it. Even if some of the method (argument?) names in most SDKs are absurdly long.","title":null,"type":"comment","url":null},{"author":"wg0","children":[],"created_at":"2024-06-12T01:22:57.000Z","created_at_i":1718155377,"id":40653520,"options":[],"parent_id":40651486,"points":null,"story_id":40651054,"text":"Haven't written Swift ever but it seems very elegant language. In that spot, only go stands but go although simple but has very ugly corners such as error handling and a weird type system.
So yes for me, I might switch to Swift which seems very elegant and readable compared to some other options.","title":null,"type":"comment","url":null},{"author":"Tainnor","children":[],"created_at":"2024-06-13T08:56:47.000Z","created_at_i":1718269007,"id":40667400,"options":[],"parent_id":40651486,"points":null,"story_id":40651054,"text":"I was maintaining a server-side app written in Swift from 2018 to 2020 and we ran into tons of issues at least back then. I haven't looked into all the improvements they did since, but you might want to check.
My coworker wrote down some of the major issues we were facing: https://forums.swift.org/t/issues-learned-4-years-with-serve...
Personally, I've been soured enough that I don't ever want to write any server-side code in Swift again. It just seemed that Swift pretended to be open-source and cross-platform and then Apple would just unilaterally push some changes just because they wanted them for iOS (e.g. function builders for SwiftUI) without waiting for community feedback. It's fine to be a dictator for your PL, but not when you're claiming to have "open governance". All the while support for Linux was routinely being neglected.
I would rather recommend Kotlin. It's similar enough to Swift and it comes with the advantage of having the whole JVM ecosystem which can probably do most things you'd ever want to do on a server.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:06:29.000Z","created_at_i":1718139989,"id":40651486,"options":[],"parent_id":40651054,"points":null,"story_id":40651054,"text":"Genuine question: is there any reason to use Swift without iOS/SwiftUI? (Outside of devs who are primarily Swift developers that want to use something they already know for a small project or similar.)","title":null,"type":"comment","url":null},{"author":"autoexecbat","children":[{"author":"e63f67dd-065b","children":[{"author":"umanwizard","children":[{"author":"Cyph0n","children":[{"author":"MrDrMcCoy","children":[{"author":"kibwen","children":[{"author":"burntsushi","children":[{"author":"kibwen","children":[],"created_at":"2024-06-13T04:23:36.000Z","created_at_i":1718252616,"id":40665917,"options":[],"parent_id":40657038,"points":null,"story_id":40651054,"text":"Interesting, I must have had musl preinstalled from some other package. And I did notice that jemallocator started showing up when I compiled for musl, I figured you must have had a good reason. :P","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T11:55:04.000Z","created_at_i":1718193304,"id":40657038,"options":[],"parent_id":40653287,"points":null,"story_id":40651054,"text":"I just tried this myself and I did not have a painless experience. Hah. Without the `musl` Archlinux package installed, I get this:
--- stderr\n configure: error: in `/home/andrew/rust/ripgrep/target/x86_64-unknown-linux-musl/release/build/jemalloc-sys-b7d053053989ba56/out/build':\n configure: error: C compiler cannot create executables\n See `config.log' for more details\n thread 'main' panicked at /home/andrew/.cargo/registry/src/index.crates.io-6f17d22bba15001f/jemalloc-sys-0.5.4+5.3.0-patched/build.rs:351:9:\n command did not execute successfully: cd "/home/andrew/rust/ripgrep/target/x86_64-unknown-linux-musl/release/build/jemalloc-sys-b7d053053989ba56/out/build" && CC="musl-gcc" CFLAGS="-O3 -ffunction-sections -fdata-sections -fPIC -gdwarf-4 -fno-omit-frame-pointer -m64 -static -Wall" CPPFLAGS="-O3 -ffunction-sections -fdata-sections -fPIC -gdwarf-4 -fno-omit-frame-pointer -m64 -static -Wall" LDFLAGS="-O3 -ffunction-sections -fdata-sections -fPIC -gdwarf-4 -fno-omit-frame-pointer -m64 -static -Wall" "sh" "/home/andrew/rust/ripgrep/target/x86_64-unknown-linux-musl/release/build/jemalloc-sys-b7d053053989ba56/out/build/configure" "--disable-cxx" "--enable-doc=no" "--enable-shared=no" "--with-jemalloc-prefix=_rjem_" "--with-private-namespace=_rjem_" "--host=x86_64-unknown-linux-musl" "--build=x86_64-unknown-linux-gnu" "--prefix=/home/andrew/rust/ripgrep/target/x86_64-unknown-linux-musl/release/build/jemalloc-sys-b7d053053989ba56/out"\n expected success, got: exit status: 77\n $ which musl-gcc\n musl-gcc not found\nIf you comment out those lines and remove the `jemallocator` dependency from `Cargo.toml`, then the build succeeds.
I imagine you'll run into this same problem if you enable ripgrep's `pcre2` feature.
However, after installing the `musl` Archlinux package (which provides `musl-gcc`, among other things of course), then the above command builds just fine. Including with `jemallocator` or even with the `pcre2` feature enabled.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T00:42:11.000Z","created_at_i":1718152931,"id":40653287,"options":[],"parent_id":40653184,"points":null,"story_id":40651054,"text":"What problems did you have? As someone who's never in his life used musl before, I just now ran `rustup target add x86_64-unknown-linux-musl` and then built ripgrep with `cargo build --release --target=x86_64-unknown-linux-musl` and it worked without a problem. ldd confirms that it's statically linked. I'm surprised it was as painless as it was, I thought I'd have to install musl separately.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T00:24:33.000Z","created_at_i":1718151873,"id":40653184,"options":[],"parent_id":40653124,"points":null,"story_id":40651054,"text":"I've had a 0% success rate compiling other people's Rust apps statically. I always end up with a shared binary or a failed build, even when building with musl.","title":null,"type":"comment","url":null},{"author":"freedomben","children":[{"author":"umanwizard","children":[],"created_at":"2024-06-12T01:58:15.000Z","created_at_i":1718157495,"id":40653734,"options":[],"parent_id":40653563,"points":null,"story_id":40651054,"text":"Nothing stops you from linking against glibc statically from rust. It\u2019s recommended to link against glibc dynamically, but that\u2019s just as true for any language.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T01:29:22.000Z","created_at_i":1718155762,"id":40653563,"options":[],"parent_id":40653124,"points":null,"story_id":40651054,"text":"(not directed at parent specifically) Do you have to link againt musl? I have some C applications that I link into a static binary using the glibc-static package (in Fedora). Can the same be used with Rust?","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T00:09:08.000Z","created_at_i":1718150948,"id":40653124,"options":[],"parent_id":40651628,"points":null,"story_id":40651054,"text":"Fairly easy to build against musl thanks to rustup and cargo (except if you have native deps): https://doc.rust-lang.org/rustc/platform-support.html#tier-2...","title":null,"type":"comment","url":null},{"author":"seabrookmx","children":[],"created_at":"2024-06-12T19:09:46.000Z","created_at_i":1718219386,"id":40661776,"options":[],"parent_id":40651628,"points":null,"story_id":40651054,"text":"Same with golang! You need the CGO_ENABLED=0 flag IIRC to make static binaries on Linux.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:19:29.000Z","created_at_i":1718140769,"id":40651628,"options":[],"parent_id":40651547,"points":null,"story_id":40651054,"text":"Rust binaries (at least on Linux) are not statically linked by default. They depend on libc.","title":null,"type":"comment","url":null},{"author":"fuzztester","children":[],"created_at":"2024-06-12T01:35:36.000Z","created_at_i":1718156136,"id":40653594,"options":[],"parent_id":40651547,"points":null,"story_id":40651054,"text":">the trend of statically linked binaries that came with Rust/Go
"Trend"? Maybe "recent reverse trend" is more appropriate.
Static linking preceded dynamic linking by several years, for compiled languages, AFAIK.
https://en.m.wikipedia.org/wiki/Static_library
https://en.m.wikipedia.org/wiki/Dynamic_linker","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:11:50.000Z","created_at_i":1718140310,"id":40651547,"options":[],"parent_id":40651487,"points":null,"story_id":40651054,"text":"Yeah, I'm really glad for the trend of statically linked binaries that came with Rust/Go. No more version incompatibilities, fights with downstream packagers, weird build configs, etc, just distribute the binary and that's it.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:06:44.000Z","created_at_i":1718140004,"id":40651487,"options":[],"parent_id":40651054,"points":null,"story_id":40651054,"text":"I guess this means it can compete with golang on ease of distribution.\nPushes all the complexity away from the end user","title":null,"type":"comment","url":null},{"author":"jkelleyrtp","children":[{"author":"christophilus","children":[{"author":"coldtea","children":[{"author":"square_usual","children":[{"author":"manmal","children":[],"created_at":"2024-06-11T22:17:19.000Z","created_at_i":1718144239,"id":40652274,"options":[],"parent_id":40651720,"points":null,"story_id":40651054,"text":"As someone dealing with Swift everyday (and, before that, faster langs like Elixir and Typescript), I can only agree. Sometimes my incremental builds take 20-30 seconds and it feels like a huge toll. Waiting on the CI (which is a weak machine) is up to 25 minutes until the test suite has passed - a large chunk of that being compilation time. Releases take 5-10 minutes.
I really like Swift, but I\u2019d highly appreciate faster compilation times.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:27:11.000Z","created_at_i":1718141231,"id":40651720,"options":[],"parent_id":40651629,"points":null,"story_id":40651054,"text":"Compiling fast has ripple effects throughout your workflow. Having your iteration time go from 1s to 5s is a massive difference: it can mean you break out of the flow state when you restart your server to test your code.","title":null,"type":"comment","url":null},{"author":"iainmerrick","children":[],"created_at":"2024-06-11T23:03:07.000Z","created_at_i":1718146987,"id":40652670,"options":[],"parent_id":40651629,"points":null,"story_id":40651054,"text":"Once you use a language where compile times are essentially invisible, it\u2019s hard to go back.","title":null,"type":"comment","url":null},{"author":"plorkyeran","children":[{"author":"coldtea","children":[{"author":"plorkyeran","children":[],"created_at":"2024-06-12T02:12:45.000Z","created_at_i":1718158365,"id":40653797,"options":[],"parent_id":40653172,"points":null,"story_id":40651054,"text":"C++ with heavy template use.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T00:21:47.000Z","created_at_i":1718151707,"id":40653172,"options":[],"parent_id":40652909,"points":null,"story_id":40651054,"text":"C++ with heavy template use or C++ as glorified C-with-classes?","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T23:36:39.000Z","created_at_i":1718148999,"id":40652909,"options":[],"parent_id":40651629,"points":null,"story_id":40651054,"text":"Swift compilation is slower than C++.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:19:33.000Z","created_at_i":1718140773,"id":40651629,"options":[],"parent_id":40651582,"points":null,"story_id":40651054,"text":"Why, would you care if it's a full second or even 5 seconds?
Go hyped their compilation speed a lot in its early years, but unless it's C++ templates level slugginess it's not like it's that big of deal.","title":null,"type":"comment","url":null},{"author":"jkelleyrtp","children":[],"created_at":"2024-06-11T21:19:39.000Z","created_at_i":1718140779,"id":40651630,"options":[],"parent_id":40651582,"points":null,"story_id":40651054,"text":"Supposedly faster in Swift 6 but I don't have any big swift projects to throw at it. It uses LLVM so it's not going to be as fast as Go's.
In Swift 6 they:
- Improved parallelism via compilation pipelining (ie top-level object files are referencing not-yet-compiled symbols but can still proceed while those compile in the background)
- Parallelized and pipelined debug symbol generation (lazy debug symbols)","title":null,"type":"comment","url":null},{"author":"josephg","children":[{"author":"MBCook","children":[],"created_at":"2024-06-11T22:57:32.000Z","created_at_i":1718146652,"id":40652628,"options":[],"parent_id":40651682,"points":null,"story_id":40651054,"text":"That\u2019s the one big loss from moving off Objective-C. Because the language was so stupidly simple to parse and didn\u2019t have a lot of \u201cwe\u2019ll figure that out for you from what you wrote\u201d it could be compiled incredibly quick on today\u2019s machines.
I know they\u2019re working on improving it. I\u2019m glad they are. But that speed is something I definitely miss.","title":null,"type":"comment","url":null},{"author":"christophilus","children":[],"created_at":"2024-06-12T22:38:22.000Z","created_at_i":1718231902,"id":40663968,"options":[],"parent_id":40651682,"points":null,"story_id":40651054,"text":"Ocaml makes me wonder if we really do need the trade off. It\u2019s a fairly advanced language, and compiles super fast. I wonder why it\u2019s such an outlier among advanced languages?","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:24:20.000Z","created_at_i":1718141060,"id":40651682,"options":[],"parent_id":40651582,"points":null,"story_id":40651054,"text":"Assuming my experience with Swift 5 is still accurate, compilation speed is at least an order of magnitude slower than Go.
It\u2019s 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.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:15:53.000Z","created_at_i":1718140553,"id":40651582,"options":[],"parent_id":40651546,"points":null,"story_id":40651054,"text":"How\u2019s the compilation speed?If it\u2019s going to replace Go, that\u2019s gotta be sub second for a medium sized project on my clunky old laptop.","title":null,"type":"comment","url":null},{"author":"coldtea","children":[{"author":"Klonoar","children":[],"created_at":"2024-06-11T22:14:12.000Z","created_at_i":1718144052,"id":40652248,"options":[],"parent_id":40651604,"points":null,"story_id":40651054,"text":"This is correct.","title":null,"type":"comment","url":null},{"author":"favorited","children":[],"created_at":"2024-06-11T22:16:52.000Z","created_at_i":1718144212,"id":40652269,"options":[],"parent_id":40651604,"points":null,"story_id":40651054,"text":"Yeah, Objective-C Protocols are so old that they influenced Interfaces in Java 1.0.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:17:56.000Z","created_at_i":1718140676,"id":40651604,"options":[],"parent_id":40651546,"points":null,"story_id":40651054,"text":">Swift also took a bunch of goodies from Rust - No garbage collector - Traits via "protocol"
I'd say they took them from Apple's own Objective-C additions who had those for decades before Rust (ARC and protocols).","title":null,"type":"comment","url":null},{"author":"e63f67dd-065b","children":[{"author":"jkelleyrtp","children":[{"author":"glhaynes","children":[],"created_at":"2024-06-11T21:48:05.000Z","created_at_i":1718142485,"id":40651979,"options":[],"parent_id":40651738,"points":null,"story_id":40651054,"text":"Why do you think they wouldn't? (I don't keep up with Rust+its community closely enough to know.)","title":null,"type":"comment","url":null},{"author":"kibwen","children":[],"created_at":"2024-06-12T01:45:04.000Z","created_at_i":1718156704,"id":40653651,"options":[],"parent_id":40651738,"points":null,"story_id":40651054,"text":"But Rust has had a default testing framework since 1.0?","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:28:50.000Z","created_at_i":1718141330,"id":40651738,"options":[],"parent_id":40651609,"points":null,"story_id":40651054,"text":"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.","title":null,"type":"comment","url":null},{"author":"glhaynes","children":[],"created_at":"2024-06-11T21:33:08.000Z","created_at_i":1718141588,"id":40651792,"options":[],"parent_id":40651609,"points":null,"story_id":40651054,"text":"I'm not a (direct) user of the C++ interop, but everything I've heard about it has been quite positive. A few hopefully relevant resources, first a couple of videos:
- "Introducing a Memory-Safe Successor Language in Large C++ Code Bases" (John McCall; CppNow 2023) https://www.youtube.com/watch?v=lgivCGdmFrw
- "Swift as C++ Successor in FoundationDB" (Konrad Malawski; Strange Loop 2023)\nhttps://www.youtube.com/watch?v=ZQc9-seU-5k
And then a series of blog posts by Doug Gregor:
- "Swift for C++ Practitioners" https://www.douggregor.net/posts/
And finally:
- "Mixing Swift and C++" (Swift.org) https://www.swift.org/documentation/cxx-interop/","title":null,"type":"comment","url":null},{"author":"MBCook","children":[],"created_at":"2024-06-11T23:00:57.000Z","created_at_i":1718146857,"id":40652654,"options":[],"parent_id":40651609,"points":null,"story_id":40651054,"text":"Apple is using it for some low-level stuff and they appear to be trying to improve that every year.
I think they want to be able to use a limited subset of it in their kernel. Actually I think they already are but I\u2019m not positive.
Obviously it started as an application level language but I do think they\u2019re trying to move it down the stack as well.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:18:01.000Z","created_at_i":1718140681,"id":40651609,"options":[],"parent_id":40651546,"points":null,"story_id":40651054,"text":"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 regex support in stdlib? Async/await runtimes?
- Default testing framework is a godsend, especially when integrated into the build system
- Rust but better for everything that's not low-level systems development is the impression I get","title":null,"type":"comment","url":null},{"author":"dagmx","children":[{"author":"jclay","children":[{"author":"dagmx","children":[],"created_at":"2024-06-12T01:32:57.000Z","created_at_i":1718155977,"id":40653579,"options":[],"parent_id":40653169,"points":null,"story_id":40651054,"text":"Ah, very cool. Thanks for the link and write up","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T00:20:19.000Z","created_at_i":1718151619,"id":40653169,"options":[],"parent_id":40651658,"points":null,"story_id":40651054,"text":"There\u2019s a very minimal example using C++ interop in Qt\u2019s test suite:
https://github.com/qt/qtdeclarative/tree/dev/tests/manual/he...
I\u2019ve kicked around with the C++ interop a few times. Projects like Qt that use raw pointers extensively seem hard to expose. Ended up having to wrap Qt classes to model as a value type which was straight forward but it\u2019s not nearly as seamless as the Objective-C++ experience","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:22:10.000Z","created_at_i":1718140930,"id":40651658,"options":[],"parent_id":40651546,"points":null,"story_id":40651054,"text":"As another huge rust fan myself, Swift 6 has really won me over.
I find myself reaching for Swift as the default for a lot of things rather than Rust, especially with the advent of C++ Interoperability and the new Swift embedded stack and ownership model.
The only thing I really need is a UI story on other platforms, but it\u2019s an area Rust is lacking great solutions too. I suspect the C++ interop might eventually make Swift have great Qt bindings to compete with PySide as an accessible way to make multi platform UIs.","title":null,"type":"comment","url":null},{"author":"square_usual","children":[{"author":"jkelleyrtp","children":[{"author":"beanjuiceII","children":[{"author":"Klonoar","children":[],"created_at":"2024-06-11T22:13:49.000Z","created_at_i":1718144029,"id":40652242,"options":[],"parent_id":40651828,"points":null,"story_id":40651054,"text":"One thing that bugs me to this day is reading Swift code without an IDE can be an exercise in \u201clet me build up a mountain of context first\u201d, due to the way enums and types can get shortened.
It\u2019s nice to write but a pain to review. Meanwhile if I read Rust or Go, it\u2019s more or less what you see is what you get.
I do agree in general that it\u2019s frustrating that Rust hasn\u2019t kept up with some of Swift\u2019s pushes, but then again that\u2019s the difference when you have the richest company in the world involved.
For context, I\u2019ve written many apps in Swift, deployed a backend in Vapor, and worked with teams who use the language. I always thought I\u2019d get over it but it just never fully clicked.","title":null,"type":"comment","url":null},{"author":"msie","children":[],"created_at":"2024-06-12T18:26:31.000Z","created_at_i":1718216791,"id":40661266,"options":[],"parent_id":40651828,"points":null,"story_id":40651054,"text":"Yes! Reading Swift code, even tutorial code, can be difficult.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:35:52.000Z","created_at_i":1718141752,"id":40651828,"options":[],"parent_id":40651724,"points":null,"story_id":40651054,"text":"after using swift extensively i did not find it better of the two, in fact it is a complex keyword ridden language that seems bolted together at very many angles, each swift codebase i enter is like a new mystery to unfold because of its extremely rocky evolution","title":null,"type":"comment","url":null},{"author":"square_usual","children":[],"created_at":"2024-06-11T21:44:23.000Z","created_at_i":1718142263,"id":40651941,"options":[],"parent_id":40651724,"points":null,"story_id":40651054,"text":"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.","title":null,"type":"comment","url":null},{"author":"kbolino","children":[{"author":"illusionyodel","children":[{"author":"kbolino","children":[{"author":"developerDan","children":[{"author":"kbolino","children":[],"created_at":"2024-06-13T13:03:43.000Z","created_at_i":1718283823,"id":40669137,"options":[],"parent_id":40665891,"points":null,"story_id":40651054,"text":"This is a good point. It's possible to use Go this way too, but it gets tricky. You can lock the main goroutine to its O/S thread with runtime.LockOSThread and then do the heavy lifting on other goroutines, sending messages back to the main goroutine typically using channels. Given Swift's lineage, this is probably more ergonomic there than in Go.","title":null,"type":"comment","url":null}],"created_at":"2024-06-13T04:19:36.000Z","created_at_i":1718252376,"id":40665891,"options":[],"parent_id":40664264,"points":null,"story_id":40651054,"text":"This is just a hunch but likely because of the application the two languages were originally designed for. Go is/was a purely backend lang (as I understand it) whereas Swift was built with the UI in mind which must be run on the main thread. So Swift has async/await for making clear boundaries between synchronous (aka UI) operations and asynchronous operations.
I\u2019m am not well educated on the subject though so take that with a grain of salt.","title":null,"type":"comment","url":null},{"author":"jkrejcha","children":[{"author":"kbolino","children":[],"created_at":"2024-06-13T13:08:00.000Z","created_at_i":1718284080,"id":40669180,"options":[],"parent_id":40666357,"points":null,"story_id":40651054,"text":"Interesting. My understanding of how things get implemented is that all code runs essentially "async" by default, but the runtime scheduler can switch to running code synchronously when requested (runtime.LockOSThread) or necessary (e.g. "slow" calls to C via cgo).
I was not aware that file I/O isn't async on Linux. Even so, I'm pretty sure network I/O and channel operations (send/receive/select) are async via epoll. I'm not as sure about these, but I think time.Sleep and sync.Mutex.Lock suspend the goroutine as well.","title":null,"type":"comment","url":null}],"created_at":"2024-06-13T05:55:15.000Z","created_at_i":1718258115,"id":40666357,"options":[],"parent_id":40664264,"points":null,"story_id":40651054,"text":"This melding of the sync and the async is actually kinda interesting to me. I know that at least in lots of environments, the sync and async paths are effectively separate for things like I/O[1]. I wondered (and still do for some cases) how Go handles this.
For those curious I looked at Windows and Linux, but not much else.
Linux: no io_uring support. There's debate on even whether to use it as people are discussing security implications[2]. It looks like (from perusing this issue, but could be wrong) AIO wasn't used.
Windows: it looks like they're using IOCP everywhere. Seems sensible enough.
General case: there seems to be an open issue regarding this[3].
[1]: For example, Windows has IOCPs, Linux has io_uring, FreeBSD has kqueue, POSIX has... POSIX AIO, etc.
[2]: https://github.com/golang/go/issues/31908
[3]: https://github.com/golang/go/issues/6817","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T23:21:55.000Z","created_at_i":1718234515,"id":40664264,"options":[],"parent_id":40663865,"points":null,"story_id":40651054,"text":"But that's the thing, we're comparing with Go, where all functions behave that way, and no async/await ceremony is required. Go has many weaknesses, but I don't think a language that treats async as unusual/special beats Go in that respect.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T22:26:07.000Z","created_at_i":1718231167,"id":40663865,"options":[],"parent_id":40653603,"points":null,"story_id":40651054,"text":"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.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T01:37:03.000Z","created_at_i":1718156223,"id":40653603,"options":[],"parent_id":40651724,"points":null,"story_id":40651054,"text":"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?","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:27:19.000Z","created_at_i":1718141239,"id":40651724,"options":[],"parent_id":40651687,"points":null,"story_id":40651054,"text":"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.","title":null,"type":"comment","url":null},{"author":"arthur-st","children":[{"author":"manmal","children":[{"author":"arthur-st","children":[],"created_at":"2024-06-12T06:52:39.000Z","created_at_i":1718175159,"id":40655342,"options":[],"parent_id":40652097,"points":null,"story_id":40651054,"text":"I have, and I am indeed very hopeful about the WWDC 2024-related Swift announcements. My comment was meant to illustrate my thinking circa a year or two ago.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:59:50.000Z","created_at_i":1718143190,"id":40652097,"options":[],"parent_id":40651990,"points":null,"story_id":40651054,"text":"Have you checked out the static linking option announced yesterday? Portability has increased a lot.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:49:13.000Z","created_at_i":1718142553,"id":40651990,"options":[],"parent_id":40651687,"points":null,"story_id":40651054,"text":"I think it depends on the person. My anecdotal experience is that I'm using Go for hobby projects because with Python at my day job, I wanted a modern language with fancy-ish static typing. Additionally, I wanted it to be equally practical on Win/Mac/Linux, and to not run inside a VM.
The obvious first candidate was Rust, but the low-level features were unnecessary overhead. A "higher-level Rust" is literally Swift, but the portability is not there. The search basically ended here, so I went with Go as a consolation prize - I don't get a fancy type system to play with, but the development ergonomics, especially with the v2 modules system, are the best I've experienced yet.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:24:35.000Z","created_at_i":1718141075,"id":40651687,"options":[],"parent_id":40651546,"points":null,"story_id":40651054,"text":"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".","title":null,"type":"comment","url":null},{"author":"cube2222","children":[{"author":"jkelleyrtp","children":[{"author":"manmal","children":[],"created_at":"2024-06-11T21:53:59.000Z","created_at_i":1718142839,"id":40652032,"options":[],"parent_id":40651799,"points":null,"story_id":40651054,"text":"Yes their \u201cprivate cloud\u201d runs on Swift, which supposedly increases security because they believe Swift has things nailed by now.","title":null,"type":"comment","url":null},{"author":"Klonoar","children":[],"created_at":"2024-06-11T22:34:09.000Z","created_at_i":1718145249,"id":40652433,"options":[],"parent_id":40651799,"points":null,"story_id":40651054,"text":"I believe it\u2019s confirmed that they\u2019re doing it with Swift, buried somewhere in the ML post IIRC.","title":null,"type":"comment","url":null},{"author":"MBCook","children":[{"author":"saagarjha","children":[],"created_at":"2024-06-17T01:48:02.000Z","created_at_i":1718588882,"id":40701626,"options":[],"parent_id":40652596,"points":null,"story_id":40651054,"text":"Most server code Apple writes is Java. They are slowly trying out Swift, but it's not really correct to say that all new code is Swift.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T22:52:51.000Z","created_at_i":1718146371,"id":40652596,"options":[],"parent_id":40651799,"points":null,"story_id":40651054,"text":"Apple deploys a ton of their server stuff on Linux. Plus they appear to be doing all new code in Swift and moving old code over slowly.
They\u2019re also using embedded Swift in the Secure Enclaves and other small processors due to its safety, though I think they have an extra layer of automated security checking that they use internally that doesn\u2019t exist in the public builds.
But in short, yes. I believe they\u2019re trying to use Swift for everything at this point and getting away from C/C++/whatever even for kernel work.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:33:44.000Z","created_at_i":1718141624,"id":40651799,"options":[],"parent_id":40651759,"points":null,"story_id":40651054,"text":"I have a slight inkling that Apple internally is using Swift for backend stuff somewhere, especially with all the ML stuff they just shipped. Word on the street is their datacenters are full of M-series chips. I could see those servers running Swift + distributed actors + mlx.
The move to make swift run on Linux could be part of that work - their sysadmins, devops, and backend folks probably use Vim/VSCode and deploy on Linux.
We might see the release of a very good backend framework by apple for Swift that works on Mac/Linux.
The new macros they added kinda bolt on serde into the language too - and the distributed actor stuff is basically RPC in the language.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:30:29.000Z","created_at_i":1718141429,"id":40651759,"options":[],"parent_id":40651546,"points":null,"story_id":40651054,"text":"Agreed that Swift looks quite amazing. There\u2019s some cool talks on how they\u2019re trying to move FoundationDB to Swift and their approach.
I think the main problem, and this is a really big problem, is that based on a very shallow investigation I did a couple months back, the ecosystem for server-side stuff barely exists.
And in my opinion, the ecosystem is one of the deciding factors when picking a language.","title":null,"type":"comment","url":null},{"author":"KurtMueller","children":[{"author":"MBCook","children":[],"created_at":"2024-06-11T22:59:19.000Z","created_at_i":1718146759,"id":40652639,"options":[],"parent_id":40651829,"points":null,"story_id":40651054,"text":"I don\u2019t think they were trying to claim that, just that it was a feature that was in Rust that they liked and wanted to keep using.
Just like Rust didn\u2019t invent not using garbage collection.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:35:54.000Z","created_at_i":1718141754,"id":40651829,"options":[],"parent_id":40651546,"points":null,"story_id":40651054,"text":"Algebraic data types are not a Rust invention and aren't exclusive to that language.","title":null,"type":"comment","url":null},{"author":"mdhb","children":[{"author":"almostgotcaught","children":[],"created_at":"2024-06-11T22:04:06.000Z","created_at_i":1718143446,"id":40652138,"options":[],"parent_id":40651846,"points":null,"story_id":40651054,"text":"> - Native C, C++, Java, Rust and JavaScript interop
dart doesn't do C++ interop","title":null,"type":"comment","url":null},{"author":"manmal","children":[{"author":"mdhb","children":[{"author":"manmal","children":[],"created_at":"2024-06-12T07:56:05.000Z","created_at_i":1718178965,"id":40655644,"options":[],"parent_id":40652424,"points":null,"story_id":40651054,"text":"Great writeup, and I love that the authors looked at a lot of other languages. The solution section on how to prevent races is a bit light still - I\u2018m curious how they will solve this.
I think there will need to be exceptions to a strict race-free model eto not take away from dart\u2018s current capabilities, and without forcing people into something like a borrow checker. Swift has `@unchecked Sendable` which lets you tell the compiler "I promise I'll take care myself to keep everything in there race-free".
What I\u2018ve been missing in Swift are tools that let me add safety _within_ such @unchecked Sendables. There's the Swift Atomics lib: https://www.swift.org/blog/swift-atomics/, but its quite limited in its capabilities. So for now, I find myself reaching for tools provided by the community, like pointfree's LockIsolated: https://github.com/pointfreeco/swift-concurrency-extras/blob....","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T22:33:29.000Z","created_at_i":1718145209,"id":40652424,"options":[],"parent_id":40652218,"points":null,"story_id":40651054,"text":"For now but this is in the pipeline too.
https://github.com/dart-lang/language/blob/main/working/333%...","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T22:12:10.000Z","created_at_i":1718143930,"id":40652218,"options":[],"parent_id":40651846,"points":null,"story_id":40651054,"text":"Isn\u2019t \u201cdata-race free\u201d in Dart achieved by just not really sharing mutable memory between isolates? Probably because the web version needs to map isolates to web workers, right?","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:36:58.000Z","created_at_i":1718141818,"id":40651846,"options":[],"parent_id":40651546,"points":null,"story_id":40651054,"text":"You almost caught up to Dart.
- Built for embedded devices and already has RISC-V support
- Already has WASM was a compilation target
- Not just an LSP but amazing VSCode tooling
- Native C, C++, Java, Rust and JavaScript interop and a .NET bridge is in the works it seems.
- Typed "throws"
- Static linking (in development)
- Data-race free by default
Unique features to Swift:
- Distributed actors for concurrency that run on distant machines. (This is doable but not native to the language)
- non-copy RAII generic types (not actually sure what this is so I assume it\u2019s not in Dart)","title":null,"type":"comment","url":null},{"author":"heavyset_go","children":[{"author":"MBCook","children":[],"created_at":"2024-06-11T23:02:59.000Z","created_at_i":1718146979,"id":40652669,"options":[],"parent_id":40651960,"points":null,"story_id":40651054,"text":"Swift has painless interop with Objective-C, which is just C plus small talk.
C should already be pretty easy, though I haven\u2019t really used it myself. I only use the Objective-C stuff.
I know they\u2019ve been working on C++ but don\u2019t have any experience to comment. Someone else had a nice comment listing resources on that.","title":null,"type":"comment","url":null},{"author":"mannuch","children":[],"created_at":"2024-06-12T22:48:45.000Z","created_at_i":1718232525,"id":40664039,"options":[],"parent_id":40651960,"points":null,"story_id":40651054,"text":"Swift has had first-class C interop for a long time.
It is only C++ interop that is more experimental/in-progress.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:46:34.000Z","created_at_i":1718142394,"id":40651960,"options":[],"parent_id":40651546,"points":null,"story_id":40651054,"text":"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.","title":null,"type":"comment","url":null},{"author":"vips7L","children":[{"author":"MBCook","children":[{"author":"vips7L","children":[],"created_at":"2024-06-12T01:39:59.000Z","created_at_i":1718156399,"id":40653622,"options":[],"parent_id":40652679,"points":null,"story_id":40651054,"text":"No they're not. Reference counting is a garbage collection algorithm. Its even described as such in most literature on garbage collection.","title":null,"type":"comment","url":null},{"author":"kibwen","children":[],"created_at":"2024-06-12T01:48:21.000Z","created_at_i":1718156901,"id":40653669,"options":[],"parent_id":40652679,"points":null,"story_id":40651054,"text":"Reference counting and garbage collection are different, yes. But in terms of classifying "no garbage collection" under "things that Swift took from Rust", Swift's pervasive reference counting is much closer to classic tracing GC than it is to Rust's system of single ownership.","title":null,"type":"comment","url":null},{"author":"pcwalton","children":[],"created_at":"2024-06-12T02:10:02.000Z","created_at_i":1718158202,"id":40653787,"options":[],"parent_id":40652679,"points":null,"story_id":40651054,"text":"Automatic memory management is a synonym for garbage collection. Reference counting is a form of garbage collection.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T23:03:47.000Z","created_at_i":1718147027,"id":40652679,"options":[],"parent_id":40652336,"points":null,"story_id":40651054,"text":"Reference counting and garbage collection are different.
They\u2019re both forms automatic memory management, but they work in very different ways.","title":null,"type":"comment","url":null},{"author":"mannuch","children":[{"author":"vips7L","children":[{"author":"saagarjha","children":[{"author":"vips7L","children":[],"created_at":"2024-06-17T23:37:41.000Z","created_at_i":1718667461,"id":40712478,"options":[],"parent_id":40701645,"points":null,"story_id":40651054,"text":"Right. They spend a lot of time in pure swift and not within its C++ runtime, but when you want to compare garbage collection algorithms that doesn't really matter. The fact is that ARC is slow and you spend a ton of time counting references. Something an alternative algorithm wouldn't have to do.","title":null,"type":"comment","url":null}],"created_at":"2024-06-17T01:51:15.000Z","created_at_i":1718589075,"id":40701645,"options":[],"parent_id":40665052,"points":null,"story_id":40651054,"text":"The ixy examples were definitely nowhere near being idiomatic code.","title":null,"type":"comment","url":null}],"created_at":"2024-06-13T01:37:33.000Z","created_at_i":1718242653,"id":40665052,"options":[],"parent_id":40663996,"points":null,"story_id":40651054,"text":"> traditional (tracing) GCs require more expensive runtimes and consume much more memory
Not really no. Look at go, D, nim, or any ahead of time compiled language.
> ARC is key in providing Swift its ability to maintain its low memory footprint compared to, say, Java
Again not really. Java has other issues. Like lack of value types, conservative escape analysis, needing extra memory for profiling and the jit, and HotSpot\u2019s GCs are focused on server applications and are designed not to release memory until they\u2019re about to run out.
Even if this were true ARC trades memory for execution speed. I can\u2019t find the exact paper right now but the ixy implementations showed that you end up spending an unhealthy amount of time just counting references when you stay in pure swift code. I think it was somewhere > 30%.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T22:42:21.000Z","created_at_i":1718232141,"id":40663996,"options":[],"parent_id":40652336,"points":null,"story_id":40651054,"text":"First of all, traditional (tracing) GCs require more expensive runtimes and consume much more memory. ARCs are also much more predictable in their behavior and pave the way for greater compile time optimizations. ARC is key in providing Swift its ability to maintain its low memory footprint compared to, say, Java.
Second, yes, ARC is a GC method. But when the language says "no garbage collector", they just mean no traditional (tracing) GC runtime because, for better or worse, tracing GC is what people think of when they hear "garbage collector".","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T22:24:19.000Z","created_at_i":1718144659,"id":40652336,"options":[],"parent_id":40651546,"points":null,"story_id":40651054,"text":"> - No garbage collector
ARC is a GC, and a slower one than most traditional tracing GC's.","title":null,"type":"comment","url":null},{"author":"lll-o-lll","children":[],"created_at":"2024-06-11T22:51:18.000Z","created_at_i":1718146278,"id":40652585,"options":[],"parent_id":40651546,"points":null,"story_id":40651054,"text":"> No garbage collector
No tracing gc. Ref counting is the other kind of garbage collector.","title":null,"type":"comment","url":null},{"author":"stux","children":[],"created_at":"2024-06-11T23:25:13.000Z","created_at_i":1718148313,"id":40652827,"options":[],"parent_id":40651546,"points":null,"story_id":40651054,"text":"> Anonymous enums/structs in parameters
Can you share an example of this? It sounds really interesting but I couldn\u2019t find any references. Do you mean the parameter \u201cpacks\u201d features?","title":null,"type":"comment","url":null},{"author":"wg0","children":[{"author":"glhaynes","children":[{"author":"wg0","children":[],"created_at":"2024-06-12T09:46:21.000Z","created_at_i":1718185581,"id":40656294,"options":[],"parent_id":40654308,"points":null,"story_id":40651054,"text":"You're right. This actually is first class Apple[0] and can't get any better than that whereas with Go, I am stuck with so many third party packages. They work well but kinda... not so elegant. Decent enough given what the language can offer.
[0] https://github.com/apple/swift-openapi-generator","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T03:55:42.000Z","created_at_i":1718164542,"id":40654308,"options":[],"parent_id":40653560,"points":null,"story_id":40651054,"text":"I'm looking for a way to generate server stubs from OpenAPI specs
I don't have experience with OpenAPI, but is this what you're looking for? https://www.swift.org/blog/introducing-swift-openapi-generat...","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T01:28:18.000Z","created_at_i":1718155698,"id":40653560,"options":[],"parent_id":40651546,"points":null,"story_id":40651054,"text":"> IMO Swift 6 is a better Go and than Go, and a better Rust for app-dev type stuff, which seems to be what people want to use Rust for.
This is a great assessment. There are some shortcomings in go that I wish weren't and I'm kind surprised that people having decades of language design experience under their belt ended up designing go.
I'm looking for a way to generate server stubs from OpenAPI specs. If that, I'm all set with Vapor+OpenAPI and would retire go for my container adventures.","title":null,"type":"comment","url":null},{"author":"pcwalton","children":[],"created_at":"2024-06-12T02:08:52.000Z","created_at_i":1718158132,"id":40653782,"options":[],"parent_id":40651546,"points":null,"story_id":40651054,"text":"Swift has a garbage collector. Reference counting is a form of garbage collection.","title":null,"type":"comment","url":null},{"author":"BodkinsOdds","children":[],"created_at":"2024-06-15T17:47:30.000Z","created_at_i":1718473650,"id":40691334,"options":[],"parent_id":40651546,"points":null,"story_id":40651054,"text":"- Anonymous enums/structs in parameters/match statements
I'm not sure what you mean by this, could you elaborate?","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:11:34.000Z","created_at_i":1718140294,"id":40651546,"options":[],"parent_id":40651054,"points":null,"story_id":40651054,"text":"Swift 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 primitives to nix platforms
- Distributed actors for concurrency that run on distant machines
- Data-race free by default
- non-copy RAII generic types
Watch the video on Swift 6: https://developer.apple.com/videos/play/wwdc2024/10136/.
IMO Swift 6 is a better Go and than Go, and a better Rust for app-dev type stuff, which seems to be what people want to use Rust for.
Swift has shipped stuff that Rust has been sitting on its hands over for years:
- Anonymous enums/structs in parameters/match statements
- Named function arguments
- A type of `Send` bound that allows Rcs to be sent between threads (not Arcs)
- Swift preview hotreloading
- autoclones (without GC)
Swift also took a bunch of goodies from Rust *[1]
- No garbage collector
- Traits via "protocol"
- ADT for Option/Result
- macros
- non-copy types enforcing RAII
I really really wish Rust had been keeping up with Swift's ergonomics because it's looking like Swift is going to catch up to Rust's cross-platform story much faster. Swift really could end up as the "do it all" language for frontend/backend/app dev.
[1] By "took" I mean if you like these things in Rust you'll see them in Swift","title":null,"type":"comment","url":null},{"author":"29athrowaway","children":[{"author":"manmal","children":[{"author":"Sytten","children":[{"author":"manmal","children":[],"created_at":"2024-06-12T08:12:22.000Z","created_at_i":1718179942,"id":40655737,"options":[],"parent_id":40652346,"points":null,"story_id":40651054,"text":"I don't have a lot of experience with Rust, but that sounds about right.","title":null,"type":"comment","url":null},{"author":"msk-lywenn","children":[],"created_at":"2024-06-12T20:31:25.000Z","created_at_i":1718224285,"id":40662760,"options":[],"parent_id":40652346,"points":null,"story_id":40651054,"text":"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.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T22:25:57.000Z","created_at_i":1718144757,"id":40652346,"options":[],"parent_id":40651970,"points":null,"story_id":40651054,"text":"The way I view it as a Rust experienced programmer: Its kinda like if everything in your program was Arc<dyn Trait> 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.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:47:18.000Z","created_at_i":1718142438,"id":40651970,"options":[],"parent_id":40651898,"points":null,"story_id":40651054,"text":"The concurrency story is quite good now with Swift 6, and it\u2019s arguably easier to handle than the borrow checker, but still very safe.","title":null,"type":"comment","url":null},{"author":"singularity2001","children":[{"author":"29athrowaway","children":[{"author":"helge5","children":[],"created_at":"2024-06-12T23:32:20.000Z","created_at_i":1718235140,"id":40664325,"options":[],"parent_id":40662254,"points":null,"story_id":40651054,"text":"No, both Rust and Swift can be seen as better C++'s. And both do not provide the Smalltalk like OO Objective-C has.\nSwift (only) on Apple platforms integrate w/ ObjC, but the core language is more like C++ and very little like Smalltalk.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T19:49:42.000Z","created_at_i":1718221782,"id":40662254,"options":[],"parent_id":40652153,"points":null,"story_id":40651054,"text":"Would it be fair to say that Rust is a better C++ and Swift is a better Objective-C?","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T22:05:16.000Z","created_at_i":1718143516,"id":40652153,"options":[],"parent_id":40651898,"points":null,"story_id":40651054,"text":"Swift is elegant, beautiful and concise, whereas Rust is an ugly verbose sigil mess.","title":null,"type":"comment","url":null},{"author":"rgreekguy","children":[],"created_at":"2024-06-12T03:57:06.000Z","created_at_i":1718164626,"id":40654318,"options":[],"parent_id":40651898,"points":null,"story_id":40651054,"text":"Because it is not Rust.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:41:06.000Z","created_at_i":1718142066,"id":40651898,"options":[],"parent_id":40651054,"points":null,"story_id":40651054,"text":"Why should I use Swift instead of Rust?","title":null,"type":"comment","url":null},{"author":"anothername12","children":[{"author":"square_usual","children":[],"created_at":"2024-06-11T21:45:03.000Z","created_at_i":1718142303,"id":40651945,"options":[],"parent_id":40651926,"points":null,"story_id":40651054,"text":"Yes: https://www.swift.org/blog/adwaita-swift/","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:42:59.000Z","created_at_i":1718142179,"id":40651926,"options":[],"parent_id":40651054,"points":null,"story_id":40651054,"text":"Can I make Gtk GUI with this like you can with cocoa on macOS?","title":null,"type":"comment","url":null},{"author":"zshrc","children":[],"created_at":"2024-06-11T21:50:17.000Z","created_at_i":1718142617,"id":40651999,"options":[],"parent_id":40651054,"points":null,"story_id":40651054,"text":"Crazy that they\u2019re still offering CentOS 7 images. PLEASE DONT USE THEM","title":null,"type":"comment","url":null},{"author":"w10-1","children":[{"author":"hugodan","children":[{"author":"andrewjl","children":[],"created_at":"2024-06-12T01:27:22.000Z","created_at_i":1718155642,"id":40653553,"options":[],"parent_id":40652146,"points":null,"story_id":40651054,"text":"https://swiftwasm.org
https://github.com/swiftwasm/swift
https://github.com/swiftwasm/WasmKit","title":null,"type":"comment","url":null},{"author":"mannuch","children":[],"created_at":"2024-06-12T18:19:50.000Z","created_at_i":1718216390,"id":40661207,"options":[],"parent_id":40652146,"points":null,"story_id":40651054,"text":"https://github.com/apple/swift-for-wasm-examples?tab=readme-...","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T22:04:42.000Z","created_at_i":1718143482,"id":40652146,"options":[],"parent_id":40652091,"points":null,"story_id":40651054,"text":"Wasm? Care to provide source for that?","title":null,"type":"comment","url":null},{"author":"janice1999","children":[{"author":"favorited","children":[],"created_at":"2024-06-11T23:15:19.000Z","created_at_i":1718147719,"id":40652755,"options":[],"parent_id":40652531,"points":null,"story_id":40651054,"text":"It's relatively new. Apple put out a WWDC session video about embedded Swift today: "Go small with Embedded Swift" <https://developer.apple.com/videos/play/wwdc2024/10197/>","title":null,"type":"comment","url":null},{"author":"RantyDave","children":[],"created_at":"2024-06-12T22:46:53.000Z","created_at_i":1718232413,"id":40664028,"options":[],"parent_id":40652531,"points":null,"story_id":40651054,"text":"Swift on Zephyr! I wonder if you can attach a debugger to it? https://github.com/apple/swift-embedded-examples/tree/main/n...","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T22:45:26.000Z","created_at_i":1718145926,"id":40652531,"options":[],"parent_id":40652091,"points":null,"story_id":40651054,"text":"Wow, I had no idea people were using Swift for Embedded: https://github.com/apple/swift-embedded-examples","title":null,"type":"comment","url":null},{"author":"walterbell","children":[],"created_at":"2024-06-13T03:12:07.000Z","created_at_i":1718248327,"id":40665554,"options":[],"parent_id":40652091,"points":null,"story_id":40651054,"text":"> It would be interesting to see if this is used for the AI OS that they are inviting researchers to validate for security purposes.
That would imply either:
1. Bare-metal Linux AI OS runs on Apple Silicon. Apple could contribute Apple Silicon firmware/hardware support to Asahi and mainline Linux.
2. Virtualized Linux AI OS runs on Apple Silicon Hypervisor. Apple could contribute mainline Linux guest support for Apple Hypervisor. They could also support Linux VMs on MacOS and iPadOS which run on Apple Hypervisor, for M2+ devices with hardware support for nested virtualization.","title":null,"type":"comment","url":null},{"author":"cellularmitosis","children":[],"created_at":"2024-06-13T15:23:36.000Z","created_at_i":1718292216,"id":40670803,"options":[],"parent_id":40652091,"points":null,"story_id":40651054,"text":"Speaking of Swift on other platforms, turbolent now has Swift running on PowerPC/Darwin via his wc2c project: https://forums.swift.org/t/retrocomputing-what-would-it-take...","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T21:59:33.000Z","created_at_i":1718143173,"id":40652091,"options":[],"parent_id":40651054,"points":null,"story_id":40651054,"text":"This static SDK is just one example of Swift's new support for user-definable platforms, timed to amplify support for embedded and WASM.
Along with the move to a non-Apple GitHub organisation, it represents real progress in extending swift to other platforms.
It would be interesting to see if this is used for the AI OS that they are inviting researchers to validate for security purposes.","title":null,"type":"comment","url":null},{"author":"JackYoustra","children":[{"author":"rescripting","children":[{"author":"JackYoustra","children":[],"created_at":"2024-06-12T03:59:37.000Z","created_at_i":1718164777,"id":40654341,"options":[],"parent_id":40652676,"points":null,"story_id":40651054,"text":"Yes! See my reply above","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T23:03:28.000Z","created_at_i":1718147008,"id":40652676,"options":[],"parent_id":40652491,"points":null,"story_id":40651054,"text":"Could you elaborate?","title":null,"type":"comment","url":null},{"author":"gh123man","children":[{"author":"JackYoustra","children":[],"created_at":"2024-06-12T03:56:33.000Z","created_at_i":1718164593,"id":40654313,"options":[],"parent_id":40652767,"points":null,"story_id":40651054,"text":"Sure! I love talking about this stuff :) here's a few:
- if you want to manager your Package.swift target, you mostly have to deal with .target enum (can't figure out how to paste the URL)
You can really only do a define or unsafeFlags, which leads to a couple issues...
1) There's only Debug and Release configurations! What if you want more? What if you want a nice flow where you emit and consume pgo data and re-ingest it?
2) What if you want to use a define for another language managed by SPM, such as metal?
3) What if you want to put in a portable path into a linker argument? SPM blocks use of build-time environment variables, so you can't do that either.
All of these things seem contrived, but I ran into all three of them at my current job (shameless NanoFlick plug). All of these can be handled by cmake or xcodebuild (although probably better to use rules_xcodeproj).
- Swift compiler feedback and performance in builders is absolutely atrocious, to the point where binary searching a view to find the actual source of a type error over ~30 second build times isn't very unusual!
- It's very overly conservative with build times, and because there's only module-level import, it's very easy to accidentally have a long dependency chain which makes building one file imply building many files, further tanking your build time. There are some forum posts I can dig up on this if you're curious more on this point.
- POD structs are default-Sendable at module-level visibility, but lose that if they're public, which means if you try modularizing your app into different small packages to restore some notion of compilation units to fight against the above two points, you end up having to go around and mark all of your different classes with default protocols (usually just Sendable) to reimplement!
- Not a huge deal, but no way to have macro_rules! like you can in rust: macros are kinda hard to use and have to be in another package.
This is just my thoughts on tooling, I have many more thoughts about the language itself that I'd be happy to share.
Honestly though it's much better with vscode. I do hope that it makes progress in the right direction, Swift has a lot of things going for it!","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T23:16:52.000Z","created_at_i":1718147812,"id":40652767,"options":[],"parent_id":40652491,"points":null,"story_id":40651054,"text":"I'd love to hear some specific examples. Ive built several iOS apps and a whole backend (on linux) with Swift and other than lack of OSS library support for some SaaS APIs, it's been quite nice.
Sure Swift itself has some sharp edges, but not any more (or worse) than many other popular languages.","title":null,"type":"comment","url":null},{"author":"akdor1154","children":[{"author":"JackYoustra","children":[],"created_at":"2024-06-12T03:40:18.000Z","created_at_i":1718163618,"id":40654228,"options":[],"parent_id":40653332,"points":null,"story_id":40651054,"text":"Completely. The language philosophy is much easier than rust imo","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T00:50:36.000Z","created_at_i":1718153436,"id":40653332,"options":[],"parent_id":40652491,"points":null,"story_id":40651054,"text":"It does, but it's also a really, really nice language. I'm excited to see Apple work to file those edges down. (and i say this as someone who is a Golang and Linux fan and owns zero iThings)","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T22:41:39.000Z","created_at_i":1718145699,"id":40652491,"options":[],"parent_id":40651054,"points":null,"story_id":40651054,"text":"Swift tooling has some really! Sharp! Edges!!! If you need something quick and easier than rust or have some reason to want to take your swift code and run it elsewhere I guess this is good but I don't see why you'd use it besides that.","title":null,"type":"comment","url":null},{"author":"dzonga","children":[{"author":"azinman2","children":[{"author":"dagmx","children":[],"created_at":"2024-06-12T01:47:09.000Z","created_at_i":1718156829,"id":40653664,"options":[],"parent_id":40652724,"points":null,"story_id":40651054,"text":"Fwiw, you can use Swift in a very Python like way.
If you give a Swift file a shebang, it\u2019ll execute as a standalone script.
I still don\u2019t agree they\u2019re necessarily as overlapped as the other person claims but there is a decent area where Swift is easy enough to replace Python tooling","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T23:10:45.000Z","created_at_i":1718147445,"id":40652724,"options":[],"parent_id":40652505,"points":null,"story_id":40651054,"text":"Those are pretty different languages. One you just run as a script with no compilation and no static typing, the other is fully compiled and linked into a binary. How could they replace each other?
And what\u2019s the complexity now that even remotely approaches c++?","title":null,"type":"comment","url":null},{"author":"guestbest","children":[{"author":"dagmx","children":[],"created_at":"2024-06-12T01:47:42.000Z","created_at_i":1718156862,"id":40653667,"options":[],"parent_id":40653632,"points":null,"story_id":40651054,"text":"https://swift.org/documentation/package-manager/","title":null,"type":"comment","url":null},{"author":"newdee","children":[],"created_at":"2024-06-12T09:19:18.000Z","created_at_i":1718183958,"id":40656123,"options":[],"parent_id":40653632,"points":null,"story_id":40651054,"text":"No, this came with Swift 3 back in 2016.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T01:41:42.000Z","created_at_i":1718156502,"id":40653632,"options":[],"parent_id":40652505,"points":null,"story_id":40651054,"text":"Does swift still lack a built in package management system?","title":null,"type":"comment","url":null},{"author":"pzo","children":[],"created_at":"2024-06-12T02:28:32.000Z","created_at_i":1718159312,"id":40653876,"options":[],"parent_id":40652505,"points":null,"story_id":40651054,"text":"I think it's too late which is sad since Swift is not a bad language even though I agree it got complex since the last 5 years.
Python is mostly used not because of its language features but for cross-platform ecosystem. This is hard and slow to build especially these days (comparing to 10 years ago) since there are many languages and winner takes all or most of the cake.
The only way is
1) to provide something really groundbreaking at the time (e.g. ruby on rails)
2) piggyback on other ecosystem by providing great interop (e.g. maybe mojo in the future)
3) slowly grind and hustle until something eventually catchup (e.g. maybe rust in the future)
The problem with apple is they are too much focused to wall garden you instead of build ecosystem. Their IBM partnership failed to make something like Rails or Spring Framework for backend. Tensorflow for Swift failed even though it was google project. They don't have cross platform support in their DNA. You don't even get Xcode on Windows or iPad - this is dealbreaker for many people.
I would bet more on kotlin (native) / java even though I'm iOS dev myself. Embedded is the exception that they still might win the game since the only competition there is pretty much: C, C++, Rust and sometimes python, js more as a glue.","title":null,"type":"comment","url":null},{"author":"glhaynes","children":[{"author":"veidr","children":[],"created_at":"2024-06-12T16:29:07.000Z","created_at_i":1718209747,"id":40659950,"options":[],"parent_id":40654287,"points":null,"story_id":40651054,"text":"I'm rooting for Swift, but OMFS (S=Science btw, join my acronym club, it's free) the complexity has doubled? tripled? since I wrote the Swift SDK for my emlpoyer's API, in the Swift 3-4 era.
I think it is a lot more difficult now, because the scenario wrt the, uh FUCK, WHAT THE\u2014 CEASE ALL MOTOR FUNCT\u2014","title":null,"type":"comment","url":null},{"author":"msie","children":[],"created_at":"2024-06-12T18:20:51.000Z","created_at_i":1718216451,"id":40661218,"options":[],"parent_id":40654287,"points":null,"story_id":40651054,"text":""But you only need to learn those new parts if you're using them" - people only use a subset of C++.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T03:52:20.000Z","created_at_i":1718164340,"id":40654287,"options":[],"parent_id":40652505,"points":null,"story_id":40651054,"text":""Swift is too complex now" has seemed to have achieved meme status of late but I don't see it.
For the average developer, writing modern Swift is generally not any more difficult than it was several years ago (much more often it's easier), it's just that the language can do a lot more now. But you only need to learn those new parts if you're using them. If you're not writing low-level or special-purpose code, you don't need to learn about more recently added things like move-only types, the embedded subset, varadic generics, or macros, etc, etc. And if you are writing things that require those features, you often couldn't have even considered Swift for that purpose before they were added.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T22:42:45.000Z","created_at_i":1718145765,"id":40652505,"options":[],"parent_id":40651054,"points":null,"story_id":40651054,"text":"Swift could've easily replaced python.
but the language got complex and is now a baby C++.","title":null,"type":"comment","url":null},{"author":"1vuio0pswjnm7","children":[{"author":"cqqxo4zV46cp","children":[],"created_at":"2024-06-11T23:53:59.000Z","created_at_i":1718150039,"id":40653042,"options":[],"parent_id":40652966,"points":null,"story_id":40651054,"text":"There is, in reality, nothing unusual about that.","title":null,"type":"comment","url":null},{"author":"1vuio0pswjnm7","children":[],"created_at":"2024-06-12T02:58:29.000Z","created_at_i":1718161109,"id":40654012,"options":[],"parent_id":40652966,"points":null,"story_id":40651054,"text":"They have now fixed it after I submitted this comment. No longer sending gzip by default. Thanks for that. Someone tell Amazon they should do the same.","title":null,"type":"comment","url":null},{"author":"1vuio0pswjnm7","children":[],"created_at":"2024-06-13T03:04:23.000Z","created_at_i":1718247863,"id":40665510,"options":[],"parent_id":40652966,"points":null,"story_id":40651054,"text":"In addition to viewport-width www.amazon.com also requires a user-agent header in order to disable compression","title":null,"type":"comment","url":null},{"author":"1vuio0pswjnm7","children":[],"created_at":"2024-06-19T02:00:53.000Z","created_at_i":1718762453,"id":40724060,"options":[],"parent_id":40652966,"points":null,"story_id":40651054,"text":"Sadly another example is now www.sec.gov.
They require a value of "deflate, gzip" for Accept-Encoding.
Other sec.gov subdomains do not have this restriction.
FTC, who also uses Akamai, does not have it.
Weird.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T23:44:04.000Z","created_at_i":1718149444,"id":40652966,"options":[],"parent_id":40651054,"points":null,"story_id":40651054,"text":"This website is sending gzip _and_ ignoring the client Accept-Encoding header. Specifiying "identity" has no effect.
Ignoring the Accept-Encoding header is common but sending gzip compressed response body and _also_ ignoring the header, thereby making it impossible for the client to disable compression using Accept-Encoding: identity, is relatively rare.
Another example that comes to mind is www.amazon.com. However in that case one can disable compression by sending a Viewport-Width header.","title":null,"type":"comment","url":null},{"author":"stephen_g","children":[],"created_at":"2024-06-12T03:53:47.000Z","created_at_i":1718164427,"id":40654295,"options":[],"parent_id":40651054,"points":null,"story_id":40651054,"text":"This is awesome, and I believe opens up what I and a bunch of people were wanting which is the ability to run Swift binaries in Alpine containers! I'd seen work on musl support going in but I didn't realise it would all be going so soon. Cross compilation is very nice too to not need your runtime platform to necessarily support the whole toolchain.
I'm really glad there's finally support for vanilla Debian and from what I've seen it looks like there are initial Swift packages finally being added in the Debian testing version, which will be nice. Debian is more and more my go-to for development VMs where Ubuntu used to be, so I'm excited for official support!
With all this and embedded, I'm really excited about Swift! I've done a lot of embedded in C and I'm super keen to try out Swift on my STM dev boards!","title":null,"type":"comment","url":null},{"author":"prophesi","children":[{"author":"easeout","children":[{"author":"saagarjha","children":[],"created_at":"2024-06-17T01:42:10.000Z","created_at_i":1718588530,"id":40701597,"options":[],"parent_id":40663597,"points":null,"story_id":40651054,"text":"It's unlikely this will ever be made public. It's probably just there for organizational reasons, just like UIKit got made an umbrella framework for UIKitCore a while back.","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T21:50:36.000Z","created_at_i":1718229036,"id":40663597,"options":[],"parent_id":40662483,"points":null,"story_id":40651054,"text":"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.","title":null,"type":"comment","url":null},{"author":"lukeh","children":[{"author":"prophesi","children":[],"created_at":"2024-06-13T17:10:17.000Z","created_at_i":1718298617,"id":40672117,"options":[],"parent_id":40665097,"points":null,"story_id":40651054,"text":"Late to respond, but thank you for the in-depth response! Your research into the different options judged by your use-case is greatly appreciated.","title":null,"type":"comment","url":null}],"created_at":"2024-06-13T01:44:52.000Z","created_at_i":1718243092,"id":40665097,"options":[],"parent_id":40662483,"points":null,"story_id":40651054,"text":"There's not a consistent story but there are a bunch of options, principally divided into wrappers around existing libraries (SwiftGTK [1], Qlift [2], LVGLSwift [3]) and \nSwiftUI workalikes (Tokamak [4], SwiftCrossUI [5], AdwaitaSwit [6], there are others too).
After exploring most of these for my use case (something that needs to run on an "embedded" RPi CM4 as well as iOS), I wrote a Swift bridge/runner for Flutter [7] which is working well. That enables me to write the UI in Dart and the business logic in Swift. I looked at all the other options below (that's how I know about them, indeed [3] I wrote as part of my research), in the end I felt that none of them were at the time of investigating sufficiently mature to base a product around.
[1] https://github.com/rhx/SwiftGtk
[2] https://github.com/Longhanks/qlift
[3] https://github.com/PADL/LVGLSwift
[4] https://github.com/TokamakUI/Tokamak
[5] https://github.com/stackotter/swift-cross-ui
[6] https://github.com/AparokshaUI/adwaita-swift
[7] https://github.com/PADL/FlutterSwift","title":null,"type":"comment","url":null}],"created_at":"2024-06-12T20:09:24.000Z","created_at_i":1718222964,"id":40662483,"options":[],"parent_id":40651054,"points":null,"story_id":40651054,"text":"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.","title":null,"type":"comment","url":null},{"author":"cryptonector","children":[],"created_at":"2024-06-12T20:43:15.000Z","created_at_i":1718224995,"id":40662873,"options":[],"parent_id":40651054,"points":null,"story_id":40651054,"text":"> 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.","title":null,"type":"comment","url":null},{"author":"darthrupert","children":[{"author":"saagarjha","children":[],"created_at":"2024-06-17T01:45:09.000Z","created_at_i":1718588709,"id":40701613,"options":[],"parent_id":40666269,"points":null,"story_id":40651054,"text":"It's fine, not quite great. It does autocomplete and jump to definition, but some stuff (e.g. refactoring) isn't implemented yet.","title":null,"type":"comment","url":null}],"created_at":"2024-06-13T05:32:01.000Z","created_at_i":1718256721,"id":40666269,"options":[],"parent_id":40651054,"points":null,"story_id":40651054,"text":"How good is the LSP? In another like-Rust-but-better language (Kotlin), that part is just abysmal.","title":null,"type":"comment","url":null},{"author":"huyegn","children":[{"author":"saagarjha","children":[],"created_at":"2024-06-17T01:43:05.000Z","created_at_i":1718588585,"id":40701603,"options":[],"parent_id":40684364,"points":null,"story_id":40651054,"text":"What's wrong with
for try await line in file.lines\n\n?https://forums.swift.org/t/text-streaming-in-standard-librar...
While these things are not difficult to solve with some minor additions to the standard library and documentation that emphasizes some basic conventions, the fact that we're on Swift6 and things like this aren't just available speaks to how much further the community needs to evolve to get the language ergonomics right for non apple-y things.","title":null,"type":"comment","url":null}],"created_at":"2024-06-11T20:25:18.000Z","created_at_i":1718137518,"id":40651054,"options":[],"parent_id":null,"points":339,"story_id":40651054,"text":null,"title":"Swift Static Linux SDK","type":"story","url":"https://www.swift.org/documentation/articles/static-linux-getting-started.html"}