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.

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.

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!

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.

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.

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.

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).

Packages get rebuilt all the time. This is fine.

As for the rest, it would be cool if binaries shipped with a manifest of some sort naming all the versions of their statically included dependencies. A SBoM of sorts. It would make this sort of vulnerability scanning much easier to do.

Go binaries have that. You can apply "go version -m" to any recent Go binary.

Also "govulncheck".

Examples:

    go version -m $(which go)
    go install golang.org/x/vuln/cmd/govulncheck@latest
    go version -m $(which govulncheck)
    govulncheck -mode=binary $(which govulncheck)
    for b in $(go env GOPATH)/bin/*; do govulncheck -mode=binary "$b"; done

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.

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.

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…

Compare to upgrading a single shared library.

They get rebuilt when a change in the package is made, not when a change in a dependency is made — which is a huge difference.

There are plenty of packages that might not get an update for a long time (month, half year, … 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 — static linking does not have the same means.

Statically linked programs don’t 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.

Debian did the strongest push for reproducible builds, and is 100% source available.

At large timescales, yes. But not at timescales relevant for rapid security updates.

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 :-)

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.

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.

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.

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.

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.

I’m happy for someone to update the version of my dependency if it has security patches. But the rest? A total nightmare. I’ll take cargo / npm / swift / etc style versioning every day.

For randomly downloaded binaries from the internet it means you will most likely keep using it with the vulnerabilities for years to come.

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.

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.

> 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.

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.

> 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.

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.

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.

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 ]

My experience. I haven't worked in a single C++ project that had hundreds of dependencies, but I encounter those regularly in Rust/npm.

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.

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.

> Say my Linux distribution distributes some Swift runtime

That runtime would need to be compatible with the Swift program. Nowadays that’s 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).

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!

Debian's build of rust packages are linked dynanically, for instance. It's a build setting, you can turn it on.

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.

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).

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

      --- stderr
      configure: error: in `/home/andrew/rust/ripgrep/target/x86_64-unknown-linux-musl/release/build/jemalloc-sys-b7d053053989ba56/out/build':
      configure: error: C compiler cannot create executables
      See `config.log' for more details
      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:
      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"
      expected success, got: exit status: 77

    $ which musl-gcc
    musl-gcc not found

If 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.

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.

And what’s the complexity now that even remotely approaches c++?

If you give a Swift file a shebang, it’ll execute as a standalone script.

I still don’t agree they’re necessarily as overlapped as the other person claims but there is a decent area where Swift is easy enough to replace Python tooling

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.

I think it is a lot more difficult now, because the scenario wrt the, uh FUCK, WHAT THE— CEASE ALL MOTOR FUNCT—

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.

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.

Think of it this way: in 5-10 years, ObjC will be the python2 of Apple development.

It's not perfect, but I hope it continues to flourish because it gets a lot right

So yes for me, I might switch to Swift which seems very elegant and readable compared to some other options.

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.

Lua is nice. But it’s chalk and cheese comparing the languages. I can’t think of many cases where you’re trying to decide between lua and Swift.

Sure, Swift has sexy features that make it appealing to developers. But the ecosystem for server infrastructure on Lua is formidable.

- 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

I'd say they took them from Apple's own Objective-C additions who had those for decades before Rust (ARC and protocols).

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’s 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.

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.

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.

They’re 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’t exist in the public builds.

But in short, yes. I believe they’re trying to use Swift for everything at this point and getting away from C/C++/whatever even for kernel work.

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.

It’s nice to write but a pain to review. Meanwhile if I read Rust or Go, it’s more or less what you see is what you get.

I do agree in general that it’s frustrating that Rust hasn’t kept up with some of Swift’s pushes, but then again that’s the difference when you have the richest company in the world involved.

For context, I’ve written many apps in Swift, deployed a backend in Vapor, and worked with teams who use the language. I always thought I’d get over it but it just never fully clicked.

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?

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.

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

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.

I’m am not well educated on the subject though so take that with a grain of salt.

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.

It’s a much more powerful language. In my opinion slower compilation is worth it for all of its great features. (Does Go even have parametric enums?). But its definitely a trade off.

I know they’re working on improving it. I’m glad they are. But that speed is something I definitely miss.

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)

I really like Swift, but I’d highly appreciate faster compilation times.

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.

- 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’s not in Dart)

I think there will need to be exceptions to a strict race-free model eto not take away from dart‘s 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‘ve 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....

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

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’m not positive.

Obviously it started as an application level language but I do think they’re trying to move it down the stack as well.

Recently went with using Kotlin Native over Swift on macOS for this reason, the C ABI export and C interop were painless.

C should already be pretty easy, though I haven’t really used it myself. I only use the Objective-C stuff.

I know they’ve been working on C++ but don’t have any experience to comment. Someone else had a nice comment listing resources on that.

Just like Rust didn’t invent not using garbage collection.

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".

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’s GCs are focused on server applications and are designed not to release memory until they’re about to run out.

Even if this were true ARC trades memory for execution speed. I can’t 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%.

Can you share an example of this? It sounds really interesting but I couldn’t find any references. Do you mean the parameter “packs” features?

Sure Swift itself has some sharp edges, but not any more (or worse) than many other popular languages.

- 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!

On the other hand, Kotlin can target native, JS, and WASM platforms as well as the JVM, which is something Java does not do (barring alternative VMs like Graal).

Also Python is getting exciting again. 3.12 can optionally remove the GIL and add a JIT.

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.