Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Carbon’s most exciting feature is its calling convention

foonathan.net

Post reply on HN
Print view View original

61–70 of 223 posts

Re: Carbon’s most exciting feature is its calling convention

#61

Post by zasdffaa »

olliej wrote: post #30
Denvercoder9 wrote: post #15

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 also loathe their desire to listen to the BNF maximalists insistence on not having any “ambiguity” from

Odd that you put ambiguity in quotes. I guess it's not real ambiguity then.

Ivory tower academics, as you see them, actually care about stuff because it affects you. I've heard too many times the knee-jerk response of "it's just theory" as if that actually meant anything. Try implementing it yourself and you'd start to understand that little bits of crap typically don't add, they multiply (Edit: and I'm hurting from exactly this right now), so don't diss theory until you've (ironically) had some practice with it.

Re: Carbon’s most exciting feature is its calling convention

#62

Post by TylerGlaiel »

tialaramex wrote: post #25

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…

since C++20 you can get around this

https://en.cppreference.com/w/cpp/language/attributes/no_uni...

Re: Carbon’s most exciting feature is its calling convention

#63

Post by lioeters »

rgovostes wrote: post #10
oneplane wrote: post #2

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.

Apple's Cocoa framework itself reused the name of a 90's visual programming language for kids developed by its own Advanced Technology Group. It was certainly a play on "java for kids." https://en.wikipedia.org/wiki/Stagecast_Creator

That's the first time I heard of Cocoa as "Java for kids". How cute!

Re: Carbon’s most exciting feature is its calling convention

#64

Post by serial_dev »

labrador wrote: post #46
ISL wrote: post #44

I'm sure the ship has sailed on Carbon's naming convention, but darn if that isn't a confusing article-title. It is interesting to contemplate the most-ambiguous and least-comprehensible/googleable name one might be able to give to a piece of software. "the"? "Biden"? "Russia"? "water"? "air"? "dog"? "person"? "!"? "?"? " "?

Google engineers: "Let's make our languages hard to Google!" Google managers: "Whatever floats your boat. How about Go, Dart and Carbon?"

I've been a Dart developer for three years and had zero issues finding anything Dart related.

I also had to write some Go, that was actually pretty bad in terms of searchability.

Re: Carbon’s most exciting feature is its calling convention

#65

Post by __float »

staticassertion wrote: post #41
olliej wrote: post #33

Earlier quoted context omitted.

The binary compatibility is the big deal. The other safe languages have explicitly taken the view the interop with C++ is bad, and so we should instead do interop with the significantly less safe C instead. 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…

> The other safe languages have explicitly taken the view the interop with C++ is bad I think it's more that interop with C++ is hard and ultimately a lot less valuable than interop with C, which is what the vast majority of languages use for FFI. > 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 al…

If you consider the context of Carbon (Google having a _lot_ of C++), solving for "interop with C++ is hard" might be considered worth the price.

Whether that's true in practice...? I guess we'll need a few more years to tell.

Re: Carbon’s most exciting feature is its calling convention

#66

Post by Cyberdog »

labrador wrote: post #46
ISL wrote: post #44

I'm sure the ship has sailed on Carbon's naming convention, but darn if that isn't a confusing article-title. It is interesting to contemplate the most-ambiguous and least-comprehensible/googleable name one might be able to give to a piece of software. "the"? "Biden"? "Russia"? "water"? "air"? "dog"? "person"? "!"? "?"? " "?

Google engineers: "Let's make our languages hard to Google!" Google managers: "Whatever floats your boat. How about Go, Dart and Carbon?"

Swift was annoying in the early days since searches would bring up info on the international payment system.

Lua and PHP have nice searchability. At least, it's fairly easy to weed out results on the Portuguese moon and the Philippine peso.

Re: Carbon’s most exciting feature is its calling convention

#67

Post by axegon_ »

Dunno about the most exciting but the most irritating so far is seeing it up. Admittedly I didn't spent a lot of time trying(I didn't have all that much time today) but in the 40 minutes or so, I was unable to get it going. I'll go back to attempting tomorrow and make sense of the errors.

Re: Carbon’s most exciting feature is its calling convention

#68

Post by gumby »

tialaramex wrote: post #25

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…

> C++ also pays a price for insisting not only that objects have addresses, but those addresses are distinct.

With only three exceptions I can't think of a case where by default one would not want that. In the case you describe you would want all those objects to have unique addresses. If you wanted to have them overlap you should go to the effort to happen the way you want it to -- how could the compiler guess on its own?

The exceptions BTW are union elements, the first class/struct element, and base object addresses (in `class foo : bar ...` the when you make a foo, the address of its bar is the same as the address of the foo itself).

Re: Carbon’s most exciting feature is its calling convention

#69

Post by kllrnohj »

moralestapia wrote: post #19
Denvercoder9 wrote: post #15

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…

>Maybe I'm missing something, but I don't see what's special about Carbon here. It's nothing really out of the ordinary ... also that particular optimization is meager in practice (on the order of 1%?). I know everything improvement adds up, but the author talks about it as if it was a game changer. I like the enthusiasm, though :D.

The "ABI now or never" paper suggests somewhere on the order of 5-10%, and that's without considering the escape pessimization. Especially with the rapid expansion of smart pointer usage (and for good reason!).

Given the major selling point of C/C++ is performance, that's not an insignificant amount.

Re: Carbon’s most exciting feature is its calling convention

#70

Post by kllrnohj »

olliej wrote: post #30
Denvercoder9 wrote: post #15

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…

> which a compiler obviously sees

Not if it's in a different compilation unit, it doesn't. Or if it's just not inlining the function for some reason, then it probably also doesn't. Which is why Carbon's restriction here is so useful and practical.

Post reply on HN