31–40 of 223 posts
Earlier quoted context omitted.
Or because Carbon as an element is "C" and "C" is also the language the framework was built for.
Well, Apple was a little clever with Carbon for this reason, because it was a C based API. I'm not sure how you get Carbon from C++.
C++ also pays a price for insisting not only that objects have addresses, but those addresses are distinct. If you've got a 1.6 billion empty tuples in variable A, 1.4 billion in variable B and 1.8 billion in variable C, C++ can't see a way to do that on a 32-bit operating system. It needs to give each empty tuple an address, so it must think of 4.8 billion integers between 0 and 2^32 and it can't do that, so your pr…
I really think the most exciting feature of Carbon (indeed, it's justification for existence) is its backwards compatibility with C++, followed closely by it's more modern and flexible governance structure. Even the docs in the repo say you should avoid Carbon unless you have lots of C++ code you need to interact with.
Some of the biggest problems with C++ come from its backwards compatibility with C. Yes, it wins you users in the short term, but it's a pain to support as both languages evolve
The real killer is that the lack of any interaction with C++ means that you can’t do any real incremental adoption of one of those safe languages in any big security critical projects. Saying that the solution to C++ is to just not use it ignores the reality that C++ exists, and large projects in C++ exist. It doesn’t matter if you don’t like C++.
The final problem with the safe languages - with the exception of swift - is that they are all hell bent on not providing even just basic ABI stability. It doesn’t matter how “safe” your language is if the first thing you have to do is make a pure C (even losing potential for automatic lifetime management the C++ would allow) interface.
So I can have two libraries both written in rust, and the entire safety of it is contingent on each library talking to the other through a C API.
C++ also pays a price for insisting not only that objects have addresses, but those addresses are distinct. If you've got a 1.6 billion empty tuples in variable A, 1.4 billion in variable B and 1.8 billion in variable C, C++ can't see a way to do that on a 32-bit operating system. It needs to give each empty tuple an address, so it must think of 4.8 billion integers between 0 and 2^32 and it can't do that, so your pr…
Maybe the right question to ask is, why you have 4.8 billion empty tuples? And why you're still on a 32-bit system?
There is a lot of 32 bit microcontrollers, most notable stm32
Earlier quoted context omitted.
Microsoft. - don’t listen to me, it’s Google.
It's Google but yes, another instance of Embrace, Extend and Extinguish . I hope this doesn't take off, with my sincere apologies to the ones who have been working hard on this. The last thing the C/C++ ecosystem needs is becoming de facto owned by a private company.
Then C and C++ are defacto controlled by private companies: Google+Apple do pretty much all the clang development, MS does MSVC - if they choose not to implement a feature that’s approved, or implement one that isn’t, that is the de facto standard.
You can argue it would require all three to agree on something, but that’s still essentially making WG21 somewhat irrelevant.
Earlier quoted context omitted.
You’re certainly not the only one. It’s a confusing choice of naming.
I think the statute of limitations on “confusing name” when Mac OS Carbon was removed from OS X 10 years ago has passed.
An old Apple UI kit has an "exciting" feature?
At first I thought this was about Mac OS around the 9 and 10 times... but I suppose not everyone is going to make that link with this name.
Earlier quoted context omitted.
Maybe the right question to ask is, why you have 4.8 billion empty tuples? And why you're still on a 32-bit system?
> And why you're still on a 32-bit system There is a lot of 32 bit microcontrollers, most notable stm32
Maybe I'm missing something, but I don't see what's special about Carbon here. In C++ the compiler can also optimize pass-by-const-reference to pass-by-value, and they do. It just can't do it across an ABI boundary, but that should only be an issue with dynamic libraries, and Carbon has to follow the standard ABI there as well. Just make sure the compiler knows it doesn't have to follow the standard ABI for every sym…
I think the alias analysis “pro” is overblown, it’s UB to take the address of a parameter via any mechanism other than explicitly taking the address - which a compiler obviously sees, and because it’s UB the compiler optimizes is free to assume no one is taking the address. Then for any parameters that are passed by reference the compiler has to assume there are other references so there’s no gain. Honestly the only…
I don't get that: can you express in C++ a code that "take the address of a parameter via any mechanism other than explicitly taking the address"?