Google Engineers Lift The Lid On Carbon - A Hopeful Successor To C++

[sinepgib]

If you're going to use inheritance, then my contention is that MI can be used to produce flatter hierarchies (I rarely have more than 2-deep) and thus reduces cognitive load in that way. I think MI gets bad press, due to worst-case scenarios that some people dream up & the general sense that it sounds more complicated.

Depends. The nice thing about C++ is that if inheritance is really what you want, C++ does it in a declarative way that you can clearly see up-front. In C, function pointer members can be set and overwritten at any point. So, it imposes a requirement that the software project have a regular mechanism & convention for initializing & overwriting them to avoid any confusion.

As I mentioned, the other use for function pointer members is to model state machines. In C++, if you see pointer-to-member variables or std::function<> members, either it's a simple form of dependency-injection or someone is using them to model a state machine. In C, there's the added uncertainty of whether it's really just modeling inheritance.

For mix-ins and interfaces, you typically won't have name-collisions between the methods of your different base classes, which is why I think it's mostly a non-issue.

Yes, all very good points. I just want to clarify one thing: I'm not defending C OOP patterns over C++ in general, but only pointing out that the "issues" with multiple inheritance that one could think of in C++ aren't there. Of course, you have a different set of issues and (IMO, and apparently yours as well) C++ is vastly superior to C in its implementation of OOP in general.

Well, I think there'd be a very high degree of overlap, like at least 80%. You might start with something like C++ Core Guidelines and then have your own kernel-specific rules that take precedence whenever there's a contradiction.

Yeah, and certainly things like smart pointers would probably translate 1:1, same for RAII, which are the most important improvement over C in terms of safety.

And yes, STL is obviously not suitable for in-kernel use. However, the kernel has plenty of algorithms and datastructures, some of which could be templated. A big advantage people overlook about C++ is that STL gives you higher-quality algorithms and datastructures than most C programmers would bother to implement. Likewise, I wouldn't be surprised to learn that parts of the kernel still use more primitive algorithms and data structures, which means there's room for improvement if they'd transition to a language which supports high-quality generic implementations.

Yes, that's precisely what I loved from C++ when I learned it. C gives you essentially nothing out of the box, and its lack of any kind of serious generics makes decent data structures particularly hard to implement and use. Now, specifically for the kernel, I wouldn't be surprised if drivers didn't make use proper use of its facilities, but a lot of work goes into optimizing its data structures. That said, a nice wrapper around templates would be a huge deal in terms of usability.

[phuclv]

Rust has a lot of buzz in the internet. But in real life I visit a job board and see the following numbers:
c++ - 138
python - 182
java - 235
c# - 199
golang - 52
rust - 5

Who in sane mind wants to get 5 job proposals instead of hundreds? So almost none will invest time into learning Rust. The same goes from the company perspective: do you want your product to get locked with a not widespread technology and hard to find developers?

fewer positions means higher salary, less competency and higher chance of passing the interview. Don't you see COBOL or PHP positions that have very high proposed salary due to the lack of programmers in those languages

[ssokolow]

If you have to argue about the size of vanity walls, then it seems to me you've given up on the technical arguments.

IMO, there are some arguments not worth having. Vanity walls is one of them. People who raise this point are not likely to be won over by anything you say.

I was replying to someone who claimed you could count the number of companies using Rust in production on your fingers. It was a perfectly valid counter to where they took things.

[ssokolow]

MI is something that in reality almost never solves more problems than it creates, and a language that doesn't have it is not in any way inherently unsuitable for general purpose, but "simple" inheritance DOES map to an absolutely enormous set of real-world problems, and Rust's workaround for not supporting that is as clumsy as "switch(p->type) {" is.

However, it won't necessarily stay that way. The Rust developers' rationale for not providing some form of implementation delegation is "We're still waiting to see which of multiple mutually incompatible ways to provide it, each with their own trade-offs, before we promise to give it language-blessed support in perpetuity."

It's a completely forward-compatible decision.

[coder]

I was replying to someone who claimed you could count the number of companies using Rust in production on your fingers. It was a perfectly valid counter to where they took things.

Sure, but I think the chance you were able to change their mind/position with that counter is very low. It's too easy to write off such vanity walls, because the standard for getting on it is probably nonexistent. I bet you just need one person toying with it, in the bowels of XYZ MegaCorp and it gets added to the wall the same as if Rust were central to their business strategy.

In contrast, membership lists do mean something, in the case of standards bodies where members must pay dues and/or contribute their employees' time.

[ssokolow]

Sure, but I think the chance you were able to change their mind/position with that counter is very low. It's too easy to write off such vanity walls, because the standard for getting on it is probably nonexistent. I bet you just need one person toying with it, in the bowels of XYZ MegaCorp and it gets added to the wall the same as if Rust were central to their business strategy.

In contrast, membership lists do mean something, in the case of standards bodies where members must pay dues and/or contribute their employees' time.

It's a little different than that, since Rust's vanity wall:

1. Is something you have to ask to be added to (at least, last I checked)
2. Has an explanation of what they're using it for on each entry.

...but you make a good point, so I'll point at the membership wall for the Rust Foundation. You can't count that on your fingers either.

[Sergey Podobry]

fewer positions means higher salary, less competency and higher chance of passing the interview. Don't you see COBOL or PHP positions that have very high proposed salary due to the lack of programmers in those languages

Wrong. Salary depends on demand and proposition in the market.

[arQon]

what? you can set and satisfy a time constraints regardless of the system you're running on.

That comment is so hopelessly wrong that it took me several minutes to even understand what (I *think*) you were actually trying to say, but even if so it's still wrong, just in a more normal way.
It doesn't help that you changed the context from what I was actually replying to, so maybe reading the post would have helped.

> Of course there might be extreme load situation where it is not sufficient, but your question is wrong anyway.

Two quick points: first, you mean you don't have the experience to understand the question; and second, it was rather obviously rhetorical.

Yes, "load" - not "extreme load" or other attempts to hedge - is one of the reasons why "10ms" obviously isn't, and can't be, guaranteed, or even close to it.

Anyway: I'm going to interpret your statement as attempting to say that what you think is that "When Go runs GC, it tries to do so in slices of not more than 10ms", right? If so, there may be some point in continuing with this. If that wasn't it then lets get out of here before wasting any more time on this.

[arQon]

Wrong. Salary depends on demand and proposition in the market.

Propositioning the market will likely get you either called in to HR or arrested.

Can you maybe try a different word? Or describe the meaning you're going for it not.

[Sergey Podobry]

No, they don't. Hardware atomics only need to ensure exclusivity in the cache hierarchy of the core that's using them. Perhaps you're confusing atomics' typical case with that of split locks?

https://lwn.net/Articles/790464/

Those perform so badly that many consider them to be a software bug, if they occur.


I don't see how this can always hold. Or, do you mean that it's merely possible to sometimes do an allocation-free insertion? More information needed.

At first atomics work as a memory barrier so they stop execution of the current core to flush the store buffer. Then they lock the cache line or the whole CPU bus (depending on the architecture and address alignment) and signal CPUs on other sockets. If any other core tries to access the memory address on which an atomic operation is performed (or any address in case of the CPU bus lock) it will stall its execution. Atomics are 10-300 times slower than non-atomics plus affects other CPU cores.

The trick with allocation-free list insertion is to store list pointers along with the data that will be stored in the list. So you need to allocate the data and then you can insert/remove it from the list without additional allocations.