5 ms·

This is a very long post! The bit that actually addresses the title, after all the "here's a thing I tried, here's the weird error message, here's the mistake I

This is a very long post! The bit that actually addresses the title, after all the "here's a thing I tried, here's the weird error message, here's the mistake I made" business, starts way down towards the bottom, with this text: Before we move on, I'd like to congratulate you on reading this far. Believe it or not, you're in the minority! The title is very misleading when the content is a very, very general discussion of compile-time versus runtime errors, mostly focusing on problems that Go doesn't catch at compile time. TL;DR: the mistake Rust doesn't catch is recursive mutex locks. It does seem like it would be good to catch that one, and that the borrow checker in some form ought to be able to do it -- it should be able to track the static scope of a mutex lock, and block further attempts to lock it inside that scope.

hermanradtke 5y ago
This is a typical fasterthanlime post. It is anti-TL;DR as he takes you on the journey from the very beginning. It is through this journey that we can appreciate how good the Rust compiler is in many cases, but also its limitations (recursive mutex locks).
fasterthanlime 5y ago
As others have noted, that's just how I write articles. More specifically, I have an end goal in mind, and to get there I need to establish a scene: make sure that we share a lot of context so that we can consider a problem together from the same angle. Most articles don't do that, and so they're "short and to the point", but only to a tiny audience that already has the same shared culture. There's always readers complaining that they knew half of it and so I "wasted their time", but they forget about the other half, and also other readers. Ideally, to please everyone, I would have to write a tailored article /just for them/, filling just the gaps they have. I do that on occasion, but I charge a lot of money for it :)
- iainmerrick 5y ago
  Absolutely -- sorry if I came across as overly negative! I was trying to stay reasonably neutral. Your approach isn't one I'm keen on but I can see your subscribers get a ton of value from it.
- ovidiu 5y ago
  Maybe a table of contents right after the intro would help the impatient readers.

hermanradtke 5y ago

This is a typical fasterthanlime post. It is anti-TL;DR as he takes you on the journey from the very beginning. It is through this journey that we can appreciate how good the Rust compiler is in many cases, but also its limitations (recursive mutex locks).

fasterthanlime 5y ago

As others have noted, that's just how I write articles. More specifically, I have an end goal in mind, and to get there I need to establish a scene: make sure that we share a lot of context so that we can consider a problem together from the same angle. Most articles don't do that, and so they're "short and to the point", but only to a tiny audience that already has the same shared culture. There's always readers complaining that they knew half of it and so I "wasted their time", but they forget about the other half, and also other readers. Ideally, to please everyone, I would have to write a tailored article /just for them/, filling just the gaps they have. I do that on occasion, but I charge a lot of money for it :)

iainmerrick 5y ago
Absolutely -- sorry if I came across as overly negative! I was trying to stay reasonably neutral. Your approach isn't one I'm keen on but I can see your subscribers get a ton of value from it.
ovidiu 5y ago
Maybe a table of contents right after the intro would help the impatient readers.