2 ms·

Hm, I'd cut the cake a little differently. I think there's two kinds of consistency we can strive for: - Strict consistency. Every pointer in my b-tree must po

Hm, I'd cut the cake a little differently. I think there's two kinds of consistency we can strive for: - Strict consistency. Every pointer in my b-tree must point to a b-tree node, and not random data which could cause the program to crash. In a financial world, a bank should never print money. - Fuzzy "good enough" consistency. In the examples in the article, all of the financial transactions should end up close enough to being reconciled. There's value in both kinds of consistency. When talking about data entered by humans into a database, there's always going to be a bit of slop involved. Someone mistyped a digit. A few records weren't entered at all. But when building software systems, designing with strict consistency guarantees is such an unbelievably massive win. I can't overstate how important it is. The entire ladder of abstraction in modern computers from transistors all the way up to this website is only possible because each layer "underneath" the layer we're standing on is solid and deterministic. If CPUs made even 1 error in every billion operations, our computers wouldn't boot at all. Tony Hoare talks about his invention of null pointers as his "billion dollar mistake". Null pointers take something that should be strictly consistent (references) and make it fuzzy. Rust is exciting lots of people in the systems programming space because it takes things that are fuzzy in C (aliasing, memory management, thread-safe variables, etc) and makes them strictly consistent. All the value in unit testing comes from how they make our systems more strictly correct. Every time I've relaxed consistency guarantees internally in systems I've worked on (or heard coworkers doing the same) we've come to regret it. At a startup several years ago, we needed to build an external search index for a database. The database updated live - and we had a change feed that updated the browsers live as records changed. The engineer in charge did a "good enough" job - he wrote a scrappy script that was only mostly correct. But it sometimes left the index inconsistent with the data. We got constant reports from our users about items not showing up in the search results. He would dutifully go back and fiddle with things to try and fix the problem. Eventually one of our senior engineers went in and rewrote the whole indexing script to be strictly correct. We never heard a peep about it after that - it just worked, every time. Even putting aside the frustration of our users, writing it correctly was a big win for us in terms of maintenance. Once it was correct, we didn't need to keep pulling engineering time away to fix problems. Maybe data consistency is overrated in databases. But I think if anything, consistency internally in computing systems is underrated. We take for granted how well computers work. But our capacity to make computers do anything depends entirely on those consistency guarantees. It seems ridiculous to disregard its importance.

fuoqi 4y ago
>In a financial world, a bank should never print money. Except banks routinely do "print money" (if you agree that credit and money are effectively the same). Even without delving into workings of our financial system, there are enough stories of banks making mistakes which erroneously increase their liabilities to clients. Banks simply revert such mistakes if they can or sue clients if money were withdrawn before such mistake was found. So it's much closer to fuzzy/eventual consistency.
IanCal 4y ago
> In a financial world, a bank should never print money. It's not relevant to the point but this is absolutely what banks do in the UK and I expect in most modern economies. They create money. https://www.bankofengland.co.uk/explainers/how-is-money-created https://www.bankofengland.co.uk/explainers/how-is-money-crea...
zvrba 4y ago
> Null pointers take something that should be strictly consistent (references) and make it fuzzy. I'd disagree; this is still strict consistency, at least in managed languages like Java or C#. (Coming from someone who has fully embraced nulls instead of fighting them.) "Strict consistency" breaks in C and C++ where a pointer can either point to 1) a valid object, 2) be null, 3) point to an invalid address (i.e., dereferencing it crashes the program). Cases 1 and 2 can simply be distinguished by simple != 0 check. There is no (direct, simple, portable, defined by the language) check to distinguish between cases 1 and 3, which is where the inconsistency arises.
- josephg 4y ago
  >> Null pointers take something that should be strictly consistent (references) and make it fuzzy. > I'd disagree; this is still strict consistency, at least in managed languages like Java or C# The semantics are well defined, but the program that lives in my head (where the pointer is never null) can be subtly different from the program that runs on my computer. On the computer, the pointer can and will very occasionally be null, because I have a bug somewhere else in my code that the compiler isn't smart enough to point out to me. That window of fuzzyness is wide enough to fit a peak hour traffic jam full of bugs. > (Coming from someone who has fully embraced nulls instead of fighting them.) Everyone who programs in C, Java, Javascript, C# and all the other languages with null pointers feel like they "embrace nulls rather than fight them". And yet, memory bugs still make up ~60% of the critical security vulnerabilities in Chrome and other systems software. I've seen so many crashes in application software over the years from null pointer exceptions (or the C/C++ equivalents). I've been programming for 30 years and I still make occasional mistakes in these languages ending up with null pointer related errors. I think its fair to say that moving away from implicitly nullable types lowers our collective defect rate. Language authors are on board too. Haskell, Swift, Rust, Typescript and even (I think) C++ now have non-nullable types in their type system. Even if you feel like you're too smart to need the guard rails of non-nullable references, I'm definitely not that smart. And chances are, you run my code. Tightening up this stuff lowers the chance that my software crashes while you're using it.

fuoqi 4y ago

>In a financial world, a bank should never print money. Except banks routinely do "print money" (if you agree that credit and money are effectively the same). Even without delving into workings of our financial system, there are enough stories of banks making mistakes which erroneously increase their liabilities to clients. Banks simply revert such mistakes if they can or sue clients if money were withdrawn before such mistake was found. So it's much closer to fuzzy/eventual consistency.

IanCal 4y ago

> In a financial world, a bank should never print money. It's not relevant to the point but this is absolutely what banks do in the UK and I expect in most modern economies. They create money. https://www.bankofengland.co.uk/explainers/how-is-money-created https://www.bankofengland.co.uk/explainers/how-is-money-crea...

zvrba 4y ago

> Null pointers take something that should be strictly consistent (references) and make it fuzzy. I'd disagree; this is still strict consistency, at least in managed languages like Java or C#. (Coming from someone who has fully embraced nulls instead of fighting them.) "Strict consistency" breaks in C and C++ where a pointer can either point to 1) a valid object, 2) be null, 3) point to an invalid address (i.e., dereferencing it crashes the program). Cases 1 and 2 can simply be distinguished by simple != 0 check. There is no (direct, simple, portable, defined by the language) check to distinguish between cases 1 and 3, which is where the inconsistency arises.

josephg 4y ago
>> Null pointers take something that should be strictly consistent (references) and make it fuzzy. > I'd disagree; this is still strict consistency, at least in managed languages like Java or C# The semantics are well defined, but the program that lives in my head (where the pointer is never null) can be subtly different from the program that runs on my computer. On the computer, the pointer can and will very occasionally be null, because I have a bug somewhere else in my code that the compiler isn't smart enough to point out to me. That window of fuzzyness is wide enough to fit a peak hour traffic jam full of bugs. > (Coming from someone who has fully embraced nulls instead of fighting them.) Everyone who programs in C, Java, Javascript, C# and all the other languages with null pointers feel like they "embrace nulls rather than fight them". And yet, memory bugs still make up ~60% of the critical security vulnerabilities in Chrome and other systems software. I've seen so many crashes in application software over the years from null pointer exceptions (or the C/C++ equivalents). I've been programming for 30 years and I still make occasional mistakes in these languages ending up with null pointer related errors. I think its fair to say that moving away from implicitly nullable types lowers our collective defect rate. Language authors are on board too. Haskell, Swift, Rust, Typescript and even (I think) C++ now have non-nullable types in their type system. Even if you feel like you're too smart to need the guard rails of non-nullable references, I'm definitely not that smart. And chances are, you run my code. Tightening up this stuff lowers the chance that my software crashes while you're using it.