Container: Apple's Linux-Container Runtime (opens in new tab)

I am going to show my ineptitude by admitting this, for the life of me I couldn’t get around to implement the Mac Os native way to run linux VMs and used vm-ware fusion instead. [0]

I’m glad this more accessible package is available vs docker desktop on mac os or the aforementioned, likely to be abandoned vmware non enterprise license.

[0] [apple virtualization docs](https://developer.apple.com/documentation/virtualization/cre...)

Swift isn't quite as fast, because reference counting is inherently slower at runtime than the allocations/deallocations generated by the Rust borrow checker.

On the other hand, Swift has (IMO) a much cleaner and less symbol-heavy syntax than Rust. Easier to read and write. Less of a culture of doing crazy metaprogramming/DSL definition with macros, and the builder DSL built into the language (which SwiftUI uses) is pretty nice and generates mostly understandable compile errors.

I actually like Apple's APIs, even the legacy ones. There's some weirdness, like how some file APIs want paths and some want URIs, but it's not that bad.

Rust and Swift have done a fair bit of borrowing from each other "pun intended".

I've never got the chance to work with swift since their cross platform compatibility and "server-side swift" have been recent introductions.

In terms comparison, it really is the closest you can get to a rust that ARC BOX's everything (which has/ is planned to come down when lifetimes come in). You get a good runtime and good performance.

I can't speak to performance since I don't really race languages. But as far as feel and what not, it is very similar. But there is also a pretty good overlap in people who worked on Rust and people who worked in Swift. Graydon worked on both. So Swift has a lot of similarities with Rust. The way I usually word it is, Swift is like having C# with mostly everything you like about Rust.

I believe a lot of the legacy names come from when your interfacing with platform APIs like UIKit and such if you have to and they haven't quiet gotten a bump from their Objective-C APIs to have more swifty-APIs.

Depends on what you're doing. If you want to write systems code, Swift is very allocation-happy and will probably not be the best fit. They're trying to make an embedded Swift, but progress is pretty slow, since that's not going to be something that gets anyone promoted.

If you just want to write A Thing, then it's up to your individual taste, what's available in the ecosystem, etc.

They are different language designs sharing quite a few of the same features/philosophies.

Swift is good for business logic, like writing an app.

Rust is better for infrastructure, like writing a HTTP/3 server or Javascript VM.

Swift has an extremely good story about ABI stability, which makes sense when Apple ships a swift runtime and libraries as part of the OS, and needs the binaries to work across two dozen different major/minor releases.

Rust has up-front memory control primitives and options to remove the core library to cater to things like embedded systems development.

People have written apps in Rust, and Apple has written API backends and even device firmwares in Swift. I would argue both push against the ergonomics of the respective languages.

much of the new swift libraries/apis don't have the legacy "NS" prefixes you're thinking of

It's not a product; it's a command line tool that's (more or less) part of the OS. It doesn't need a fancy name.

You're right, it's an incredibly pyrrhic decisions that aims to wrestle the meaning of the word towards apple's implementation. I mean, the company is named "apple". This kind of raze-a-language marketing is in their DNA.

I was wondering the same thing

Apple has a track record of doing that: product names that are only unique if you keep repeating the "Apple" prefix.

Apple Card

Apple Pay

Apple Music

Apple TV

Apple Watch

App Store (trying to namesquat this is just evil, so it's "Apple App Store" for me)

Hence, I recommend you call it "Apple Container", and "Apple Containerization".

According to jzelinskie, yes: https://news.ycombinator.com/item?id=44229248

This is a layer on top of the operating system support for virtualization, which Docker Desktop (and tons of open source alternatives) already use.

I disagree, they are different, and that (containerization, not container here) is the more novel/interesting one imo. It'd be nice to focus the discussion more (though at present there are many confused comments there that think they're discussing the container tool).

well of course, the ipad is not a computer (despite what the marketing says)