V: Consideration: Crash Handling / Recovery similar to Erlang possible?

[ylluminate]

Something to consider at some point: Is it possible to make a crash handling / recovery system similar to Erlang in V? There are various things to consider from conversations in Discord:

• here: https://discordapp.com/channels/592103645835821068/665558664949530644/686713726073569302
• and here: https://discordapp.com/channels/592103645835821068/592115457029308427/687023233089667117

[dumblob]

Could you please copy the relevant parts of the discussion here? Sometimes (like now) I can't reach Discord and I think I'm not the only one.

It's also better if Discord discards (or changes :open_mouth:) the history or changes the permalinks (yeah, nothing is fully "perma" :wink:). Btw. this is also what Stackoverflow dictates, so it proved useful.

Thanks!

[cristian-ilies-vasile]

@dumblob
FYI
ElixirConf 2018 - Introducing Scenic A Functional UI Framework - Boyd Multerer

a compiled crash recoverable system might be the game changer for everyone looking on.

My understanding of ylluminate's proposal is that the ideal V recovery mechanism should run on auto mode, without defer / panic / recover explicit instructions.
Erlang design was done with high reliability of 99.9999... in mind, for telecom civil and military equipment (switch boards) able to run without a glitch 24/7/365 for years, similar with what mainframes are doing.

[dumblob]

FYI
ElixirConf 2018 - Introducing Scenic A Functional UI Framework - Boyd Multerer

Thanks for the link. Scenic seems to be actually an Elixir version of concur-js with a nice API built around explicit widget graph manipulation and with efficient pub-sub backend built in (note there are many other ways to implement the "processors" - "drivers" as thery're called in Scenic - not just by yield as in the linked repo or by a separate go routine for each widget).

a compiled crash recoverable system might be the game changer for everyone looking on.

My understanding of ylluminate's proposal is that the ideal V recovery mechanism should run on auto mode, without defer / panic / recover explicit instructions.
Erlang design was done with high reliability of 99.9999... in mind, for telecom civil and military equipment (switch boards) able to run without a glitch 24/7/365 for years, similar with what mainframes are doing.

I don't think we need much more in V to achieve this kind of reliability - first, if my proposal gets implemented, then every reentrant go routine actually guarantees it'll be restarted if there is less than 1 such instance. Second, in my proposal basically everything can be achieved due to the possibility to influence/exchange the scheduler, so you'll be totally free to write your scheduler which'll react to specific crashes of go routines (here I use the term crash for go routines returning with return error( 'my error' ), but not go routines panic()king, because I still strongly hope panic() will disappear from V as it makes all this stuff very complicated and doesn't offer anything more than return error()).

[Immortalin]

Another language that V can borrow features from is Pony. It shares a lot of ideas with Erlang and Rust.

[cristian-ilies-vasile]

@Immortalin
We are aware of Pony, Kotlin, Go, Python, Ballerina, Chapel, see https://github.com/vlang/v/issues/1868 &
https://github.com/vlang/v/issues/3814

[cristian-ilies-vasile]

Neither me nor @dumblob are main developers, so we don't know which solution will be chosen for the future if any.