I don't have a strong opinion on the beta site, but I do know that they need to stop listening to the exact people that killed their site (or allowed it to be killed by AI at least).
Actually they should have stopped listening to them a decade ago. Now is way too late.
Doesn't say anything you didn't already know. Probably written with AI.
Also the conclusion is wrong:
Neither approach is universally superior.
The Rust approach is obviously superior.
Less "best kept secret" more "not very useful so nobody cared to learn about it".
Very easy to install
This has to be a joke.
Why would I hate systemd? It has fixed many of the problems with desktop Linux that many people refused to even admit were problems. This looks like it throws all that away.
Sort of. He's definitely right that make_u32_from_two_u16 is a terrible function name that obscures the meaning but I don't think he's right that the best solution is to inline it. C bit shifting is notoriously error prone - I've seen this bug multiple times:
uint32_t a = ...;
uint32_t b = ...;
uint64_t c = (a << 32) | b;
The real problem is the name isn't very good. E.g. it could be u32_high_low_to_u64 or something. Might clearer. Certainly easily at kernel code levels of clarity.
(Really the naming issue comes from C not having keyword arguments but you can't do anything about that.)
I don't think they're stupid, they just don't care about the same things. The sooner people understand that the better.
Generally a bad idea to use in-band signalling like that. They won't do anything weird but consider what happens if the actual data contains them.
Yeah it always bothered me that they're saying "concurrency is not concurrency".
I'm going to start using "multitasking" instead. That's so much better. Who's with me?
def foo(x):
return x.whatevr
No linter is going to catch that.
Wow I was wondering what toolkit they were going to use... apparently the answer is "yes".
Yeah if you saw the quality of my coworkers' code you would not be saying this.