Handle_continue callback for OTP - good or bad?

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…

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

It is amazing; but one have to be carefull because if the awaited continuation takes a long time—say 5 seconds—other processes that are awaiting a response from a handle_call might timeout. I quite like it because it formalize the use of selective receives in gen_servers.

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.