hnb2137's comments

On: What happened to WebAssembly

[hnb2137]

WASM allows you to run some parts of the application a bit faster. ;)

On: Google has most of my email because it has all of yours (2014)

[hnb2137]

Until slmail.me disappears and all your logins stop working and can no longer be changed.

On: UML diagram for the DDD example in Evans' book

[hnb2137]

One of the creators of UML, Booch, has said so himself that it was taken to a point where it should never have. Interesting interview: https://youtu.be/u7WaC429YcU?feature=shared

[titaphraz → hnb2137]

Thanks. I was only going to find the part about UML but I ended listening to the whole thing. What a legend!

On: Career Development: What It Means to Be a Manager, Director, or VP (2015)

[hnb2137]

How many Big Macs?

[Thrymr → hnb2137]

or grande non-fat lattes?

On: Programmers are bad at managing state (2020)

[hnb2137]

And only once delivery. And only once delivery.

[btschaegg → hnb2137]

This reads more and more like Monty Python's Spanish inquisition sketches. I love it :)

[Ygg2 → btschaegg]

Nobody expects the Spanish Programming inquisition! Amongst our weaponry are: bad naming, undefined 46$$43$_22#3off data races. by one errors,

And only once delivery. And only once delivery. And cache invalidation. And cache inva

Damn it! I can't say it, you'll have to say it.

[malfist → hnb2137]

Only one delivery is easy as long as you don't guarantee delivery

[paulddraper → malfist]

(commenter meant to say exactly once)

On: Causal Trees

[hnb2137]

CRDTs solve the problem of concurrent updates bij users.

[tomaskafka → hnb2137]

And offline edits from concurrent users

[OskarS → tomaskafka]

I've always wondered if it's a good trick for horizontal scaling as well. Like, if you have one server serving 1,000,000 clients, using a CRDT you could trivially split that up into 10 servers serving 100,000 clients each, and then have the ten servers be peers to each other.

[josephg → OskarS]

The one “downside” compared to regular databases is that CRDTs use optimistic concurrency. If you want transaction support, or want multiple writers to block each other, CRDTs are a bad fit. They move conflict resolution to the point when reads happen rather than make writers fetch and retry.

Still fine for a lot of use cases though.

[fauigerzigerk → josephg]

>The one “downside” compared to regular databases is that CRDTs use optimistic concurrency.

My understanding of the term "optimistic concurrency" is that a write operation can fail if the optimism turns out to be misplaced (so to speak). CRDTs on the other hand always merge deterministically and never fail, even if application level consistency constraints are violated.

This is why CRDTs are rarely useful to me, but I can see how they may be useful in domains that can live with the very weak form of consistency guarantees that CRDTs can provide.

[filleokus → fauigerzigerk]

> even if application level consistency constraints are violated.

I think, in theory at least, it should be possible to encode the application level constrains into the CRDT merging algorithm. Like how two edits making different (but overlapping) spans bold are fine to merge into one bold span, but i.e highlighting with different colors are not.

Of course the merge will never be "perfect", as it is impossible to encode all human wishes into the CRDT, but I think there is a lot of room to improve when it comes to merging non-text data.

[fauigerzigerk → filleokus]

I don't think it is theoretically possible, but even if it was, it would be tantamount to inventing one or more new CRDTs per application. Each begin/end transaction block would become its own research project.

On: The Frothy Saga of the Jacuzzi Family

[hnb2137]

Same on Android. Even on desktop mode after completing a bunch of traffic light CAPTCHAs it would not continue. Nevermind, then.