Rust tries to prevent developers from doing bad things, then has to include ways to avoid these checks for cases where it cannot prove that bad things are actually OK. Zig (and many others such as Odin, Jai, etc.) allow anything by default, but surface the fact that issues can occur in its API design. In practice the result is the same, but Rust needs to be much more complex both to do the proving and to allow the developers to ignore its rules.

[1]: https://ziglang.org/documentation/0.15.2/std/#std.math.divEx...

Rust instead has all these implicit things that just happen, and now needs ways to specify that in particular cases, it doesn't.

In any case I had one paragraph about the content and one side-note about the writing style. Every single reply except one focused on the side-note, including you.

That said I increasingly have a very strong distaste of these AI generated articles. They are long and tedious to read and it really makes me doubt that what is written there is actually true at all. I much prefer a worse written but to the point article.

Outside of that, error codes are useful for debugging code that is running on other people's machines (i.e. in production) for and for reporting reasons.

The most important is that the team needs to actually use the task board (or whatever data source you use to get your inputs) to track their work actively. It cannot be an afterthought that gets looked at every now and then, it actually needs to be something the team uses.

My current team kind of doesn't like task boards because people tend to work in small groups on projects where they can keep that stuff in their own heads. This requires some more communication but that happens naturally anyway. They are still productive, but this kind of forecasting doesn't work then.

In normal markets there are competitors who force each other to keep reasonable profit margins and to improve their product as opposed to milking other people's hard work at the expense of the consumer.

At a minimum it will help you to be skeptical at specific parts of the diff so you can look at those more closely in your review. But it can inform test scenarios etc.

In this case a few minor edge cases is really not a big deal compared to that (in my opinion).

I am not sure (of course), but I think Atwood simply thought standardizing this format was so obviously valuable that he didn't consider Gruber might not want to work with him. In retrospect it's kind of nice that it didn't happen, it really keeps everyone incentivized to keep the format simple.

I don't know how that book ever got as big as it did, all you have to do is try it to know that it's very annoying and does not help readability at all.

I used to quite like Windows, but it has gotten worse every patch day for years now. The pain of learning a new system is not so bad and at least I own my computer now.