A common scenario for lazy init is establishing a connection to an external system like a database or a message broker. You don’t want to establish the connection in the init because it may fail and you then loose the ability for your supervisor to recover that process.

I think it expresses actually what you want when trying to use send’s inside the init or right after creation of a genserver, which is start and this is your first message, but what was actually expressed with send was start and here's a message which could end up in race conditions.

Extracting keys from maps in ets also seems like a great addition

From the article:

This will do just what you wanted from the beginning - execute the async initialization code before accepting any message, but allow parent supervisor to continue execution. No race conditions possible - “it just works” ™️!

OK, perhaps it makes sense. Teaches me for firing off a post before reading the full article…