I had it write an ansible job to enable a service with a specific name, and I got what I expected: something that looks correct a first glance, but with some subtle errors.

Much like half the answers on stack overflow.

Rather than ask it to write a full ansible job, try asking it the question you would ask on Stack Overflow (i.e. you probably wouldn't ask Stack Overflow to write the full job for you).

Disagree with your disagree. I understand there’s a recession and security people have to justify their salaries.

The most secure system imaginable is for your users to shut their computers and go outside. If you can’t provide security without usability, your system is worthless.

The truth is that users want products that feel secure, rather than products that are secure.

This is a misguided and incorrect assessment except for your second point, IMO.

What do you mean by “fundamental problems.” I’m using chrome right now, it works great, and there’s no better browser.

I assure you they’re not embarrassed they didn’t write it in rust from the beginning and they’re not embarrassed to have written the best and most successful browser there is.

They are so very "not embarrassed" that they are embarking on a massive change in how they operate. Or, claim to be; we will need to wait and see if it really happens, and then, if it does happen, if it has any desirable outcome.

We can anyway be certain Google does not need unpaid help defending them.

How many bugs should a software project have? You can’t justify a rewrite of working code because there might be bugs.

Memory bugs! I mean mean memory bugs.

Every project should have exactly zero (0) memory bugs. That's nigh impossible to achieve with large codebases written in C/C++ or some other unsafe language.

Chromium and FireFox are still busily fixing memory bugs twenty years after the code was written. It's a God-awful mess!

I’m not sure what you’d gain is worth the cost. What’s the cost in dollars and cents of SQLite cves over the past 20 years, and what would the cost be of rewriting that entire codebase?

At some point you have to come to terms with the fact that some bugs shouldn’t be fixed.

I think the cost savings is more than just the cves. You also get faster features and have to write fewer tests. You can use higher level abstractions with fewer rough edges. You may even be able to take advantage of the ecosystem more.

And you don't have to rewrite everything at once, you can do it at the function or file level bit by bit. Perhaps the parts that are changing the most are done first, or perhaps the parts with the most bugs.

I'm still not saying rewriting is always right or wrong, but I think it isn't as cut and dry as some make it sound.

We sure are all great on here aren’t we? Plaudits to everyone involved.

Irrelevant. You can get a full amino acid profile by combining plant based sources. It is basic high school biology that there’s less energy available the higher up on the food pyramid you go.

Farming Lions for meat would be less economical than farming cows. Farming cows is less economical than farming wheat.

> You can get a full amino acid profile by combining plant based sources.

Well, yeah, that's why I'm asking how meat compares to those rather than pure calories sources like corn or sugar cane.

Meat is heavily subsidized.

Beyond is a world ahead of both of those. The actual problem is that they’re not as good as the impossible that Burger King has seen success with.

Fake meat has gotten much better over the past few years, and there are still companies producing the bad versions from decades ago.

Right. Op is saying an unsafe program that’s paying the bills and we can fix later is better than being a Rust evangelist on hn because your startup never got off the ground.

Somewhere out there, a startup is writing a browser in pure safe rust, and there won’t be any memory errors in it because they’re never gonna take on any tech debt and it’s never gonna ship.

Yeah I understand but I disagree.

If you race a skilled Rust team against an equally skilled C++ team to build some big complicated fast software, the Rust team would likely ship first, and with less bugs.

The C++ team will eventually ship too, but it will take much longer. The software will also be of high quality, and very slightly superior performance, but there will be a couple of memory leaks, maybe a couple of exploits, and possibly a tricky segfault, somewhere down the line. Maintaining the C++ team’s software without introducing further issues will require superhuman intelligence, so it won’t happen - there will increasing issues as the team turns over and the detailed understanding of the code is lost over time.

The Rust team will mostly suffer from frustration about how bad async is, go down the rabbit hole of using it, and then rip it out and replace it with hand-rolled state machines and epoll. Down the line at some point, future programmers will decide this is legacy garbage and replace it all with async again.

There will be no segfault or memory exploits, and a similar number of logic bugs to the c++ team.

I say this having worked on large C++ projects and large Rust projects, and with no particular religious love for Rust other than a grateful appreciation for the compiler.