It's hard to see how car sharing would reduce the number of vehicles on the road. When a personal car isn’t being used, it’s typically parked in a garage or a parking spot, not occupying road space. The actual number of cars on the road is determined by how many people are commuting at any given time and how many passengers each car holds, not by who owns the vehicles. So, whether cars are individually owned or shared, the number of occupied cars on the road should remain about the same.

However, robotaxis introduce a new factor: they drive empty between passengers, adding extra, unoccupied trips to the roads. This added movement would likely increase traffic rather than decrease it, potentially making it worse rather than improving it.

But should have we trusted random strangers on the internet in the first place? The practice how casually random libraries are included into software projects have been scaring me already for a while. It could be slightly better if all software was run in a sandbox, but even on macOS, where sandboxing is pretty much streamlined, many developers just don't bother to use the feature. Various Electron apps without sandboxing with randomly downloaded plugins (I am looking at multiple IDE-like editors) seems like recipe for a disaster to me.

Qt is not a GUI-only framework - it had other non-GUI related stuff, including networking, for ages. So, I don't think this ads support would be completely foreign compared to what Qt already had.

As I understand it is not about "existing parsers", but the parsers that are required to be fast - i.e. browser parsers that work in real time as opposed to CSS generators like SASS or Less which are usually used offline and for which couple seconds slower or faster does not have a big difference.

They have a comment about the apersand:

And programmers/engineers are users of compilers/programming languages.

The pilots go through lots of hours of training before they can get a license, yet they do mistakes and we build safer planes for them. Same with engineers. Engineers are not some special infallible kind of humans.

If you have a working thing and you want to improve it, it is easier to treat the original as a black box and add new features around it - this way it is easier to predict how your changes will influence the outcome and ensure that you don't break the original functionality. On the other hand, if you want to remove stuff, you need to know the inner workings of the original thing very well. For this reason adding may be chosen (consciously or subconsciously) more often because of a smaller risk (especially if you are not sure what you are doing), even when subtracting could lead to better solutions.

I can't believe how this got score 5,Insightful as it is so wrong.

By such definition, there are no competent programmers. All of us do mistakes once in a while. So, when some says that programmers need to be "competent" to program in C, they are talking about some fictitious nonexistent people. Following this thinking, you might be "competent" one minute and totally "incompetent" the next one.

I think overconfidence is a big evil and responsible for big part of software issues. Show me a "competent" programmer who never makes mistakes and I'll know whom not to trust.

Once you accept that everyone is fallible, it becomes obvious that you want the computer to check and validate your code as much as possible. Thats why I believe that for any modern programming language safety features should be opt-out rather than opt-in. Obviously, you will need to have some fallback to unsafe C-like mode once in a while, but such cases are quite rare and should be small and well isolated.

Regarding Rust, I can't really tell how good or bad it is. I don't use it. I tried introductory Rust tutorial once, and it seems there is quite a learning curve there. But no matter whether it is a good substitute for C or not, I believe that Rusts exploration of language safety features is the right direction in compiler and programming languages evolution.

Even the best mountaineers use safety ropes and those who do not are considered crazy.

It's not about "we want to let you do everything but not really everything", it's a buffer overflow bug.

You can buy a new prosthetic, duh.

By paying government tax, you also get benfits. The question is how fair theese taxes are. Lets think, if your app is not absolutely trivial, AppStore maintenenace just could not amount to 30% of effort you make by yourself. You may say that it is also a marketing platform, which I would agree, but first, you are forced to it, even if you dont need it, and second, I still dont think 30% for one marketing channel is really right

I think it is less about the user choice than about the busenesses that want to reach their customers. Imagine you are developer making software for some customer. Now you customer buys iPhone. So you need to make your software available on iOS. It is no way your customer would buy another Android phone just to use your product. But if you make it available on iOS, you are forced to pay 30% tax (and that is even bigger tax than you pay for the government!). In my mind this situation is definitely not monopoly abuse by letter, but it is very similar - Apple puts a leverege on you through the users of the platform, and users are kinda stuck at that platform (by choice, but they would not use another platform no matter how good your software there would be).

Did he mean "Hangover"?

Agree, several complex test may help perform smoke testing and catch major regressions reasonably well. I don't argue against that. But if you want your software to be secure and not crash when user provides strange input, you must handle edge cases well.

Nullability errors are quite common, and modern languages with Optional types help avoiding them. Another example could be switch statement over enum - compiler can notice that you are not handlng all enum cases and warn you about it - that also helps to avoid edge case where some rare case is not handled properly.

I would argue that static typing helps to achieve this. A good type system may be used to make invalid states simply unrepresentable - if you cant create an invalid state, there is less special cases to consider

Might be, but this probably goes both ways: you can't be sure that program is correct if it compiles the same way you can't be sure about that if all tests pass.

The problem with unit tests is that:
1. They must be there in the first place
2. They must be exhaustive (a few tests here or there wont help much)
3. They must be correct (if test passes, it does not necesarily checks what it should)
4. Tests must be maintained and updated together with other refactored code (and it is quite easy to miss required test changes, leading to the case 3.)
5. Even if you have lots of tests and they are well maintained and correct, it still pretty much guaranteed that not all edge cases would be covered (and writing good and robust tests is really hard)

In the end, unit tests happen to be just another tool helping to improve code quality, but it does not ensure full correctness. And as it relies on human implementing them right, it does not make unit tests a very trustworthy tool. I trust compiler more than myself or my fellow colleague.

Static typing (and static analysis based on it) is also yet another tool. But being perfomed by computer, it is much more robust and reliable. While unit tests quality may vary very widely, compiler static checks are consistently thorough and accurate (and if they are not, you have quite a big problem)

Of course static typing is not a replacement for unit tests, but in that area where they overlap, static compiler checks do a better job. And if you really care about your code quality, you should use as much helping tools as possible.

I like Python and it is usually my language of choice for scripting (mostly because of a large variety of libraries available), but for a large and complex codebase I would rather choose something more strictly typed