Hacker News Reader

Comment by judge2020 | Hacker News Reader

judge2020

From the job posting[0]:

> We interface directly to low-level Linux kernel interfaces, using asynchronous I/O and threads to distribute workload. Following a very successful first foray into Rust we are migrating an established codebase from C to Rust, and building new functionality primarily in Rust.

However, the team specifically works on the cloud services:

> We develop and deploy software which forms the foundation for some of Apple's most important services, including iCloud, Maps, iTunes, and more.

So no rust-based software is going into MacOS or iOS quite yet.

0: https://jobs.apple.com/en-us/details/200170723/software-engi...

View on HN

So I am reading this as more like Apple is funding ( so to speak ) some work on Linux Networking using Rust? Which seems reasonable given Linux Kernel recently shared their intention to accept Rust code.

And I was thinking why did they make Swift for low level usage if they were going to use Rust.

Swift is 6 years old, Rust might have been popular among programming language connoisseurs at the time, but it wouldn't have been that silly to expect it to be a fad.

Rust hadn't hit 1.0 6 years ago and it changed a lot leading up to 1.0

Another factor here is that Chris Lattner, creator of Swift, used to work for Apple, with a high-ranking job, he was directing a whole department. He's since left Apple a few years ago. No longer having the creator of Swift championing its use at Apple opens the door to alternatives. I haven't used Rust myself, but it looks like a solid language for systems development.

I see more people and companies adopting Rust since last year after Rust 2018 version with async support.

Swift for Linux needs more ecosystem support

It needs more swift for Linux programmers.

> And I was thinking why did they make Swift for low level usage if they were going to use Rust.

Swift is great for application programming, but for low-level performance-critical systems programming it’s currently a huge pain in the rear. Swift’s philosophy is basically “give everything a Python-like level of dynamism, and then heavily inline/optimize out when statically possible.” For instance:

- Swift’s memory management is based on reference counting. It’s usually convenient and efficient (and lets you do cool things like copy-on-write), but when you know more about your object lifetimes than the compiler, the unnecessary retain/release traffic gets really annoying and is not easy to avoid.

- Swift’s generics are dynamic by default, which involves wrapping up every object into a possibly-heap-allocated container and using dynamic dispatch for everything. Usually the compiler will inline/specialize generics, but there’s no guarantee, especially when calling generics across module boundaries (due to ABI stability restrictions). Rust/C++ exclusively uses compile-time template instantiation, which is a little less flexible and doesn’t guarantee ABI stability but it always guarantees unimpaired performance. See [0] for a more detailed comparison.

- No stack-allocated arrays in Swift; all collections are reference-counted and stored on the heap.

- Still no async/await (or any real concurrency model at all) in Swift; it’s planned to be available in the next year or two. This could be a big deal for a networking team.

[0]: https://thume.ca/2019/07/14/a-tour-of-metaprogramming-models...

> - Swift’s generics are dynamic by default, which involves wrapping up every object into a possibly-heap-allocated container and using dynamic dispatch for everything.

You're right about the dynamic dispatch, but both specialized and unspecialized generics use the same memory layout. While unspecialized generics have to compute the layout dynamically if needed, there's no boxing required. If this were not the case, specialized and unspecialized code would not be able to interoperate (and as you said, this is a requirement because of ABI boundaries).

> - No stack-allocated arrays in Swift; all collections are reference-counted and stored on the heap.

There's a compiler optimization pass which stack-allocates reference counted objects with a known lifetime (which includes the backing storage for arrays). However, just as with generic specialization, this is a best-effort optimization and is not guaranteed to actually take place.

Reply on news.ycombinator.com