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.

In DDD, the model is loaded before any business logic is executed

That's really not a DDD requirement. Having a domain model does not require you to preload data to run business logic. For example, you can easily have business logic that only takes as input a value object and triggers a usecase, and you do not need to preload anything to instantiate a value.

If I wanted to use SQL for cache, I’d rather choose the memory engine of MySQL.

Why would you onboard an entirely separate service if you're already using PostgreSQL ?

There’s Tauri.

...and now your newbie has to onboard onto not only Rust (?!) but also HTML, CSS, and JavaScript to render "Hello World".

The Rust community is a very diverse group of people with many different opinions. It is not a universal truth that the Rust community believes Rust to be an awful first language.

You don't need to take my word for it. Google the topic and go through all the discussions. Even the ones in Rust's own forum get mixed responses, and that community is by its very nature very partial towards Rust.

Also, framing the discussion around newbies learning Rust as a first language is a strawman. The question is not whether if someone without any prior experience in programming can or cannot make and effort and write code in Rust. The question is which language to learn.

There are many programming languages to pick and choose from, and some are renowned to be very beginner friendly. Rust is not one of them.

If you want to make a case for Rust, it's up to you to prove that Rust is a better language to take first steps than any other programming language around. In my personal opinion, it is simply not possible to claim that Rust is better for this particular usecase than quite a sizable set of programming languages, including but not limited to Python. If you want to claim Rust is better suited then you need to make a case for it, and that is a challenging thing to pull off.

You missed the point

What point do you think I missed?

This SAM9x60D1G-I/LZB SOM module is a mouthful to say. But at 28mm x 28mm its roughly the same size as a US Quarter. But… at $60 it sounds like a bad value. Okay, it is a bad value, but stick with me here, this represents far more than you might think.

The Orange Pi Zero is not that larger (48 mm × 46mm), ships with up to 512MB DDR3 SDRAM, wifi, and 10/100M Ethernet RJ45, and can be bought for half the price.

The problem with desperate monetization stunts like this video is that they rarely have any relevant content to show, and they are a formulaic output of mixing clickbait titles with 15min of inane fluff.

sql was built so people other than devs can use it, but we got stuck with it.

Not really. Being designed with UX in mind, so that it sacrifices conciseness for readability, does not make it something for "people other than devs".

Likewise, BASIC was also developed with UX in mind, and no one in their right mind would ever claim that it's not a programming language.

It’s long running, so you want a database so you can store your state. If you’re storing state, locking it into a state machine makes sense.

That's besides the point. Of course that the most fitting way to represent a state machine is with a state machine. The point is that implementing the transition table in a database table creates many problems while apparently solving none.

I am but it’s a bit too much money for “just because”.

I'm on the same boat. I have a RPi4 that I briefly used as a personal computer, and even though I'd love to get a RPi5 I'm struggling to justify it. It sounds like it's around €100 for a 8GB version (board+case+power supply) and that's already in x86 MiniPC territory.

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.