Even languages without a heritage, which are invented within two generations have complex features comparable to established languages. There are many good examples in Steven Pinker's "The Language Instinct."
Similar to the Sapir-Whorf hypothesis I think "broken mindsets," and "poison," are exaggerations with little basis.
tl;dr It's really not that depressing. There are different ways of doing the same thing.
UNIX had a few nice ideas, but so did other OS, there is hardly a reason to have it in a pedestal.
Of all the things about Apple that could be changed, I'd say the underlying technology of their OS is the least interesting.
Database based filesystem.
The way multi-core programming was present across whole OS.
The other two are more substantial, but still seem pretty unimportant things to ask from Apple in an alternate reality. I'd say the problems with Apple are mostly non-technical.
Which part? IOKit, for writing kernel drivers for Darwin's xnu kernel is C++.
Cocoa is mostly Objective-C and not plain C. What would C++ improve there?
So… which other part would redoing in C++ improve? The kernel filesystem layer? The internal kernel exec implementation?
I'm not seeing what C++ brings to the table in any of these cases.
Maybe the POSIX layer itelf? That could be new and interesting, but the C++ ABI isn't really compatible with much beyond C++ itself. The beauty of the C ABI is that pretty much everything implements it, some languages with direct C FFI APIs.
Now a kernel written Rust… that's something I'd like to see. But then again, what would the userspace interface layer for such a kernel look like? POSIX?
Everything.
> I'm not seeing what C++ brings to the table in any of these cases.
Making C move out of the scene and moving into safer languages for systems programming. Even though C++ also has its issues, but at least it is way safer than C.
There are C++ OS like Symbian, OS/400, Genode and also Windows is moving into that direction.
However having a desktop OS to point out to as example, would be nice to the C++ community.
> The beauty of the C ABI is that pretty much everything implements it, some languages with direct C FFI APIs.
This is a consequence of C ABI being the OS ABI.
Outside the UNIX world there are a few OS were this wasn't true.
> Now a kernel written Rust… that's something I'd like to see. But then again, what would the userspace interface layer for such a kernel look like? POSIX?
Me too. POSIX is tied to C, the API should be something modern.
I guess I don't see as being "way" safer than C. I see it as being marginally safer [1], but with an arbitrary and rigid object model.
> > The beauty of the C ABI is that pretty much everything implements it, some languages with direct C FFI APIs.
> This is a consequence of C ABI being the OS ABI.
Perhaps. But a non-OO interface layer makes a lot of sense anyway (or at least OO agnostic ones).
The problem with making your main OS interface be C++ is that now every other language has to contort its object model to match the C++ one. How do you write Go code that interfaces with the C++ OS objects? C++ and Go are remarkably different. Ruby and C++ are different, as is Perl, Obj-C, Python, and Java. Either you have to use barely anything from C++ (really light inheritance, no STL, no RIAA, etc.) or you have to have extremely severe wrappers for every non-C++ language. The former means you give up on a lot of the safety that C++ gives you and the latter means that every language binding is 100% different. Neither of those is a good option.
An idiomatic C++ OS interface sounds good on the surface, but I think it's really only a good idea if you want all the user code to be written in C++, too.
[1] Everything you can do wrong in C you can also do in C++: Good old "((void(*)())0)();" compiles in both.
Agree. But at least C++, the language, gives you the tools to write safer code, when you stick to what STL offers or similar libraries.
With C, only third party tools that aren't available everywhere.
Not to mention that back in 80's, C already felt primitive and its success is only a consequence of UNIX spreading into the enterprise out of research labs.
The best would be to have both gone. But until that doesn't happen C++ is way better than C.
> Perhaps. But a non-OO interface layer makes a lot of sense anyway (or at least OO agnostic ones).
C++ usage does not imply OO. The language has a lot more to offer.
> The problem with making your main OS interface be C++ is that now every other language has to contort its object model to match the C++ one.
I fail to see how this is different from OS where C isn't the OS ABI, like the mainframes, almost all of the 80-90's home market OS, for example.
Languages have to use the OS ABI. The fact that in most OS C ABI == OS ABI is a side effect of writing the OS in C.
It's everything I could ever dream~ vomits uncontrollably
All monocultures are bad.
What happened is that now young developer generations think that UNIX and Windows are the only OS in town and disregard all the other ones out there being used.
As such they only focus their efforts into UNIX way, instead of trying to come up with new ideas.
For example, how to move away from C for systems programming, when C is married with UNIX? This is just one example.
Things are changing in the Linux world. Just not in a particularly positive direction.
Moral of the story: Linguistic relativity (Sapir-Whorf hypothesis) is real. It doesn't apply just to human languages, but technology as well. People with broken mindsets will carry over their baggage with them and poison even already mediocre environments.
More depressing though, is the anti-BSD sentiment present amongst many Linux users. Mostly because of how ironic it is.