I'm even seeing tiny firmware moving to Rust. no_std noalloc Rust is actually a pretty good fit for that environment, especially since a lot of tiny firmware code absolutely, positively must not crash, ever. Rust's memory safety plus the no-panic crate get you about as close to that as possible without formal methods. The biggest remaining gap is stack overflow. flip-link is a pretty good tool for that; it doesn't keep you from blowing the stack, but it makes stack overflows a hard, immediate crash rather than quiet corruption.

Ah, the "Of course we can do this if only programmers always remember to do X, Y and Z" argument.

This is exactly the point. Rust encodes those safe practices into the language and has the compiler enforce them. No one is arguing that it's not possible to write safe, correct C code. Only that humans are incapable of doing it at scale.

Of course he asked himself those questions. The problem is that the answer is "I can't. I can do some things to try to reduce their occurrence, but C is fundamentally not designed to make avoiding them possible".

You clearly haven't written a significant amount of Rust (or C++) and then disassembled it to examine the output.

You mean, what Rust does.

Is a C string even UTF-8? You have no idea. The *only* thing you know about a C string is that it has some bytes and (you hope!) a NUL terminator.

You mean, what Rust does.

It's also the pointer stuff that trips up people who do understand the underlying assembly language code.

Only if your compiler sucks, which hasn't been the case for a very long time. Back in the late 80s when I started writing C, compilers already optimized switch statements into binary searches of the target space. By the early 90s I'd encountered a couple of compilers that optimized them into extremely efficient hash tables, making them both faster and more compact. In the 2020s compilers are downright wizardly at optimizing these things.

This is actually really important for Rust, because Rust's type-safe-union enums strongly encourage heavy use of switches. Many cases that require vtable-based polymorphism in C++ (or structs of function pointers in C) end up as highly-optimized switches in Rust. You can do vtables in Rust, too, but they're strikingly less common than in C++ and even than in many common C styles.

Good C++ classes use functions that are as small and single-purpose as possible. You can write crap code in any language. You can write slow code in any language.

This doesn't follow at all. Using the C runtime doesn't preclude being a better C, at all. The problems with C have very little to do with its runtime. C's problems are all about the lack of bounds checking, lack of dangling pointer checking, lack of thread synchronization checking. Note that in Rust the last two things are done entirely at compile time. It's like if "-Wall -Werror" got 1000 times smarter. Not because the compiler is smarter but because the language semantics don't require the compiler to allow a lot of potentially bad stuff.

It is true that sometimes Rust is too restrictive, disallowing provably safe code. Just yesterday, I couldn't convince the borrow checker that a function was safe without breaking a hashmap lookup into two steps. I actually considered using a small unsafe block to avoid the extra lookup. I decided against it, but this raises two points: First, in Rust if you need to you can always discard the protections (though note that even "unsafe" blocks are more restrictive than"-Wall -Werror") and drop down to a C style, or even assembler if you need to. Second, and more importantly, Rust points out when you're doing something potentially risky and forces you to think hard about it. C just lets you do it... even with -Wall -Werror.

