Comparison to Go?

Posted Jan 5, 2025 21:46 UTC (Sun) by tialaramex (subscriber, #21167)
In reply to: Comparison to Go? by khim
Parent article: Preventing data races with Pony

There's a lot here and this is rather a distraction from an article about Pony, but, briefly:

That compiler error is just because C++ insists on things being written in a specific order, just re-arrange the specialisation so that it's earlier in the source code.

Yes the C++ 0x Concepts were largely equivalent to Rust's traits, but they weren't what Bjarne wanted and so the Concepts Lite in C++ 20 is closer to Bjarne's original concept from decades earlier.

I was assuming (and perhaps you intended?) that the array was a variable declaration. You're correct that as a part of the function signature these are silently a pointer. I'd love to believe that common C compilers warn you about this if you do it, but I find that I don't even care enough to check.

I don't agree at all that these are the same ideas except in the broad sense that some ideas (e.g. the move assignment semantic) pre-date C++ attempting them and were known good ideas in PLD anyway so the fact they're in both C++ and Rust is a coincidence. That's true for Option for example, std::optional is what you might build if you were the C++ committee and you saw a Maybe type (common in many functional languages) and wanted that for C++. And you could say the same about Option and Rust, but neither directly inspired the other.

And I can't help you on Herb's position, Herb Sutter said that indeed he sang it repeatedly, on stage, it was the whole thesis of a large section of one of his "future of C++" keynotes. Take it up with Herb, not me, if you disagree about the modern C++ language, he's the convener. The other user defined types are not gifted anywhere near the power given to class.

Likewise I can't help you with the belief that somehow an attribute hack is a type, we can actually ask C++ what type is returned by a noreturn function and it'll happily tell us the type from the function signature, which is in this sense wrong. No Unique Address is a kludge for ZSTs, but the Empty type isn't a ZST you're probably thinking of the unit type. Monostate is another unit type hack, so that checks out but again, not the Empty type. Actually you're giving about the same answers as I described, remember I have heard all this before.

Comparison to Go?

Posted Jan 5, 2025 22:34 UTC (Sun) by khim (subscriber, #9252) [Link] (2 responses)

> That compiler error is just because C++ insists on things being written in a specific order, just re-arrange the specialisation so that it's earlier in the source code.

Sure, but that's not how Rust or even C macros work. There compiler really doesn't care about anything but tokens.

And “template” systems written C macros never care about things like if specialization is already defined at the instantiation time or not.

C++ does… and ironically enough Rust does, too. That's one of the reasons why Rust's specialization is still unstable and why Rust does have such elaborate orphan rules.

> I was assuming (and perhaps you intended?) that the array was a variable declaration.

Why would you assume that? I faced that issue with Vulkan marshalling. blendConstants have float blendConstants[4]; array, vkCmdSetBlendConstants have float blendConstants[4]; pointer… and yes they are described identially in the “source of truth” API definition. You couldn't understand what you are working with just from the entity definition, need to have context-dependent parsing). Very annoying.

> I'd love to believe that common C compilers warn you about this if you do it

They couldn't. There are bazillion APIs with such pointers. I wonder if all people involved even had an idea that they are actually passing pointer and not array.

> And you could say the same about Option and Rust, but neither directly inspired the other.

That's pretty bold assertion if you recall that people that do the work on rust have to know C++ and often refer to things that they find in C++ proposals. There are tons of references to various C++ proposals on IRLO with discussions about whether or not these proposals would be useful for Rust.

> Actually you're giving about the same answers as I described, remember I have heard all this before.

This explains things.

> Likewise I can't help you with the belief that somehow an attribute hack is a type, we can actually ask C++ what type is returned by a noreturn function and it'll happily tell us the type from the function signature, which is in this sense wrong. No Unique Address is a kludge for ZSTs, but the Empty type isn't a ZST you're probably thinking of the unit type. Monostate is another unit type hack, so that checks out but again, not the Empty type.

If that is what you have been saying to your C friends who have years of expertise in C but otherwise very different backgrounds then no wonder they couldn't get Rust! You may say that Rust's never type is different from function attribute, but that's like discussing the details of how you need wheels for the car but horseshoes for the horse: minutia details of implementation that inhibit the understanding. Especially if you recall that never type in today's Rust is not even a type yet! Sure, Rust developers are working on it, while C developers are happy with hack… but these are hacks, in both cases. Even if Rust version may sometime become a proper type.

For me the experience is total opposite: if you tell people about similarities between C++ and Rust instead of trying to discouraging understanding by saying that things work in Rust like in ML and not like in C++ (when all three are similar yet different) then sure, that's one way to make people confused and uncertain.

While Rust picked many ideas from ML and pile of other languages “under the hoot” it's built on top of C++ compiler and this affects many things in it very deeply.

Comparison to Go?

Posted Jan 6, 2025 16:58 UTC (Mon) by tialaramex (subscriber, #21167) [Link] (1 responses)

! is in practice a real type, you're just not yet allowed to use that name in stable Rust, I'd guess it might stabilize this year. Types you can't name aren't a big deal, both Rust and C++ have types you can't name.

You can make your own Empty user defined type easily today and that'll have a name, enum KhimDemo {} now KhimDemo is an empty type. We cannot make any value of this type, and so if our function claims to return one we know that function diverges, if some code seems to need to assign one to a variable that code never executes and so on, the compiler can prune lots of dead code as a result.

C++ has a trait predicate std::is_empty which is true for a unit type, which is a bit like when people convince themselves that the multiplicative identity and the additive identity should be the same in arithmetic, thus 1==0. And that's the exact confusion you've also demonstrated by suggesting No Unique Address and monostate are relevant here.

Comparison to Go?

Posted Jan 9, 2025 0:52 UTC (Thu) by NYKevin (subscriber, #129325) [Link]

> You can make your own Empty user defined type easily today and that'll have a name, enum KhimDemo {} now KhimDemo is an empty type. We cannot make any value of this type, and so if our function claims to return one we know that function diverges, if some code seems to need to assign one to a variable that code never executes and so on, the compiler can prune lots of dead code as a result.

The (current version of the) Rust stdlib is even kind enough to provide one of these out of the box. It's called Infallible, and is used pervasively as a substitute for ! in Result<T, !> (e.g. the blanket impl of TryFrom<T> for T currently returns Result<T, Infallible>, but when ! is stable it will be changed to Result<T, !>), hence the name "Infallible." The compiler is already smart enough to treat Infallible very similarly to ! for many (but not all) purposes. Infallible is not magic, and is literally defined as an empty enum just like your KhimDemo.

> C++ has a trait predicate std::is_empty which is true for a unit type, which is a bit like when people convince themselves that the multiplicative identity and the additive identity should be the same in arithmetic, thus 1==0.

I don't think it's quite that bad, I think this is just a case of poor terminology. C++ has no true empty types, at least in my understanding of the language. Unit and monostate are "empty" in the sense that they behave a lot like an empty struct (which is also a unit type, in languages that allow empty structs). That is not how the term "empty" is used in type theory, but calling it std::is_unit would confuse the hell out of programmers who have no knowledge of ADTs or type theory, and the abuse of terminology causes no confusion because there is no empty type to confuse it with. I'm also of the opinion that monostate was a terrible name, for exactly the same reason (but I'm not entirely sure what name they should have used instead).