You’d have had me ignore them all and keep using C for everything.
Please tell me which language other than C is widely adopted to develop firmware.
You're talking about so many up-and-comers during all these decades. Name one language other than C that ever came close to become a standard in firmware and embedded development.
Right.
With what in mind? Evading NULL?
Depends on your perspective. It's convenient to lean on type checking to avoid a whole class of bugs. You can see this either as avoiding NULL or use your type system to flag misuses.
Languages that make use of references rather than pointers don’t have this Dualism. C# has nullable references and nullability analysis, and null as a keyword.
C#'s null keyword matches the monadic approach I mentioned earlier. Nullable types work as a Maybe monad. It's the same concept shoehorned differently due to the different paths taken by these languages.
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?
While I can agree we don’t have sufficient data to make hard conclusions on this front, I think there are enough early indications that point to Rust being able to stay on par with or even outperform C++ in this regard:
I'm skeptical of these claims, not because X or Y is better or worse, but because milking the last drop of performance has far more to do with software architecture than it has to do with the programming language per se.
Also, I think this sort of argument always leads to specious reasoning. C is the undisputed performance lead, and you surely do not see Rust proponents using benchmarks to argue they should rewrite all Rust code in C.
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?
ASP.NET? The microsoft technology? That runs mostly on IIS?
No, by ASP.NET I was referring to ASP.NET Core, whose latest LTS version was released along .NET 8.
I find it absurd to make a plaidoyer to all git users to add another file to their repo to placate those unable, unwilling, or ignorant to adhere the standard.
You only speak for yourself, and your comment clearly showed you were ignorant of some basic usecases that are behind the feature you were criticizing.
This is very over-exaggerated. A lot of people started with C or C++ as their first language.
That took place over two decades ago. There were no better alternatives back then. Times have changed.
Both of which are significantly harder than learning Rust.
This is simply not true. It's far simpler and less frustrating to work on either C or C++ for the simple reason that you can shoot yourself in the foot anywhere you'd like. In Rust, newbies have to alternative to endure the compiler enforcing its safety constraints anywhere they'd like. Rust is also a far more complex and extensive language that enforces memory safety rules that can and very often are very frustrating to handle by those who don't have a firm grasp on them.
Like everyone has mentioned, because you want the data to persist across program runs.
RDBMS do not imply persisted data. There are plenty of databases which support or are designed explicitly to work as in-memory data stores. Perhaps the most popular one is SQLite, whose in-memory store is a popular choice.
But the data itself can and does lead to tracking.
I'm not sure how to express it any clearer: anonimized info, by definition and by design, does not and cannot lead to tracking.
I think it would be beneficial for their community to take the wish for more credit more serious and try to make him feel welcome.
I think they did. Apparently the maintainer trusted the first-time contributor enough to propose tackling another bug.
If the goal is to get more contributions, I think that's exactly what should happen. I feel the kernel maintainer is being treated unfairly.
Whining about getting extra work feels like the author didn't intended to contribute anything else and just put all this reputation chips on that one isolated ticket.
That's laughable. Literally the whole world uses it. Are you telling me that everyone in the world just loves to waste money? Unbelievable.