Google is an enormous company which operates flatter than you’d expect for an organization of its size. It’s entirely possible that someone from Google was involved in organizing this (i.e. booking the venue) without having buy-in from leadership. Once leadership became aware after being asked about it, they may have shut the whole thing down because they knew the optics would be bad.
Speaking as an annoying Rust user, you’re being bigoted. I’m annoying, but the vast majority of Rust users are normal people who you wouldn’t even know are using Rust.
Don’t lump all the others in with me, they don’t deserve that.
How exactly is an individual supposed to determine which cops will be good and which will abuse their power?
Just as we can’t make a general statement that all cops are definitely bad, you can’t make a general statement that all cops in any particular country or town will be good.
From a basic risk management viewpoint, it doesn’t make sense for anyone to accept the risk that any given cop won’t abuse their position, even if we were willing to accept that very few would actually do so.
Cops have an extremely privileged status in society and the amount of damage that a bad one can do to an individual - on purpose or even by accident - is incalculable, including setting up an innocent person for capital punishment as we’re seeing unfold in Missouri right now.
You’d be amazed at how resistant most people are to anything that feels unfamiliar, even if it’s good for them. Coal and oil jobs are familiar, green jobs are not.
It should be as simple as you’re suggesting, but sadly it isn’t.
Best practice when using .unwrap() in production code is to put a line of documentation immediately above the use of .unwrap() that describes the safety invariants which allow the unwrap to be safe.
Since code churn could eventually cause those safety invariants to be violated, I think it’s not a bad thing for a blunt audit of .unwrap() to bring your attention to those cases and prompt to reevaluate if the invariants are still satisfied.
But only if pattern matching were included, otherwise they would be as unpleasant as C++'s std::variant.
This makes a lot of sense, but the functions were Rust bindings for plain C functions, they weren’t function pointers. Granted I could have put pointers to the function bindings into fields in a struct and stored that struct in the mutex, but the ability to anyhow call the bindings would still exist.
It’s a massive win, and I would question the credibility of any systems programmer that doesn’t recognize that as soon as they understand the wrapper arrangement. I would have to assume that such people are going around making egregious errors in how they’re using mutexes in their C-like code, and are the reason Rust is such an important language to roll out everywhere.
The only time I’ve ever needed a Mutex<()> so far with Rust is when I had to interop with a C library which itself was not thread safe (unprotected use of global variables), so I needed to lock the placeholder mutex each time I called one of the C functions.
Valid questions. Do we have firm answers to any of them? And absent firm answers, what kind of risks to the safety of the general public are we willing to accept in service of ideological values?
Yeah… I’m all for compassion and understanding, but if someone is missing the voice in their head that says “Hey, we shouldn’t be killing people” then their circuitry is broken, no matter what age they are or what their circumstances are. And that broken circuitry poses a real and present danger to everyone in that person’s orbit.
I don’t support punitive incarceration, but the general public has the right to exist with a reasonable degree of certainty that they’re not likely to encounter a cold blooded murderer on any given day, and part of ensuring that is to incarcerate people who are known to kill others, at least until such a time that we can have a high degree of confidence that they won’t be doing that again.
The person being a child doesn’t really change that part of the social contract. I promise you won’t be any less upset if someone you love is murdered by a child than by an adult.
People just don’t want to believe that China can win at capitalism because it undermines all their internal narratives around the innovation power of liberalism. I say this as someone who does not personally like China and its authoritarianism.
The fact of the matter is with a population of nearly 1.5 billion people, you’re statistically guaranteed to have enormous pools of talent to draw on. Even a relatively modest per capita investment in education, focused on key objectives and funneled into the portion of the talent pool that they’ve managed to identify, will be able to yield massive innovation.
A lot of people will suffer under this authoritarianism. The people from these talent pools will be exploited and burnt out at a young age. This is already happening in China. But as a nation, it will be able to position itself extremely well technologically and economically, and this is a reality the rest of the world needs to be prepared to deal with.
The ideas in the article are great, I’m just a little confused by some aspects of the author’s tone where it sounds like there’s an assumption that the Rust community isn’t interested in expanding the scope of the language to every conceivable use case domain and height.
For the 4 years that I’ve been paying attention the Rust language is advancing faster than I ever thought a language is able to, but more importantly that advancement has been sound and sensible. So far I haven’t seen a language feature make it into Rust stable and thought “Oh no that was a mistake”, even as features roll in at an incredible rate.
Compare that to the C++ ecosystem where I feel like almost every new language feature is arriving very slowly while also being poorly executed (not that I think the ISO committee is doing their job badly; I just think it’s effectively impossible to make new language features in C++ without gross problems so long as you demand backwards compatibility).
I fully expect everything in this very sensible list to make it into the language at a reasonable pace. I don’t object to the “bikeshedding” as much as the author here seems to because I’d appreciate if Rust can avoid painting itself into a corner with bad language design choices the way C++ has. If we’re talking about language ergonomics, I’d rather suffer some tedium now while waiting for a feature to be polished than be stuck in a corner forever in the future because a bad decision was made.
One example I can think of is I’m not convinced that his proposal around kwargs for function arguments is a good thing, at least not without some serious thinking. For example should it support the ability to reduce foo(a, b, x: x) to just foo(a, b, x) like what’s done for struct construction? If so then the optional arguments start to look too much like positional arguments and the syntax starts to get questionable to me. On the other hand if that simplification isn’t supported then that becomes inconsistent with other parts of the language. So this is something that I believe requires a lot of serious thought, and maybe the better answer is to have built-in macros for generating builder structs
That being said, the edition system of Rust could afford us some leeway on not being forever trapped with a bad language design choice, but I don’t think we want to rely too much on that.
OP really needs to heed this advice. Modifying things in the cache will cause breakages that will confuse the hell out of you.