If you're want to have access to everything, Objective-C++ is easier.
Where C++ reigns in Metal is being the shading language.
Metal on Windows would not help much because the GPU hardware is what's different.
A metal compatibility layer would encourage developers to start using it for games etc. Doesn't really matter if it performs a little worse - it just has to work.
Apple shipped Intel Macs with Intel/AMD GPUs until quite recently, so hardware might not matter significantly.
Even Microsoft efforts with .NET are half hearted, with the goal to sell Azure, Windows and Visual Studio licences.
Using .NET outside Windows means leaving behind several frameworks that will never be ported, a VSCode subpar experience vs VS (unless you buy Rider instead), relying on the community for GUI frameworks,...
So they get better libraries (from more dev usage) and more native software on macos.
The knock against .NET is strange. Does Google need to make a cross platform GUI framework in Go for Go to not be half-hearted?
Go did not start as a Linux only product for 15 years, and then only got ported half the ecosystem to other platforms, while keeping the key IDE, the one with experience to rule them all, Linux only.
Rather Microsoft's upper management, see the hot code reload attempt removal from dotnet watch, the new .NET plugins for VSCode with the same VS license, or the recent killing of VS4Mac.
Microsoft's management is also on the record in a couple of places, that VS Code will never have feature parity with VS, or that the best dev experience is VS/Windows.
I get a headache even thinking about projects that affect, like, three different teams within my own company. I can’t imagine the kind of migraine I’d get from trying to push a completely new standard out to multiple CPU architectures, operating systems, and GPU vendors across multiple companies.
If anything, Mantle inspired Apple.
As Long Peaks experience has shown, had not been for AMD, and Khronos would still be wondering how OpenGL vNext was supposed to look like.
This is why Apple has issues with Khronos, they didn't like what happened to OpenCL after giving it to Khronos.
I think of the timeline like this: Mantle comes out and it shows that you can deliver performance improvements with a new API that more closely reflects the hardware. Microsoft goes off and starts working on DirectX 12, to bring those benefits to DirectX. OpenGL starts working on a new version of OpenGL, to bring those benefits to OpenGL, but the progress is somewhat slower. Apple works on Metal internally, so it doesn’t have to wait for a new OpenGL and doesn’t have to deal with committees. Khronos sees that they’re being left behind, and kicks off OpenGL Next.
Rough timeline:
2013: AMD makes Mantle (no GA).
2014: OpenGL AZDO talks. Apple delivers Metal 1.0. Khronos kicks off the Vulkan project, then named OpenGL Next.
2015: OpenGL Next renamed as Vulkan. Microsoft delivers DirectX 12.
2016: Vulkan 1.0.
If the audience at Goose Con thinks your talk about Hedgehogs is great, that's not the wrong talk for Goose Con. Maybe it means "Wildlife Con" is a better name, but, maybe that talk, on that subject, at that time, was perfect and there's no wider lesson.
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.
That is how you end with COM stuff, C++ only SDKs, and .NET dev community having to implementing bindings ourselves.
It's amazing how Apple never toyed with any managed runtimes this whole time.
Being ahead of time compiled doesn't mean a language isn't managed.
Rather automatic resources management, reflection, infrastructure for dynamic loading of plugins,...
ChatGPT says: Is objective-c a managed language?...Objective-C is not typically considered a "managed language" in the sense that languages like Java or C# are."
C++ is not used for the majority of platform APIs because of all the problems, difficulties, and costs of ensuring ABI stability. C++ ABIs are notoriously fragile, which is a problem objc does not have, and swift was designed specifically to reduce ABI issues (that’s part of the reason generics are implemented as they are)
I understand your clarification but gp (jb1991) is just using a different meaning of "first class" than you and gp (bluetomcat).
For some people, a "first class language status" would also include examples such as:
- C++ would be a menu dropdown choice in Xcode project options. In Xcode's "choose options for your new project", the only language options for "Storyboard"/"XIB" are "Swift" and "Objective-C".
- C++ would be the programming language and API for Apple's VR headset ARKit. Instead, it requires Swift and SwiftUI.
- C++ language would be prominently featured as the code examples in Apple WWDC developer conferences and presentations. E.g. go to WWDC sessions page and compare Ctrl+F search hits count for "C++" vs "Swift": https://developer.apple.com/wwdc23/sessions/
Apple documentation has the sentence: "Swift is intended as a replacement for C-based languages (C, C++, and Objective-C)." -- from https://github.com/apple/swift/blob/main/docs/tools/swift.po....
Understandable that some don't include the above bullets but just pointing out that's what "1st class language" means to others. Maybe it's a sign that the term "first class" is too ambiguous and just invites disagreements.
But Xcode does not care about exactly what your project is, and those are just starting templates. Most projects I have ever worked on are combination C++ and (UI language).
To me, you're using a very weird definition of what 1st class language support is. C++ is extremely heavily used, developed, and in invested in by Apple, and Xcode has extremely good and maintained support for it. It is not the language used for UI toolkits because C++ has proven to be bad at that task. Not applying the "everything is a nail" mentality to the C++ hammer is not "not a 1st class language" it's acknowledging one of the major deficiencies in the language.
Your final 'Apple documentation has the sentence: "Swift is intended as a replacement for C-based languages (C, C++, and Objective-C)."' comment is certainly reflective of what I think some people want, but the fact that the article itself is on the topic of Apple working on interop between C++ and Swift should be a pretty good indication that C++ support is such high priority that swift is the only language working towards full interop with native C++. rust, go, etc all just say "write a C bridge", the MS story is managed C++, etc.
Maybe in the future C++ won't be first class on the platform (probably good from safety PoV for all platforms), but that's not any time in the near future.
Interesting statement, considering how there are many popular and highly influential user interface frameworks in C++.
There’s nothing false about whether you can write an app entirely in C++ or not. The only languages you can do this with are Swift and ObjC. You cannot get a window up, access platform features, interact with the frameworks with C++.
You can't use the UI toolkits, because time has shown again and again that C++ is particularly bad at UI toolkits, but also as my other longer answer said, idiomatic Cocoa and UIKit programming has significant subclassing of ui components, and even the most robustly and carefully designed C++ frameworks can't manage ABI stability well (if at all) in that case.
It is pretty standard on apple platforms to have a ton of C++ doing things C++ is good at interacting with things in ObjC and Swift, and the fact the Apple is working to improve the c++/swift interop when every other new language has the response of "who cares about C++ interop? they can just write c interposition layers until they can replace an entire subset of the library all at once" demonstrates how important and well supported C++ is on the platform.
Long term who knows. Despite the questionable equivocation about safety from Herb&Bjarne modern C++ is not safe, and new features that introduce lack of safety keep getting added while long term failings like the over reliance on UB for definable behaviour[1], and as long as that attitude remains my hopes for actually getting C++ to a place it can be used safely if it can ever be exposed to attacker control data remain low, and so the future would eventually see C and C++ being dropped everywhere. Looking forward to safe languages in the kernel: swift, rust, and the most popular safe language in the world: javascript!!!! :D
[1] C++ has "unspecified behavior" and "implementation dependent behavior" that allow for different behaviour that people claim UB is needed for, without the "compiler can pretend this doesn't happen" nonsense