Make sense. Firmware is also extra difficult to debug so it's nice to use a language that significantly reduces the amount of debugging you need to do.
Looks interesting. Linux ABI compatibility is a herculean task though. Probably on the order of writing a web browser or a MS Word compatible word processor.
Sure there aren't many things that are universally loved. I mean I can't really think of anything that doesn't have some flaw.
But that doesn't mean everything is equal! What would you rather program with, Visual Basic or Go? PHP or Typescript? If you polled people there are obvious winners.
Think of it from the company's point of view. If you're hiring a new employee then the options for a good candidate are a) move jobs and work for you, b) move jobs and work for someone else. You're competing with other companies.
If you're reviewing an existing salary for a good employee their options are a) do nothing and accept the shitty raise, b) move jobs and work for someone else.
Moving jobs has significant cost for most people - it's time consuming, stressful, might involve moving house, etc.
That downside gives employees who haven't proven they are looking for a new job a significant negotiating disadvantage.
If you really want you can tell your boss you are actively looking for new jobs. That will increase your chances of getting a bigger raise, but of course it has other downsides so most people don't do that.
Rust is the obvious answer, though I dunno how suitable it really is for games - the most popular game engine is Bevy and I'm not sure I like it too much. Also there seems to be much more focus on game technology than making actual games.
Don't worry about it being "functional" though. It did support lots of FP features but the typical style is much more like imperative C++ than Haskell.
Languages that make use of references rather than pointers don’t have this Dualism.
It's not about references vs pointers. You could easily have a language that allowed "null references" (edit: too much C++; of course many languages allow null references, e.g. Javascript) or one that properly separated null pointers out in the type system.
I agree with your point though, using a special Null value is usually worse than using Option or similar. And nullptr_t doesn't help with this at all.
Very complicated. Way more complexity than you want in most cases.
Depends on HTTP 2. I've seen people who weren't even doing web stuff reach for gRPC, and now boom you have a web server in your stack for now reason. Compare to Thrift which properly separates out encodings, transports, etc.
Doesn't work from the web. There are actually two modifications to gRPC to make it work on the web which means you have three different incompatible versions of gRPC with different feature sets. IIRC some of them require setting up complex proxies, some don't support streaming calls, ugh. Total mess.
Plain HTTP can be type safe. Just publish JSON schema or Typespec files or even use Protobuf.
TOML is not a very good format IMO. It's fine for very simple config structures, but as soon as you have any level of nesting at all it becomes an unobvious mess. Worse than YAML even.
What is this even?
[[fruits]]
name = "apple"
[fruits.physical]
color = "red"
shape = "round"
[[fruits.varieties]]
name = "red delicious"
[[fruits.varieties]]
name = "granny smith"
[[fruits]]
name = "banana"
[[fruits.varieties]]
name = "plantain"
That's an example from the docs, and I have literally no idea what structure it makes. Compare to the JSON which is far more obvious:
Good. I had a couple of answers to one of my questions that just wasted my time before I realised they were AI. The authors didn't get banned annoyingly.
Well that just sounds insane. Isn't the whole point of an abstracted API that you can write code for it once and it works with all of the implementations?
Questions about AI seem to always bring out these naysayers. I can only assume they feel threatened? You see the same tedious fallacies again and again:
AI can't "think" (using some arbitrary and unstated definition of the word "think" that just so happens to exclude AI by definition).
They're stochastic parrots and can only reproduce things they've seen in their training set (despite copious evidence to the contrary).
They're just "next word predictors" so they fundamentally are incapable of doing X (where X is a thing they have already done).
I'm not moving any goalposts. The addition of the . was very blatant. They literally just added a syntax error. It went undetected because humans don't have the stamina to exhaustively do code review down to that level. Computers (even AI) don't have that issue.
Don't listen to the idiots downvoting you. This is absolutely a good task for AI. I suspect current AI isn't quite clever enough to detect this sort of thing reliably unless it is very blatant malicious code, but a lot of malicious code is fairly blatant if you have the time to actually read an entire codebase in detail, which of course AI can do and humans can't.
For example the extra . that disabled a test in xz? I think current AI would easily be capable of highlighting it as wrong. It probably wouldn't be able to figure out that it was malicious rather than a mistake yet though.
submitting a merge request with changes that don’t compile is an absolute no-go.
Right but unless the tests for all 50 filesystems are excellent (I'd be surprised; does Linux even have a CI system?) then the fact that you've broken some of them isn't going to cause a compile error. That's what the linked presentation was about! Rust encodes more semantic information into the type system so it can detect breakages at compile time. With C you're relying entirely on tests.
That appears to not support comments. How they made that mistake after JSON is a mystery.