dmsnell

yep - init is for things you can guarantee, not things you can't, like anything needing to make network or database calls.

handle_continue was added for these kinds of things that should happen when starting up gen_ processes.

the entire init chain is sequential, so not only will it risk crashing your entire supervisor tree, but it will slow startup

Not pictured, but right next to this machine is the "garry gum" and "anti-garry gum" dispenser.

note: the article mentions that the app is written in TypeScript which _is_ statically typed and therefore many of these optimizations are at least possible if not in place

> there are no icons. Civilizations had lots of icons, and eventually we got the Roman alphabet which I believe is a huge step forward. So, for links I just use words in the Roman alphabet

icons continue to be a form of universal language around the world for helping people to navigate where they need to go: this way to the bathroom, that bathroom has changing table, no smoking in this area, stop!, play/pause, radioactive, scald-danger, tent-camping, etc…

they don't communicate without ambiguity but they do serve a very functional and well-appreciated purpose for rapidly communicating information which would otherwise require more words and more thought.

adopting familiar icons around a website and providing a way to remove any ambiguity can enhance the experience; eliminating them altogether is somewhat of an overreaction

One of the notions in HATEOAS as far as I can surmise is that we decide to build a common vocabulary describing our API and that becomes the fixed interface for interaction. It's not at all meant to imply that software clients can magically figure out what to do next (thought often a human with a reasonable API app could do so).

Imagine for example that we decided that whenever you request a comment resource from my API then I promise to provide a link in the response called "upvote" which you can follow to upvote that comment.

We have agreed to a fixed interface but left plenty of details flexible.

Maybe we are experiencing heavy load: let's stop sending the "upvote" link - the clients should understand that in its absence the operation is not currently available.

Maybe we have implemented some load-balancing system which redirects clients to `fiji.api-server.com` or `romania.api-server.com` based on their geo-ip data: those clients need only hard-code one top-level API URL into their code and all other URLs come through successive API responses. Load-balancing happens automatically and can even change throughout a single session because the client follows the links instead of building its own URL.

Maybe we are running some test or gradual rollout of a new API or URL structure; as long as we provide those links and references the clients can follow the right path without needing to know about the changes. It's possible that we ended up moving comments from `api-server.com/api/threads/1337/comments/42` to `api-server.com/comments/what-do-you-kow-joe` and this won't break any client designed to follow the interface instead of the incidental details.

For what it's worth I think very few APIs come reasonably close to this design and maybe few even have much need to. REST and HATEOAS become much more important when someone is publishing a public API that many third parties will consume and the ability to introduce non-breaking changes and server-side control of different specifics is important.

/my 2¢

For what it's worth, there's a specific distinction for software systems like lane assist. The bar for "working" is so high that if it doesn't essentially work perfectly we can't say it works at all.

We would expect reviews to point out if a feature such as lane assist fails or has noteworthy failures (such as rapid weaving inside the lane) but maybe not so much if it works properly.

endless.horse