I agree. Those who make bold claims like "AI is making programmers worse" neither has any first-hand experience with AI tools nor has any contact with how programmers are using them in their day-to-day business.

Let's think about this for a second: one feature of GitHub Copilot is the /explain command, which is used to put together a synthetic description of what a codebase does. Please someone tell me how a programmer gets worse at their job by having a tool that helps him understand any codebase anywhere.

If you write it down it is documentation.

I think you're not getting the point.

It matters nothing if you write down something. For a project, only the requirements specification matters. The system requirements specification document lists exactly what you need to deliver and under which conditions. It matters nothing if you write a README.md or post something in a random wiki.

Requirements are not the same thing as specifications either, but both are documentation!

https://en.wikipedia.org/wiki/System_requirements_specification

All of the other things you mention can be solved with money. In terms of the things that are easy and hard, this very much the former.

I don't think you know what you're talking about, or have any experience working in a corporate environment and asking for funding or extraordinary payments to external parties to deliver something. I even personally know of cases where low-level grunts opt to pay for licenses out of pocket just to not have to deal with the hassle of jumping through the necesssry hoops. You just don't reach out for the cash bag and throw money at things. Do you think that corporations work like hip-hop videos?

C has always been (...)

I think you tried too hard to see patterns where there are none.

It's way simpler than what you tried to make it out to be: C was one of the very first programming languages put together. It's authors rushed to get a working compiler while using it to develop an operating system. In the 70s you did not had the benefit of leveraging half a century of UX, DX, or any X at all. The only X that was a part of the equation was the developers' own personal experience.

Once C was made a reality, it stuck. Due to the importance of preserving backward compatibility, it stays mostly the same.

Rust was different. Rust was created after the world piled up science, technology, experience, and craftsmanship for half a century. Their authors had the benefit of a clean slate approach and insight onto what worked and didn't worked before. They had the advantage of having a wealth of knowledge and insight being formed already before they started.

That's it.

And that’s how software development became just another profession.

I don't think that's a healthy way of framing things. Software development was always, from the very start, just another profession. What changed in the last decade or so was a) supply and demand in the job market, b) the quality of the pool of workers searching for jobs. Companies still look for developers, and most still pay handsomely well, but the hiring bar is currently met only by those who are far more experienced and/or paid attention to their career growth. You still see companies hiring people straight out of bootcamps, but they come out of the bootcamp pipeline with proper portfolios and they hit the ground running without requiring that much training or onboarding.

In contrast, the blogger states that "After more than a decade of sitting behind a single company's desk, my CV looks bleak." A decade is a very long time to stay idle by without updating their skills, isn't it?

I saw this phenomenon throughout the past decade in the hiring loops I was involved. In the demand peak I already saw a few developers with over a decade of experience interviewing for senior positions that started their interviews already defeated and broken, complaining that in their last roles they just went with the flow and never bothered to do anything relevant with their career. They claimed they could fit the role and do whatever needed to be done, but the truth of the matter is that that's true for each and every single developer called for a technical review. We needed to have some assurance that we were hiring the best candidate for the job, and these developers with a long experience of "sitting behind a single company's desk" gave us nothing to work with. So why would we hire them over those who could show off something?

I use C++ all the time, undefined behavior is not something I encounter ever. I run undefined behavior sanitizer often.

From the looks of some of the posts showing up in this thread, I doubt the bulk of the commenters portraying UB as the root cause of any problem have any experience at all with C or C++. They are clearly resorting to unrealistic strawmen to pretend UB is something that it clearly is not. That just goes to show their technical background and the substance behind their claims. I really don't know how this helps advocating for Rust.

Each implementation that exhibits different behavior doubles the amount of testing needed to ensure cross-platform correctness.

Not really. The whole point of undefined behavior is that the standard intentionally leaves out any definition of behavior, or the program is already fundamentally broken.

If you insist on unwittingly using code that relies on undefined behavior, you're the one mindlessly writing broken code. It's not the standard's fault that you're adding bugs.

The irony is that compiler implementations also leverage undefined behavior to save you from yourself and prevent programs to crash when they stumble upon the mess you've done with the code.

I’m reasonably sure compilers can shift the if out. I believe it’s called “loop invariant code motion”.

That scenario would only apply if the condition was constant and specified at compile time. There's no indication on whether var1 or var2 are compile-time constants or predicates evaluated at runtime.

Also, it’s worth noting that cargo is a fairly good package manager all things considered.

Yes, I'm familiar with Cargo. My point was to point out the absurdity and silliness of OP's remarks on "no bulky management of a virtual environment, no make files, no maven, etc." Once Rust fundamentalista take off their rose-tinted glasses, it's clear that Cargo is just as good (or as bad) as any contemporary integrated build system.

At that volume of communication, the Github workflow of “clicking through stuff” is way inferior to an efficient email workflow. Essentially, your workflow turns into email anyways because its the only sane way to consume based on push (...)

I don't agree. Any conversation on pull requests happens through issues/tickets, which already aggregate all related events and are trivially referenced through their permanent links, including through the Git repo's history.

You could just upvote Java 8 and Java 17

A database carry the schema, structure, that allow you to validate that you are still having the structure you want.

So do all file formats.

SQLite is both a file and a database, but what I’m saying is that people shouldn’t mess with the file, but the database interface instead.

The same holds for all file formats: don't go around licking random bits in a file, use a client instead.

I have nothing against third party clients, the important thing is keeping the structure.

That's what file format clients are for, and anyone can even roll out their own if they want it.

The facts a DB use the Filesystem behind the scenes, is an implementation details the user shouldn’t be much concerned about, some DB can do without Filesystems.

That's really besides the point. The point is that it doesn't make sense to frame using databases over files as using a higher level client over persisted data.