Rust is fine for both, though when using in the kernel, drivers or on bare metal, you have to configure it correctly. For context, I'm currently writing bare metal code in Rust on a device that has minimal stack and no heap. It's no_std, noalloc, abort-on-panic (though I'm using the marvelous no-panic crate to statically verify that my code cannot panic). The code is very compact and very efficient -- but also guaranteed to be safe against buffer overflows, dangling references, etc. and, IMO, substantially more readable than the same thing would be in C. Making it compact and efficient requires understanding the code that will be generated, of course. This is universally true.

C has everything to do with it. C requires that programmers be infallible. They're not. They never have been. They never will be.

Rust's designers understand that programmers are human and will always make mistakes so the language allows and even requires building safe zero-cost abstractions that allow the compiler to check for huge swathes of common mistakes. Rust isn't the first language to do that, by any means, but it's the first language that (a) does it consistently and thoroughly (C++ fails this test), (b) is efficient enough for low-level system and kernel coding (managed-runtime languages fail this test) and (c) has achieved sufficiently-broad adoption (many niche languages fail this test).

If you want to communicate "nuance", maybe start by not using the word "immediate" when you mean in "a few decades".

I have no idea what your point is at all. Seriously, are you OK? Just to make it clear - I am against governments, I am against governments using any technology to make it easier for government to oppress people and this is one instrument of oppression.

If you shift school times, you impact parents who have to go to work, so businesses will need to shift their times, too. At that point, you've just reimplemented the clock shift, but in an ad-hoc, unsynchronized and patchwork fashion.

I've done it for most of my career, probably 20 of 35 years, including the near-decade I was a manager -- and I was WFH full-time, not half-time (1000 miles from the office). I did try to get onsite for a week every couple of months. Making it work requires a lot of overcommunication, but it can be done.

Nonsense.

Oh, there are some forces slowing us down, especially the orange man, but even if all of those forces went away or even reversed course 180 degrees there's no way we'd make "an immediate switch". It would and will take many years. It's complicated, there are a lot of moving parts, and we'll get to a point (CA is already there on a lot of days) where renewables frequently have to be curtailed because there isn't enough storage to shift that generation to times of low renewable generation.

Indeed. Case in point immediately above this post.

Indeed. Though, total capacity matters, too. I had a 2014 Tesla that only had ~200 miles of range, and road-tripping with that car was moderately painful. It was especially bad in areas where Superchargers were further apart and when there was a lot of elevation increase from one to the next, because it meant that I often had to charge to full to be able to reach the next. The smaller battery meant a lower miles per minute figure even at the best charge rate, but if you have to charge to full you're also waiting through the abysmal charge rate of the worst miles-per-minute part of the charge cycle.

I don't think you can really boil it down to just one figure. Though if I had to, "miles per minute while charging from 10% to 60%" is probably the best.

Absolutely wrong. A 1C battery is a 1C battery, regardless of how large it is. Different chemistries and configurations can affect this, but size absolutely does not, assuming the charger is capable of delivering power at the max rate the pack can take it at peak flow -- but 350-400 kW chargers are the norm.

Also, learn how to post. All it takes is trivial HTML markup knowledge.

Name-calling, especially when coupled with calling me clueless while demonstrating your own complete lack of understanding, earns you a Foe, which means it's unlikely I'll ever see your posts again.

Not really. You size the power to what the batteries can take at the fastest phase of charging. 350 kW is the norm for fast charging now. A 50 kWh 1C battery that charges at 4C when low (meaning that if it could sustain that rate for the whole recharge it would charge empty to full in 1/4 hour), would max out at around 200 kW. 3C is a more typical max rate, so 150 kW.

From the summary:

The small battery pack also means faster charging times

That's not how this works. Charging time is unrelated to battery size, except that in a given amount of time a larger battery can take in more energy. You charge all of the cells in a battery in parallel, so unless your input power is limited by something, charge time is dominated by how long it takes a single cell to go from empty to full. The number of cells (i.e. the size of the battery) is only relevant to how much power your charging system needs to deliver so that all of the cells can charge as quickly as possible.

There's a little variability among chemistries, but to a first approximation, the Li-ion cells we use today all take about 1 hour to fill from empty, when given power at the highest rate they can handle without sustaining damage. And they can take it faster when they're close to empty.

If you want to minimize the amount of time it takes to add X miles of range, what you want isn't a smaller battery, it's a larger battery. Suppose you want to add 50 miles of range in two minutes. Assuming 165 Wh/mile, you need to add 8.25 kWh. In two minutes a low battery (say, 20% SoC) can add about 10% of its capacity, so to get 50 miles in two minutes at the assumed mileage, you need an 82.5 kWh battery, and a 250 kW charger.

I'm sure Tesla has done the math carefully and weighed size and cost against range and charge times for their expected usage pattern and determined that 50 kWh is the right balance. But a smaller battery doesn't reduce charging times. For a given demand profile, a smaller battery increases charge time and a larger battery decreases charge time.

So how can this be allowed if there is so much graft around this technology that is flowing through thousands of hands in the government offices?

Here is an example: https://www.fmcsa.dot.gov/news...

This here: https://simpler.grants.gov/opp...

Funding Opportunity Number: FM-MHP-26-002
Assistance Listing: 20.245
Funding Details: $52.7 million expected total amount to award

Executive Summary:
The objective of the HP-ITD program is to advance the
technological capability and promote the deployment of
intelligent transportation system applications for CMV
operations, including CMV, commercial driver, and carrier-
specific information systems and networks, and to
support/maintain CMV information systems and networks to
(i) link Federal motor carrier safety information systems with
State CMV systems; (ii) improve safety and productivity of
CMVs and commercial drivers; (iii) and reduce costs
associated with CMV operations and regulatory
requirements.

Eligible Applicants
1.1 General
The HP-ITD awards are available to States, the District of Columbia, the Commonwealth of Puerto
Rico, the Commonwealth of the Northern Mariana Islands, American Samoa, Guam, and the U.S. Virgin
Islands. FMCSA may award HP-ITD funds to eligible applicants that have an approved program plan as
outlined in the Fixing Americaâ(TM)s Surface Transportation (FAST) Act. Individuals and businesses are
not eligible to apply for HP-ITD funding.

This entire thing is premised on the idea that there will be *more* information available to the federal government to work with, not less. They are fully committed to using these ALPR cameras that are everywhere now to track everything all the time and to put every truck driver out of service for any inconsistency in their visual data and thus hand out more fines, more court time, more oppression.

This is just one single program, one example, there are so much more, there is so much money at stake, never mind the actual flock graft itself.