I think I could have states my opinion better. I think LLMs total value remains to be seen. They allow totally incompetent developers to occasionally pass as below average developers.

This is a baseless assertion from your end, and a purely personal one.

My anecdotal evidence is that the best software engineers I know use these tools extensively to get rid of churn and drudge work, and they apply it anywhere and everywhere they can.

Walter Bright has fairly odious political opinions;

I fail to see the relevance of what personal opinions and beliefs he may or may not have. You're making it sound like the goal is not to improve a language ir fix issues, but to take something away from a person just because you disagree with their political opinions. That's hardly good use of anyone's time, and sounds terribly petty behavior.

I wish I had that much free time to be able to waste it being so vindictive about such trifling issues.

Which languages have you invested/migrated to, only to find that “political stunts” had a “negative impact” on your planned development?

I don't waste my time with meaningless irrelevant stuff. Either a tech stack serves it's purpose, or it doesn't. I don't have enough free time to waste it trying to cancel others.

I'm partial for the Royal Kludge RK84 for no particular reason other than it's one of the rare small form factor keyboards that has USB passthrough. It's a godsend if you use a USB security key, and it also helps if you need to plug in additional devices such as a USB headset.

If keychron had any model that supported USB passthrough, I'd update my recommendation.

I’d go with an ergonomic one to avoid pain on the outside of the wrists.

I might be totally wrong, but I firmly believe these ergonomic risk factors are not the root cause of these health problems, and instead they are indirect factors that are correlated with fundamental problems affecting a person's activity.

For example, tennis elbow isn't caused by a particular model of a tennis racket, nor is jumper's knee caused by a shoe model. Interestingly, I stumbled upon a post somewhere in the past that pointed out that Emacs users had a higher incidence of repetitive strain injuries than vi users. One of the most basic treatments of RSI is a combination of working on the patient's overall posture and rest, regardless of keyboard format.

If you're experiencing wrist pain due to keyboard usage, the time you spend typing is a far more important factor than what keyboard model you're using.

Ive never gotten to write rust professionally, but I have always kinda winder d if it was marketed wrong. My thought was always that it should be sold as “easy” though. Its easy to write code. It’s hard(er) to make mistakes.

I agree, but I don't think the problem is marketing. The problem is how some elements of Rust's community desperately try to upsell the language beyond the value it actually can provide, and once that fails they fall back to toxic behavior and basically just mindlessly shitting on anything that's not Rust. It goes well beyond a cargo cult mentality, and it's sad that a fine technology is dragged through the mud by those who were expected to show its value.

my point was that I was able to find answers for everything else before I had to resort to posting a question.

That's not a SO problem per se. Some projects do use SO as their semi-official customer support channel, but in general posting a question on SO is not supposed to be better than posting a question on Reddit: you get what you paid for.

They force you think of o(n) and train you better than anything else on how to write your functions (but not how to organise them).

I agree. I think it's all about blind spots. A software engineer spends most of the time reading code, and the changesets they write most of the time are not algorithms or any fancy iteration beyond doing a vanilla for loop over a collection. leetcode-type exercises tend to invert that tendency, and present us with challenges which we would only rarely tackle. It's a good exercise in the sense that it forces a type of usecase we don't often use. Still, their practical usefulness beyond coding crossword puzzles is very limited.

This might sound silly but I think that coding challenges like HackerRank, CodeSignal help me improve/learn programming.

At first I thought they were utter crap, and recruiters used them to test candidates on artificial problems that matter nothing and reflected no relevant skill. I still do, they are awful at that. What a complete waste of time and effort.

However, these coding challenges are like crossword puzzles. They present us with nonsense challenges that provide us with the opportunity to employ obscure programming constructs on a multitude of programming languages in a way that rarely happen in real world professional settings. I use them to explore obscure corners of standard libraries, solve the same problem in multiple ways, employ different idiomatic ways to iterate over data structures, etc. That's helpful in a way.

Nothing. Just read Mozilla’s Manifesto

Your trolling skills are subpar but given this is a lazy weekend I guess I'll bite just for the entertaining value.

Let's go through "Principle 2, 3, 4 and 7", shall we?

Principle 2 The internet is a global public resource that must remain open and accessible.

Making source code available through GitHub is a realization of Principle 2. You got it exactly backwards.

Principle 3 The internet must enrich the lives of individual human beings.

I don't even know what could possess you to believe that making a software project available through GitHub would jeopardize this. Anyway.

Principle 7 Free and open source software promotes the development of the internet as a public resource.

That's what making FLOSS projects available to the public through GitHub does. GitHub, by providing managed hosting to Mozilla to host Firefox's project tree and making it available to the public, is unquestionably meeting this goal, both in its letter and its spirit.

You need to put some effort into finding things to be outraged about.

Which is what putting most of this stuff on the background accomplishes.

The part you're missing entirely is the complexity that's hidden behind the weasel word "most".

The majority of event handlers from a GUI app do not do anything complex, computationally expensive, or blocking. They do things like setting flags, trigger changes in the UI state (i.e., show/hide/update widgets) bump counters, etc.

No one in their right mind would ever consider going through the trouble of doing this stuff in separate threads/processes. "Most" handlers run perfectly fine on the main thread.

Nevertheless software changes, and today's onClick handler that sets a flag to true/false tomorrow is required to emit a metric event or switch a different treatment depending on the state of a feature flag or A/B test, or is required to write a setting to disk or something like that.

How do you draw the line in the sand that tells whether this handler should run on the main thread, should trigger a fire-and-forget background task, or should be covered by a dedicated userflow with a complete story board?

That's the stuff that's hand-waved away with weasel words like "most".

This blog post delivers a crisp mental model to tell which approach is suitable: follow the real time computing rulebook, acknowledge that each and every handler has a time budget, and if a handler overspends it's budget them it needs to be refactored.

Java 12

Well, in Rust, it’s a sum-type

The discussion is on to use monads in C++, and not on why is C++ different than Rust.

I repeat: you do not need sum types to implement a Result monad in C++.