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

[coder]

Just the list of companies who've actively asked to be added to their vanity wall of production users would take fingers and toes to count on seven people.

https://www.rust-lang.org/production/users

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.

[coder]

I mean, there's always Donald Knuth.

What about all of those checks for $2.56 that he wrote? I'm sure there have been hundreds of them. That was probably one of the first "bug bounties" in the history of software.

[coder]

You most likely had some of them but probably never noticed them. Thats usually the case with all C/C++ projects.

Good style tends to steer clear of these pitfalls. It's only when people either don't learn good style or try to outsmart it that they get into trouble. That said, good style does become yet another thing to learn (which not everyone does).

But nothing warns you and you would have to be a perfect programmer that does not exist. And than a second programmer comes to you project ...

Static analysis has come a decent ways, in recent years. It will always have limitations, but it's far from nothing.

If you need performance you wouldn't use linked lists.

That's largely a fallacy. Linked-list nodes are often at consecutive memory addresses, if allocated in a batch. And if not allocated in a batch, then you're in for cache misses no matter what data structure you use. That said, I use std::vector<> or std::dequeue<>, when I don't need either stable iterators or efficient random-insertion/removal.

[coder]

as well as one of the most bug free complex pieces of software out there.

LOL. I've seen far too many bad formatting outcomes and spew of "Badness 10000"-type error messages to consider T_EX such a pinnacle of software design.

That said, it was a different era and he was using more primitive tools on machines that make present-day microcontrollers look powerful.

[coder]

Reference counted pointers have overhead as they need to stall execution on all CPUs for their atomic counters.

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.

Also inserting a list item is allocation free in Linux kernel.

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.

[coder]

Ah more people who are too retarded to program in c++ reinventing the wheel.

I assume most of them are C++ developers who are frustrated by how much legacy C++ has to carry around and the amount of resistance they (IMO, legitimately) get when trying to deprecate stuff.

[coder]

This focus on China polluting doesn't match reality. We must factor the imports and exports and then it's the occident that pollutes way more.

China lacks press freedom, and this extends as far as impinging on their coverage of global warming. Even when they have historic flooding, climate change is rarely mentioned as a possible factor.

And to the extent they have the awareness, popular sentiment can't directly translate into governmental action. Not to mention the issues of corruption and political patronage, but that's hardly unique to China.

The issue is consumerism and capitalism no matter if it's made in China or in Occident, the atmosphere doesn't care.

Consumer choice is often cited as a cause, because it lets companies and governments off the hook. But consumers can't build out all of the renewable energy sources, nor change the transportation infrastructure.

Getting back to China, we also shouldn't overlook their ongoing campaign of building coal-fired power plants, both domestically and around the globe. And I have to wonder how much deforestation of the Brazilian Amazon is fueled by their desire to diversify their sources of agricultural products.

That said, we in the USA have our own struggles with the fossil fuel industry and other forms of pollution. So, I'll conclude by agreeing that singling out China was both unnecessary and rather unfair.

[arQon]

I thought the Go devs made it a point to keep stop the worlds under 10ms.

That's an absolutely nonsensical statement. "Under 10ms" on *what*, exactly? A 5990X? A Raspberry Pi? A single-core 600MHz washing machine CPU? Under what sort of allocation load?

[sinepgib]

That's an absolutely nonsensical statement. "Under 10ms" on *what*, exactly? A 5990X? A Raspberry Pi? A single-core 600MHz washing machine CPU? Under what sort of allocation load?

Under whatever they're testing on, most likely some AWS instance due to the niche they cover.

[arQon]

I doubt that. C -> C++ is a vastly greater evolution than C++ -> Rust. This means one of two things: either we're converging on the "ideal" programming language (for mainstream uses), or that Rust is much more of an interim evolutionary step than anything wholly new. And for something to have staying power for the next 50 years, I think it needs to do a more comprehensive job of addressing the next 50 years' evolution in computing. I doubt Rust is up to that task, but that's just my opinion.

Rust certainly doesn't "feel" up to it, but a lot of that is for the same reasons that C "isn't" - that is, that you have to manually implement a lot of "stuff" that should ideally be part of the language, with all the guarantees and checks that come from it being so. IOW: has anyone with any nontrivial C experience, ever, NOT implemented fake OO/class support?
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.

> C++ ... could have been used in the kernel and could have been done to good effect. The reasons it wasn't weren't purely technical.

I haven't actually seen *any* technical reason claimed for it - or if I did, I've forgotten that part. IIRC it was driven entirely by the *potential* for people to do really stupid things (hello operator overloading). That's not to say there weren't some small technical differences at the time: const, for example, is still fundamentally broken in C with limitations that don't exist in C++, and that and proper locality for variables *alone* would have made adopting C++ for the kernel a massive win even if those were explicitly called out as the only C++ "extensions" permitted - but the impression I got was that the decision was based solely against the ability to write code that was not just even more illegible than bad C, but simply couldn't be trusted to actually be sane *in isolation*, i.e. unless you also had the header file open etc.
I still think it was a poor decision, but after some of the clown code I've seen over the years I can certainly sympathize with the concern.

> Also, they're only enabling Rust for use in drivers. Maybe more, in the future, but even that much hasn't landed in a shipping kernel release.

Yeah, don't remind the fanboys that this isn't the first time this exact scenario has played out. :P

I do think Rust is very likely to make it in someday, since the Rust ecosystem fully understands that if they don't hitch their wagon to a star of some kind Rust will simply be the 37th fad language to vanish into obscurity. The fact that drivers, more than almost any other code, will be highly dependent on using "unsafe" is also something that never seems to be mentioned, but I'm sure it'll all work out in the end. Even only having the trivial parts of the code be subject to some sort of additional static analysis does still have *some* value, regardless of how far it is from being the silver bullet that non-developers imagine it to be.