devnullbrain

Weird that you don't understand it. Have you read any of the replies in the multitudes of times you've invariably seen this discussion come up online?

OK. Is it a sensible thought? Did VPNs exist in 1949?

No, it's trite and useless. You don't need to refer to popular literature to talk about authoritarianism, there are plenty of examples in real life.

In addition to the sibling comment: I really dislike opening my Photos app in front of other people.

Aw, I missed it

You seem to be blaming the OS for how you broke it?

I'm not the PC but I think you miss most of the pain points due to: 'personal' projects.

There's not a compatible format between different compilers, or even different versions of the same compiler, or even the same versions of the same compiler with different flags.

This seems immediately to create too many permutations of builds for them to be distributable artifacts as we'd use them in other languages. More like a glorified object file cache. So what problem does it even solve?

How would you have minimised migration costs for std::map?

>1. Somebody verifies with the users that speed is actually one of the most burning problems.

Sometimes this is too late.

C++98 introduce `std::set` and `std::map`. The public interface means that they are effectively constrained to being red-black trees, with poor cache locality and suboptimal lookup. It took until C++11 for `std::unordered_map` and `std::unordered_set`, which brought with them the adage that you should probably use them unless you know you want ordering. Now since C++23 we finally have `std::flat_set` and `std::flat_map`, with contiguous memory layouts. 25 years to half-solve an optimisation problem and naive developers will still be using the wrong thing.

As soon as the interface made contact with the public, the opportunity to follow Rob Pike's Rule 5 was lost. If you create something where you're expected to uphold a certain behaviour, you need to consider if the performance of data structures could be a functional constraint.

At this point, the rule becomes cyclical and nonsensical: it's not premature if it's the right time to do it. It's not optimisation if it's functional.

> and the missing context is essential.

Oh yes, I'd recommend everyone who uses the phrase reads the rest of the paper to see the kinds of optimisations that Knuth considers justified. For example, optimising memory accesses in quicksort.

A state machine is a perfect example of a case where you would benefit from linear types.

Some things just need precise terminology so humans can communicate about them to humans without ambiguity. It doesn't mean they're inherently complex: the article provides simple definitions. It's the same for most engineering, science and language. One of the most valuable skills I've learned in my career is to differentiate between expressions, statements, items, etc. - how often have you heard that the hardest problem in software development is coordinating with other developers? If you learn proper terminology, you can say exactly what you mean. Simple language doesn't mean more clear.

I wasn't born knowing Rust, I had to learn it. So I'm always surprised by complaints about Rust being too complex directed at the many unremarkable people who have undergone this process without issues. What does it say, really? That you're not as good as them at learning things? In what other context do software people on the internet so freely share self-doubt?

I also wonder about their career plans for the future. LLMs are already capable of understanding these concepts. The tide is rising.

...a far better place than 2011.

Come on, the 6th word after 5 English words is obviously going to be a rare word in your second keyboard language, not another common English word.

>You see, the shapes of roads in real life come from an underlying essential fact: the wheel axles of a vehicle. No matter how you drive a car, the distance between the left and right wheels remains constant. You can notice this in tyre tracks in snow or sand. Two perfectly parallel paths, always the same distance apart maintaining a consistent curved shape.

Emphasis mine - that's not really true

- Cars have differentials, so the wheel speed can differ between wheels

- Steering geometry isn't parallel! The tyres turn a different amount when you turn the wheel

- Unless you're going in a straight line, cars don't go where the tyres point! Tyres 'pull' the car towards their slip angle

What you will actually see in tracks in snow or sand is non-parallel tracks, describing curves of different radii. You can also see this in racetracks, where the path more closely resembles the limits of car physics without care for passenger comfort or tyre wear. The example 'fail' image looks not dissimilar from a hairpin turn.