swift-nio-http2 VS swift-evolution

Apple is investing a lot in it, but Swift is much younger than Rust (especially as an open source project). There is a working group that meets every few weeks to shepherd the various projects. Most of the recent activity has been (AFAICT) about orchestration. Well, that and transitioning projects to use async/await and structured concurrency. Here's some recent activity in the Swift on server space:

- the proposal for distributed actors is currently in-review (https://github.com/apple/swift-evolution/blob/main/proposals...)

- a metrics API for backends like Graphite, Prometheus, etc. (https://github.com/apple/swift-metrics)

- HTTP/2 support for SwiftNIO (https://github.com/apple/swift-nio-http2)

- a new service discovery API (https://github.com/apple/swift-service-discovery)

- a new distributed tracing API (https://github.com/apple/swift-distributed-tracing)

- a Linux implementation of Apple's CryptoKit API on top of BoringSSL (https://github.com/apple/swift-crypto)

I'm not pretending that it's taking the server-side world by storm, but there is a fair amount of ongoing activity Personally, I'm using it for a couple personal projects and it's been solid, but I'm already a macOS developer, so it wasn't a big stretch for me to reach for it.

According to their changelog[0], Clock was added to the standard library with Swift 5.7, which shipped in 2022, at the same time as iOS 16. It looks like static linking by default was approved[1] but development stalled[2].

I expect that it's as simple as that: It's supported on iOS 16+ because it's dynamically linked by default, against a system-wide version of the standard library. You can probably try to statically link newer versions on old OS versions, or maybe ship a newer version of the standard library and dynamically link against that, but I have no idea how well those paths are supported.

0. https://github.com/apple/swift/blob/main/CHANGELOG.md

1. https://github.com/apple/swift-evolution/blob/main/proposals...

2. https://github.com/apple/swift-package-manager/pull/3905

[A Vision for Embedded Swift](https://github.com/apple/swift-evolution/blob/main/visions/e...) has the details on this new build mode and is quite interesting.

> Effectively, there will be two bottom layers of Swift, and the lower one, “non-allocating” Embedded Swift, will necessarily be a more restricted compilation mode (e.g. classes will be disallowed as they fundamentally require heap allocations) and likely to be used only in very specialized use cases. “Allocating” Embedded Swift should allow classes and other language facilities that rely on the heap (e.g. indirect enums).

Also, this seems to maybe hint at the Swift runtime eventually being reimplemented in non-allocating Embedded Swift rather than the C++ (?) that it uses now:

> The Swift runtime APIs will be provided as an implementation that’s optimized for small codesize and will be available as a static library in the toolchain for common CPU architectures. Interestingly, it’s possible to write that implementation in “non-allocating” Baremetal Swift.

I may be out of my depth here as I've only casually used Rust, but this seems similar to Swift's proposed lifetime dependencies[1]. They're not in the type system formally so maybe they're closer to poloneius work

[1]: https://github.com/apple/swift-evolution/blob/3055becc53a3c3...

Swift recently adopted a region-based approach for safe concurrency that builds on Milano et al’s ideas: https://github.com/apple/swift-evolution/blob/main/proposals...

No, it's not. Refcounting CAN be a garbage collection algorithm, but in Swift it's deterministic and done at compile time. Not to mention recently added support for non-copyable types that enforces unique ownership: https://github.com/apple/swift-evolution/blob/main/proposals...

You can stackallocate buffers with unsafe Swift but it's not exactly fun to use. https://github.com/apple/swift-evolution/blob/main/proposals/0322-temporary-buffers.md