FizzyOrange

... in one benchmark.

It does still have a traditional assignment operator. You can assign values to mutable variables.

Also I would say let-binds are still pretty much assignment; they just support destructuring. Plenty of languages support that to some extent (JavaScript for example) and you wouldn't say they don't have assignment.

I don't think it affects the ability to overload = anyway. I think there aren't any situations in Rust where it would be ambiguous which one you meant. Certainly none of the examples you gave compile with both = and ==. Maybe there's some obscure case we haven't thought of.

>= and <= match the mathematical operators. The question you want to ask is why doesn't it use = for equality, and the answer is that = is already used for assignment (inherited from C among other languages).

In theory a language could use = for assignment and equality but it might be a bit confusing and error prone. Maybe not though. Someone try it and report back.

Yes, but I was talking about Linux in general. I'm pretty sure Gnome at least has commercial backing.

And Linux advocate never say "don't use Linux; it isn't a commercial product so it isn't as good as Windows" do they? They say "you're an idiot for using Windows; Linux is better".

No that's a subtly different thing. The storage is a contiguous vector, but because it is a ring buffer there must be one pair of adjacent elements that are not contiguous in memory. That's what that comment is saying.

But because it is only one discontinuity it doesn't affect algorithmic complexity, so it is still O(1) to access elements, unlike a linked list which is O(N).

If you google "circular buffer" there will be loads of diagrams that make it really obvious how it works.

Standard ring buffers or circular buffers are implemented as continuous vectors, with a read and write pointer.

Rust's VecDeque is a ring buffer: https://doc.rust-lang.org/std/collections/struct.VecDeque.html

Zero surprises. It's the same as in any other language.

I think once things get established the people in charge see any attempt to change it as some kind of personal insult, so they just go into defence mode. You see the same thing e.g. with Python - for literally decades they've denied that performance matters and it's really only recently that that has changed.

I think it will only get worse for C++ because the people who understand this stuff have mostly given up on C++.

Yeah I mean it's definitely a reference volume of last resort, rather than a tutorial you would read cover to cover. Clearly a genius but he explains things as if you already understand them, and can also read his mind.

That said, for a lot of the content the only alternative is research papers and they are even less accessible. I definitely would only use it if I couldn't find answers anywhere else though.

This is about Spectre, not about buggy hardware implementations.

Spectre is a fundamental flaw in speculative execution that means it can leak information, so it's a security vulnerability. Apparently Intel has been imposing draconian requirements on software to work around the issue rather than fixing it in hardware, which is obviously what they should do, but is not at all trivial.

Unless the binary size difference is insane, who would say "oh well we were going to pick the library that wasn't riddled with security issues but we decided to save 2MB instead, hope that makes you feel better about your $12m cybersecurity fine!".