Later, it turned out the Clinton campaign had essentially taken over the DNC far in advance of the primary results which is highly unusual, to the say the least. [1]

[1] https://www.politico.com/magazine/story/2017/11/02/clinton-b...

That should absolutely include wear and tear as well as accidental damage. Intentional damage is an issue, but there shouldn't be much motivation for it under such a system.

I don't understand why this argument gets thrown about so often. Obviously not so much about neo-nazis in particular, but whenever a comparison is made to LGBT people. And before anybody jumps to conclusions, I am not about to argue that sexual orientation is a choice.

Even in the face of overwhelming evidence of all kinds, from all sorts of sources, there are people that seem to honestly believe the earth is flat. There is no way to make a reasoned decision to believe that. It must be something they are not in control of. It could be something they were born with, something in their experiences, or both, but it's clearly something they are not rationally deciding.

I'm not certain it can be said that the neo-nazis are definitely making a choice. It seems to be a pretty vehement emotional response, which would indicate it's not.

I don't mean to say we should tolerate neo-nazis in the sense that we just let them do their thing. But I do think we might be better off treating them as people that have some predisposition to being neo-nazis than as people that just decided to be one.

I understand avoiding excessive amounts of large boiler plate where standard patterns are constantly repeated for no particular reason, but that's not a comparable situation to individual keywords.

Taxes are already pretty divorced from use of the services they pay for. People with more money than you have had more of it "forcefully" taken from them to pay for the roads, emergency services, and so on that you use.

You may as well ask any other sort of technical trivia question and figure the people that happen to carry around more random facts about tech are more likely to understand the bigger things that do matter. It isn't necessarily wrong it's a pretty obtuse way to make a judgment. Why not just ask them about the memory hierarchy or network delays or whatever directly?

The reason is that things today are "fast enough." These days most slowdowns aren't the result of the CPU not executing instructions fast enough. Other factors dominate, such as memory access patterns, network delays, and interfacing with other complex software such as databases.

Unless you are doing compute-heavy code, the speed of the CPU isn't much of a factor in estimating how fast the program will run.

Which really just demonstrates the point, I think. At some point things are "fast enough" that it just doesn't matter. We've reached that point with computers. Unless you are working in a niche field that needs serious compute, the sources of performance problems are almost never going to arise from issues like trying to execute too many add instructions in a given period. The delays will come from things that are significantly harder to see - network, database, or program architecture + runtime.

If you want to add fractions by individually adding the numerators and denominators and the only reason you don't is one of these checks, you have some kind of fundamental lack of understanding about fractions. It's great that you are wise enough to verify, but that's irrelevant to your mathematical understanding.

Mostly it just means I'm in trouble and need to be really careful and do more checks because I'm working with things I don't understand fully.

For example, I've never needed to do that sort of check with adding fractions. I have enough understanding of what those numbers represent and how they work together that I've just never thought I might want to add numerators and denominators separately.

Checking is the smart thing to do then, but ideally what is important is the understanding rather than just the diligence to make sure a guess isn't trivially shown incorrect.

It also gives you a lot more control over portions, which can be an issue as well. There is no point packing more than you are going to eat.

I brought up the salt content not for health reasons, but taste. Many of the ones I've tried have been so salty I've had trouble finishing them even after a day of backpacking.

If your goals include speed or (less) weight, those freeze dried options are really far from ideal. To get around the weight issue you mostly need to plan and package your food yourself, which takes some time. If you're getting called out to do SAR you either need to have it done in advance or go with another option.

And I've seen that before. Frankly I thought it overly nice to Rust by not spending any time at all considering the differences in user-defined types. That's really one of the biggest and most important differences to me, and a place I think Rust really falls short.

Once you do get to explicit memory management, Ada does a number of things. I'm going to a list here just for my own sanity.

First, all deallocations are essentially marked unsafe. You use Unchecked_Deallocation() to free memory.

More importantly, it provides memory pools, and subpools. Each pointer type can be associated with a pool (or subpool). Once the pool goes out of scope, all memory is freed. You can use this to avoid explicit deallocations yourself. Pools also control allocations and deallocations, and there exist Debug pools that can help ensure memory is accessed correctly.

Ada also requires that stack-based objects be declared as "aliased" before you may make a pointer to them, so it's always clear where there might be trouble.

Finally (I think), Ada has a concept of accessibility levels. Essentially a pointer cannot point to an object that is more deeply scoped than itself. This isn't the perfection of the Rust borrow checker, but it does quite a bit.

As for C FFI, Ada does that quite well. It's got a package in the standard library with C interface types, and aspects for marking things for C FFI.