I love how Apple has somewhat come full circle on C++. There was a time they somewhat shunned the language publicly and highly discouraged anyone from using it in apps. A lot changed a few years ago when they started dedicating WWDC sessions to new C++ language features. Really triggered my geek zone. That they are working hard to bridge these two languages is really good news and benefits everyone.
They definitely have opened some things up, like a full C++ interface to Metal. I think the idea with this current effort is kind of the opposite though - not to encourage more use of C++, but to start writing new features of C++ projects in Swift (the presenter at the C++ Now 2023 talk [1] goes into this). I expect WebKit is a big target for them, I think they eventually want to replace all their C++ with Swift gradually (instead of trying to do ground-up rewrites, where you dedicate a team to doing that for years and you have a replacement at the end with fewer features than the old project).
As an aside, I do find it funny to think about presenting “successor languages” in a con that’s meant to showcase the vitality of the current languages. Call it CppNotForever, maybe.
Since switching to Clang more than 10 years ago, Objective-C, C++ and Swift are first-class citizens in the Apple development environment. You can mix Objective-C and C++ in mm files and it's a smooth experience in general. The actual language becomes less relevant when you have the same backend.
C++ is not first class on Apple platforms. The main APIs are only in Swift or ObjC. You can use C++ in your app, but you will need an actual first-class language to interact with the OS and UI.
Interesting how they started to do the same as Microsoft did back then - use the API from every language that matters and what Microsoft wanted to matter more.
It still is shunned. The only reason to use it is for compatability with existing code. Any new code written in C++ is already deprecated and will be an attack vector.
Since a lot of people are discussing Apple’s plans to replace C/C++ in performance critical areas, I’m curious to discuss it. How do they plan to make Swift actually match those languages in speed? Last I checked, classes, along with fundamental struct types like Array and String, use atomic reference counting. Do they plan to ban all those types in these systems? Are there any highly performance sensitive and C/C++ Apple systems (not just libraries) that have been rewritten in Swift without a drop in speed? The rewrite of the Swift compiler from C++ to Swift is an example of where rewriting is occurring but where there’s a non trivial performance loss as a result.
A lot of work is going into move only types for swift to avoid the need of ARC in fundamental types like you mentioned. Classes aren’t going away but Apple is trying to evolve the language to cater to various performance needs.
I think you mean automatic reference counting (ARC) — and ARC happens at compile time as part of a static analysis pass. (The compiler is basically adding retain/release code for you.)
At runtime, it’s functionally close(ish) to malloc/free and doesn’t carry much overhead.
In my understanding, it’s both: you’re right about Automatic Reference Counting (ARC) being a compile time pass. But the reference counts that they use for said retain/release are atomic reference counted (ARC).
ARC certainly helps ARC be more performant than ARC without ARC due to the elided traffic on the count. (lol)
> The rewrite of the Swift compiler from C++ to Swift is an example of where rewriting is occurring but where there’s a non trivial performance loss as a result.
Citation needed on the performance loss. So far only a handful of SIL optimizer passes have been rewritten in Swift.
So, the buildin stdlib types afaict use arc only to figure out if the instance has a single unique reference. Internally it is a value type. If a variable on one of these types is modified then the existence of more than one reference is used to do a deep copy of the internal value type.
Also, internally the stdlib uses objc arc types nsarray nsstring etc only on Darwin platforms for zero overhead objc interop. This isn't the case on Linux and windows. For some embedded or Micro-swift variant for low level os work there could be a similar stdlib toggle for Darwin I think.
Some really smart people working on Swift, and the C++ interop is a dark art (although was missing some critical features like virtual message dispatch and support for std::function from blocks last time I looked).
FWIW there’s been plenty of C++ in macOS since the start, eg. Security.framework.
Not everyone wants to work on a distributed team. I happen to and it works for me, but I have been much happier in the past when my entire team was colocated in the same office. There is no right or wrong choice here, simply different choices made for different teams/companies. Find the one that works for you and ignore the rest.
Apple have compiler engineers who aren't at that site. Maybe they're currently only hiring for that one area, more likely it's divergence between what HR wrote down and reality.
Because that's Apple. Just like how they forces everyone to come in office three days a week. Not every company does that -- some big companies are still quite flexible with full remote work. But this is Apple.
It's confusing that folks are upset about this. If it doesn't work for you, don't work for Apple. It's like complaining about the neighbor who bakes great apple pies also happens to not let their children play video games. The children may be upset by why would you be?
Given the various claims set forth in the discussion, one thing that would be very useful would be a map of what's written in what language. From what languages are used in Apple's desptop apps, iOS, watchOS apps etc to what is used in those pesky macOS daemons. You know, the one where a new daemon decides to blow up every release and consume enormous amounts of CPU.
One thing that has always puzzled me is the low quality of a lot of Apple software. Here are some things that tend to happen over and over:
- Desktop applications that block the UI thread and present spinning ball of fail
- OS daemons that consume far more CPU than they should and often get stuck in a state where they consume lots of CPU
- Slow downloads and ultra slow "checking for update" type scenarios
It wouldn't hurt Apple to focus on quality for a couple of years. Both to rewrite a lot of software that doesn't quite perform as it should, as well as laying down some plan for long term quality enhancement.
The stuff that is written in C/C++ and possibly Objective-C today should perhaps be written in Rust. Rust is a pain in the ass to program in, but I do think it is worth it for system software just because it affects so many people when stuff fails. And I suspect a lot of Objective-C code could also be replaced with Swift.
I don't know that Rust would solve the issues you mentioned. It's great for fixing memory errors, and making it hard to make logical mistakes where you forget to handle a particular case. But it doesn't do much to stop deadlocks, quadratic algorithms, or 'scheduling' type mistakes where a thread gets into an asynchronously reptitive loop.
Three examples are powerd, bluetoothd, and more recently CalendarAgent. CalendarAgent spending 100% CPU syncing a calendar that has almost no entries is...astonishing. For powerd and bluetoothd I eventually wrote a program to keep an eye on them and terminate them if they use close to 100% CPU for more than a minute or so.
Not those exact symptoms, but Apple replaced mDNSResponder with discoveryd then gave up and went back to mDNSResponder because they couldn’t get discoveryd stable:
I agree that Apple has a lot of low-quality software.
I found that ObjC made it easy to write spaghetti code if you don't understand the motivations behind ObjC and its SmallTalk-like OO approach, and if you didn't have good rules to follow, and really think hard about the best way to do things.
I feel like too many people came into ObjC trying to just use it like Java or Python.
The dynamic-ness of it can quickly get out of control, event handling was verbose and tangled.
I feel like ObjC was missing a proper SmallTalk environment to tame it.
I think ObjC caused a lot of this bad software. Race conditions, state management bugs, logic bugs, etc.
But on the flip-side the compiled nature of it allowed things to be fast when they needed to be.
Swift Playground was a good sign of Apple drawing on its SmallTalk roots, but at the same time entirely abandoning the SmallTalk OO approach.
I find Swift a bit of a boring language. It's just a new compiled language with some fun and quirky syntax choices. There doesn't seem to be any brave new philosophy or new ideas behind it.
> I think ObjC caused a lot of this bad software. Race conditions, state management bugs, logic bugs, etc.
Apple software quality has declined significantly from the Objective-C era to the Swift era; but that actually has nothing to do with the programming language and everything to do with the forced march yearly release schedule and the lack of caring about quality by current Apple leadership.
Java was inspired by Objective-C experience at Sun, many of its features are inspired in Objective-C, and Java EE was originally a Objective-C framework, Distributed Objects Everywhere.
The first IDE vendors for Java, were doing Smalltalk.
Readit News
https://www.youtube.com/watch?v=ZQc9-seU-5k
1. https://www.youtube.com/watch?v=lgivCGdmFrw
If you're want to have access to everything, Objective-C++ is easier.
Where C++ reigns in Metal is being the shading language.
From Apple's point of view C++17 is good enough for their purposes.
Metal uses a C++14 dialect, and LLVM requires C++17 currently.
https://github.com/apple/swift-evolution/blob/main/proposals...
At runtime, it’s functionally close(ish) to malloc/free and doesn’t carry much overhead.
ARC certainly helps ARC be more performant than ARC without ARC due to the elided traffic on the count. (lol)
Citation needed on the performance loss. So far only a handful of SIL optimizer passes have been rewritten in Swift.
Also, internally the stdlib uses objc arc types nsarray nsstring etc only on Darwin platforms for zero overhead objc interop. This isn't the case on Linux and windows. For some embedded or Micro-swift variant for low level os work there could be a similar stdlib toggle for Darwin I think.
1. https://youtu.be/tzt36EGKEZo?si=N_dm8K_d852t6wY6
https://youtu.be/lgivCGdmFrw
FWIW there’s been plenty of C++ in macOS since the start, eg. Security.framework.
I never understood why the "Champagne" issue was so obviously silly to Americans.
Champagne is an actual place, that's where the name of the wine made there comes from.
Could you name something "Napa Valley wine" if it's not from Napa Valley?
One thing that has always puzzled me is the low quality of a lot of Apple software. Here are some things that tend to happen over and over:
- Desktop applications that block the UI thread and present spinning ball of fail
- OS daemons that consume far more CPU than they should and often get stuck in a state where they consume lots of CPU
- Slow downloads and ultra slow "checking for update" type scenarios
It wouldn't hurt Apple to focus on quality for a couple of years. Both to rewrite a lot of software that doesn't quite perform as it should, as well as laying down some plan for long term quality enhancement.
The stuff that is written in C/C++ and possibly Objective-C today should perhaps be written in Rust. Rust is a pain in the ass to program in, but I do think it is worth it for system software just because it affects so many people when stuff fails. And I suspect a lot of Objective-C code could also be replaced with Swift.
What are you referring to, for specific example? I haven’t had any of the symptoms you list.
https://mjtsai.com/blog/2015/05/27/mac-os-x-10-10-4-replaces...
If someone found a rust binary somewhere on a macOS install I’d be super interested.
I found that ObjC made it easy to write spaghetti code if you don't understand the motivations behind ObjC and its SmallTalk-like OO approach, and if you didn't have good rules to follow, and really think hard about the best way to do things.
I feel like too many people came into ObjC trying to just use it like Java or Python.
The dynamic-ness of it can quickly get out of control, event handling was verbose and tangled.
I feel like ObjC was missing a proper SmallTalk environment to tame it.
I think ObjC caused a lot of this bad software. Race conditions, state management bugs, logic bugs, etc.
But on the flip-side the compiled nature of it allowed things to be fast when they needed to be.
Swift Playground was a good sign of Apple drawing on its SmallTalk roots, but at the same time entirely abandoning the SmallTalk OO approach.
I find Swift a bit of a boring language. It's just a new compiled language with some fun and quirky syntax choices. There doesn't seem to be any brave new philosophy or new ideas behind it.
Apple software quality has declined significantly from the Objective-C era to the Swift era; but that actually has nothing to do with the programming language and everything to do with the forced march yearly release schedule and the lack of caring about quality by current Apple leadership.
The first IDE vendors for Java, were doing Smalltalk.
So the Java critic is kind of ironic.