The whole point of having teachers is to give intellectually developing and still vulnerable children the best possible support they could have from a human which is ideally interested in their well-being, being responsible and in doing a good job.

Replacing that with AI is the kind of SV-stupid which starts making sense after the educational system was hollowed out for profit reasons and is failing. The human in that system is just checking in and DGAF.

A little cheating here, a bit of fraud there and before one knows it, one is CEO of some AI company.

The revealing thing is how the cheating is seen as normal and how the other people are considered out of touch or wrong.

It’s fair to ask people bragging about their amazing AI skills to show their code or GTFO. Hope it becomes established.

I work on proprietary software, so no, that’s not really a fair question to ask.

However, if you’re willing to share how you’re prompting the AI and some examples of where you think the results are poor, we might be able to help identify what’s causing the difference. I’d be genuinely interested in understanding why we’re getting such different results.

Rather than assuming one of us must be wrong, it would be more useful to compare approaches and see what we can learn from each other.

Well, low-stakes clients are usually poor clients because they’re clueless and overly demanding.

Real designers would avoid them in the first place.

And that’s why they want to use AI.

The problem’s not so much that the posters are AI generated, but that they’re too crowded and unfocused. Their individual elements seem fine and look good, but when taken as a whole they feel wrong.

This may be a failure mode similar to juniors using AI and making it much harder for seniors to find the bugs, because the code actually looks good at first sight.

I don’t think the blog author actually has any design skills based on the prompts and the AI obviously can’t nudge them in the right direction or help them clarify their brief, like a real designer (i.e. not random online freelancers) would.

Replace opt with its equivalent “choose” and it becomes choose-(tobe-)in and choose-(tobe-)out.

The set-up and your reply feel like a Rust sketch.

Not touching a codebase only applies to legacy software which is feature complete. Any actively developed software will benefit from incremental improvements.

Quality C++ projects continuously improve their code and tooling. It would be very convenient for the rustafarian community if the competition stood still, but that’s not the case. Quite happy to see that golang’s also providing solid opposition.

Note that an incremental language improvement doesn't mean a small code change. For example, C++'s iterator with two related but technically independent pointers is a PITA for alias analysis, which is a problem not only for Circle/Safe C++ but for WG21 Profiles too (https://www.circle-lang.org/draft-profiles.html). An incremental language change would be to adopt a Rust-like iterator. That would be a small language change, but a migration away from begin/end would be a massive churn for C++ codebases that sounds more ridiculous than rewriting in Rust.

Bjarne still sees C++'s safety problem as lack of adoption of Modern C++. WG21 is catering to C++ users who will not make such changes.

WG21 has firmly rejected everything resembling Rust's borrow checking (a solution that now has a decade of proven track record, and has been demonstrated to be possible in C++ via Circle/Safe C++). Addition of "pervasive annotations" is so unacceptable to WG21's view of C++ that they're still insisting on Profiles.

“Because incremental improvements don't provide enough value. A stable C++ codebase is best left untouched.”

That was most of your original comment and it remains wrong.

Now you’re talking about specific memory-safety-related features, but you’re making a big assumption. Not everything has to look like Rust. Goodness no! And C++ is still improving in that area too.

“An incremental language change would be to adopt a Rust-like iterator.” One of many possibilities.

“That would be a small language change, but a migration away from begin/end would be a massive churn for C++ codebases that sounds more ridiculous than rewriting in Rust.” Obviously not. Nowadays maybe it could be easily done with AI, even if a Rust-like iterator is not necessarily something that C++ programmers would want.

Don’t believe everything you read. Any communication from them is a PR exercise.

On the other hand, I read an interesting substack blog from an ex-Azure employee the other day: the Russinovich-dictated Rust rewrite was allegedly vaporware for a long time and caused lots of headaches that were not widely known. A highlight for me was the use of over 1000 third party crates in their products.

Would be interesting to know how it’s going nowadays.

As any company, the one I work for also has its decent share of rustafarians. The Rust penetration is modest and slow, but the PR is remarkable.

It’s useful for DIY, but definitely not great. One has to carefully double-check everything; there’s no unit-tests to save your butt.

It can help out with understanding tools, workflows, materials, etc but doesn’t actually understands what it’s writing about and is prone to over-engineering, making critical mistakes or just replying with nonsense (for example swapping dimensions, recommending a completely inappropriate procedure, the wrong tool, etc).

This is all with Opus and Sol. Paying 22€ per month for that is a bit pricy for what one gets in return.