[marvy]

If I understand the persistence stuff correctly, programs don't do explicit I/O but instead just run forever and thus use normal variables and data structures to store state.

This sounds very convenient until one fine day you decide add a new feature, so you need to change your code, but the new code has different variables and there may not be any sensible way to "port" the data.

[jpalomaki]

” Motoko provides numerous features to help you leverage this environment, including language features that allow your heap to self-migrate when you upgrade the software of a canister.” https://sdk.dfinity.org/docs/language-guide/motoko.html

So in this sense it could be a bit like creating migrations to your database. Maybe on ”cloud scale” you just would like to migrate the data when it is used.

Edit: Few more details in this document: https://sdk.dfinity.org/docs/language-guide/actors-async.htm...

[marvy]

Okay, so the magic ingredient is that variables that are marked "stable" are treated specially. Nice!

[coldtea]

Not sure what the problem is supposed to be. Is the idea here that the programs don't do I/O (e.g. to disk/db/etc) ever?

Because that's not probably what it happens...

[arethuza]

Sounds more like you don't have to worry about mapping your variables to and from an underlying persistent store - it happens automagically.

It's an idea that has been tried on and off for decades and is obviously very appealing but tends to have lots of interesting problems when it has been used for a while - often when you want to access your data outside the context of your application.