I am not sure what you mean by "style", but top chess grandmasters certainly play in a different way today compared to, say, 20 years ago. Current play is much more concrete (less based on general strategic principles) and players are willing to take greater risks for rewards such as material gains, since AIs have shown that there are often many more defensive resources than was previously thought as long as the defender remains tenacious.
Acting responsibly as a researcher who has discovered a vulnerability requires delicately balancing a question of two greater evils. Will more people get hurt overall if we announce the vulnerability sooner, or will more people get hurt overall if we wait until the vendor is ready?
In most cases, working with the vendor to allow a patch and a warning to be released is the path of least harm. But sometimes the right decision is to announce a vulnerability before the vendor has issued a patch.
The first time I ever heard the Numa Numa song was when I was 10 and had the flu. I was puking in the hallway and had intense nausea for hours. My classmates kept playing the song because it was the new viral thing.
It took me over 10 years before I could listen to the song without feeling sick. It's fine now though.
I'm pretty sure part of the job of a bodyguard is to ensure the well being of their client. If they ask for something that improves safety but makes the client miserable, they are not doing their job.
Have you used a lot of go? I'm a big fan of rust and definitely like rust devs and the rust community, but I find that people haven't used go enough to "get" it don't really understand just how much it can take away from cognitive load.
Rust and go are not really comparable in this regard, even if rust is much better than most people realize. There are too many ways to approach a problem in rust.
That said, definitely there are plenty of places where rust is a much better language choice than go
I’m not making any point about Go in my post, not trying to compare them, only to speak about Rust’s situation here, since that’s the question that was asked.
I have written some, but not a ton, of go. It is opinionated in ways that are very different than my own opinions, and so I didn’t enjoy it very much. That said, I deeply respect the Go team, and am glad others really like it. I’m not really the best person to compare the two languages, which is why I try not to do it.
This is not my experience at all. We've spent the past few years building a multi-hundred thousand line of code distributed system in go and have found that sticking to idiomatic go has been very beneficial in building the thing successfully.
What is with all of the condescension that other developers have towards Go developers? Go has a set of highly desirable features that are very practical for building large team projects.
Imo it's unnecessarily hostile to compare go to playmobile and diplo, and it really encourages people to overlook the genuinely excellent features that go supports.
That's really not it. The more complex a language is, the more ways there are to approach a problem. The more things to have to learn and adapt to when reading code another engineer wrote.
You want code to be obvious. The senior engineer smiles when the junior engineer reads his code and says in just seconds "I know exactly what this does and have high confidence that it has no bugs."
