> "Ramping up" means planned to increase.

No it doesn't. It means increasing.

Sure, but increasing something like fucking coal power plants isn't some instantaneous event that could start and stop at any time, putting some ambiguity at the moment between "increased" and "increasing". If plants are or will be built, it's because it's planned for development. That '-ing' isn't just present tense, it's there for the continuous/progressive aspect of it.

If they produced 13% more energy from coal in 2025 than 2024, the latest point at which we have real numbers rather than projections, it's fair to say that production of energy from coal is increasing rather than decreasing.

as the references point out (please re-read this chain), it increased but is not increasing. the context of what your replying to:

> The US is in an excellent position to massively harness wind and solar and yet right now it's dialing up the coal usage

they are not "dialing it up", they instead have planned reduction.

> as the references point out (please re-read this chain), it increased but is not increasing.

As I pointed out (please re-read my comment), it was increasing as of the most recent time for which we have data (not projections) available.

Not if the bike goes significantly slower than the e-bike. Which is the whole point.

Idk, I think baby becomes pancake no matter the speed. With my naive understanding of the physics involved, the weight of the teenager and their bike compared to the relatively tiny baby is going to be the deciding factor here.

> my first motorbike ride and car drive at 60kmh were terrifying

Maybe those should be more tightly regulated.

> Why do e-bikes become better or more safe when you have to rotate your legs?

Because you're directly engaged in operating them. Electric handcycles are also legal, the problem isn't which body part it is, it's whether you're moving muscles to move your bike - and, perhaps more importantly, that your bike will stop accelerating when you stop your body.

Must be nice to live in a world simpler than the one I do. Your broad generalization has so many deficiencies that I actually deleted what I was writing. There are countless exceptions to your hasty generalization.

If that's how you want to redefine the term, sure, ok. But the "victim" in this particular scenario is the one at fault.

You seem to be unwilling to assign blame to the operator of hazardous machinery for running people over. Why is that? "They should know better"? Kids? Disabled people unable to use their mobility devices on the unplowed sidewalks? Animals?

If you cannot control yourself enough to slow down around people, you need to get out of the driver's seat. If you cannot stop before a potential crash, you were going too fast. 100% of the time. It literally does not matter if someone jumps in front of you. If you're going to choose the statistically most violent mode of transportation by multiple orders of magnitude, that is your responsibility.

Certainly very hard to defend against that when the messenger you're using won't let you use a device you control.

Early '90s maybe. By the late '90s people knew tests were a good idea, and many even applied that in practice.

This all sounds very clever, but in practice no, most of the problems are code problems and if you do functional programming you really can avoid getting paged at 3AM because everything broke. (Even if you don't solve the deployment problem the article talks about - you're not deploying at 3AM!). It's like those 400IQ articles about how Rust won't fix all your security problems because it can't catch semantic errors, whereas meanwhile in the real world 70% of vulnerabilities are basic memory safety issues.

And doing the things the article suggests would be mostly useless, because the problem is always the boundary between your neat little world and the outside. You can't solve the semantic drift problem by being more careful about which versions of the code you allow to coexist, because the vast majority of semantic drift problems happen when end users (or third parties you integrate with) change their mind about what one of the fields in their/your data model means. There are actually bitemporal database systems that will version the code as well as the data, that allow you to compute what you thought the value was last Thursday with the code you were running last Thursday ("bank python"). It solves some problems, but not as many as you might think.

> It's like those 400IQ articles about how Rust won't fix all your security problems because it can't catch semantic errors, whereas meanwhile in the real world 70% of vulnerabilities are basic memory safety issues.

even setting aside the memory safety stuff, having sum types and compiler-enforced error handling is also not nothing...

The thing is, you're gaining a bunch of knowledge about compiler internals and optimisations, but those aren't necessarily specified or preserved, so it's questionable how valuable that experience actually is. The next release of the compiler might rewrite the optimiser, or introduce a new pass, and so your knowledge goes out of date. And even if you have perfect knowledge of the optimiser and can write code that's UB according to the standard but will be optimised correctly by this specific compiler... would that actually be a good idea?

All of that is less true in the microcontroller world where compilers change more slowly and your product will likely be locked to a specific compiler version for its entire lifecycle anyway (and certainly you don't have to worry about end users compiling with a different compiler). In that case maybe getting deeply involved in your compiler's internals makes more sense.

Learning about how compilers optimize code isn't really knowledge that goes out of date. Yes, things get reshuffled or new ideas appear, but everything builds on what's already there.

You'd never want (except in extreme desperation) to use this knowledge to to justify undefined behavior in your code. You use it to make sure you don't have any UB around! Strategies like "I wrote a null pointer check, why isn't it showing up anywhere in the assembly?" can be really helpful to resolve problems.

You're not just learning the specific thing this compiler does on this code, but also the sorts of things compilers can do, in general.

The US would spend 20 years arguing about which agency's jurisdiction it was, and ignore the dead babies?

No, wait, Volvo is European. They'd impose a 300% tariff and direct anyone who wanted a baby-killing model car to buy one from US manufacturers instead.