If the language makes common but dofficult to deal with error impossible, that’s nice. Not critical, but nice.
If the language introduces easy to make and hard to deal with errors, that’s an issue. Not a deal breaker, but an issue.
The idea does exist, but it’s stated with way more confidence and finality than it deserves. That’s social media I guess.
The evolution strategy: if you don’t know what you’re doing, every function is a feature!
A very low current transformer, more of kess yeah.
Some lights will charge op and flicker, others have a constant glow. The speed/brightness depends on how long the wire is, so most residential lamps are unnoticeable even when it happens, but large rooms and weird wiring can make it more obvious.
LEDs are so efficient that even microamps can power them. If your LED driver is cheap, it’ll run on basically nothing, or charge up enough to start for a fraction of a second.
The microamps come from a hot wire running next to a switched wire behaving as a capacitor when carrying AC voltage, letting microamps leak through. (It’s not required that the light is on the hot side of the switch as I said previously, my bad).
This can happen if the switch box is a terminal box with hot and switched wires in the same cable, which is rather common. Probably some other configurations too.
Worse, if the LED is wired to the hot side it will just barely glow at all times.
Yet Another Better Barrel Attempt (YABBA)
Memory leaks are often difficult to deal with, and many contemporary languages basically encourage them. I know many applications that suffer significant performance issues due to memory leaks, and way too many that simply don’t care about memory footprint.
A language that treats memory management differently from the start makes all these problems much easier to deal with, if they appear at all. The real question is if the other costs of using the language are worth the somewhat niche performance gains.