Rust seems to have failed to be a drop-in replacement for C++.
Carbon’s most exciting feature is its calling convention
121–130 of 223 posts
Re: Carbon’s most exciting feature is its calling convention
#122Earlier 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++.
Apparently, although it's not likely to occur under most conditions, you can form a monatomic carbon C²⁺ ion by shooting a laser into very high-temperature carbon:
https://sciencetrends.com/the-charge-of-a-carbon-ion/
https://aip.scitation.org/doi/10.1063/1.4966987
"Up to C⁴⁺ ions are observed."
And I guess you could also write the C²⁺ ion as "C⁺⁺" if you wanted. :-)
Re: Carbon’s most exciting feature is its calling convention
#123Rust seems to have failed to be a drop-in replacement for C++.
It has interoperability with C++, but it hasn't ever been a drop-in replacement. They have different value propositons. There's room in this world for both Carbon and Rust to succeed and interoperate.
Re: Carbon’s most exciting feature is its calling convention
#124Rust seems to have failed to be a drop-in replacement for C++.
I thought D was the drop-in replacement for C++
Re: Carbon’s most exciting feature is its calling convention
#125I searched on several sites to find out what their memory management strategy is but couldn’t figure it out. GC? ARC? Whatever Rust does? Would love to see where this fits. Exciting to see a neat new language though! Also my second favourite feature of rust and swift is Enums with associated values, I can’t see any info on this but I saw a blog mention they have it.
I think it's manual memory management, but with effort made to make that easier to handle and easier for tooling to check. With a plan to have a memory safe subset at some time in the future but not as part of the 0.1 designs.
Re: Carbon’s most exciting feature is its calling convention
#126I really thought this was gonna be about carbon atoms and molecular interactions, in some kind of geeky, programmer-friendly analogy.
Re: Carbon’s most exciting feature is its calling convention
#127I 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.
To be fair, the compatibility is a design goal, not a complete feature as such.
Even C++ struggles to be compatible with C++. I expect Carbon to have at least as hard a time with it, especially given the "bazaar" that is the C++ build and packaging ecosystem.
I also expect that Carbon will have a hard time tracking C++ as it evolves. It could freeze C++ feature development? Or it could target an old and aging C++ standard?
Point is, I'm not taking C++ compatibility as a given. It seems very hard and may require a lot of big tradeoffs.
Re: Carbon’s most exciting feature is its calling convention
#128Advantage #3 is false.
C++ already does this.
The standard explicitly states that a parameter taken by value and initialized from an prvalue of the same type may elide the move constructor (which all implementations do).
Re: Carbon’s most exciting feature is its calling convention
#129C++ 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…
In C++, the way around this is to use inheritance rather than members, since base and derived classes may obviously have the same address.
Re: Carbon’s most exciting feature is its calling convention
#130I searched on several sites to find out what their memory management strategy is but couldn’t figure it out. GC? ARC? Whatever Rust does? Would love to see where this fits. Exciting to see a neat new language though! Also my second favourite feature of rust and swift is Enums with associated values, I can’t see any info on this but I saw a blog mention they have it.
Scope-bound resource management, like C++.
GC and ARC are for people that need shared ownership, which is pretty much always a bad idea.