Hacker News new | ask | show | jobs
by zZorgz 2500 days ago
Their hinted opinion on that:

> That being said, C/C++ are the only languages with a compiler supported by both Google and Apple, so using a different language would have created a whole host of other problems to deal with.

2 comments

I'm not sure why "supported by both Google and Apple" is supposed to matter. Apple doesn't need to ship a Rust compiler for me to use Rust.
1st tier tooling supported by the platform won't break yearly on every new OS version and you don't have to wait until your 2nd tier tooling developers gets around to fixing it.

The platform developers will do their best to keep 1st tier tooling working and fix it when it breaks.

Last I checked the Rust compiler doesn't output bitcode in the format Apple requires. So no Watch/TV apps.
Likely too much friction. Native environments benefit from using the expected IDE and tooling integration to build UI apps on respective platform. C or C++ is the best common supported language, and they didn't even like that.

Also the UI frameworks are being written in said preferred language these days, eg SwiftUI, and adding one additional language could be perceived as a pain.

Apple ships a C++ compiler but you can't use C++ with Apple's platform SDKs. IF you want to use C++ you need to write Obj-C++ glue code to access most of the system frameworks, including UI code.
I would look at it differently, i.e, obj-c++ is a valid supported language environment, that makes interopt with C++ pleasant at least compared to other interopt choices. Developers may choose to target Obj-C++ even out of preference.
Metal and driver SDKs require C++.
Metal is Obj-C.
Then try to write Metal shaders in Objective-C.
Is that still true? If Rust is built on clang it should not be that hard to port. Go also runs on both AFAIK.
Runs on a platform is very different from "officially supported"