After a successful and relatively long beta testing phase, EOP is now blessed for use in production, with Motoko compiler version 0.14.4 onwards.
Goal
EOP has been designed with the intention to relieve programmers from dealing with stable memory by offering an upgrade mechanism that is simple, safe, and scalable at the same time:
Simplicity: By way of orthogonal persistence (the persistent actor or stable variables in Motoko), transitively reachable structures of any first-order type are automatically persisted across upgrades. No stable memory or stable data structures are needed.
Safety: The runtime system rigorously checks type compatibility on upgrades and supports several kinds of data changes by implicit migration. Any more complex migration can be implemented by custom code, in particular with the new Motoko migration syntax. This prevents any data corruption or misinterpretation at the memory level.
Scalability: Upgrades become super-fast because the main memory is simply retained on an upgrade. No copying to and from stable memory is needed. The main memory has been extended to 64-bit to scale as large as stable memory in the future.
While orthogonal persistence (persistent actor and stable variables) was already available in previous Motoko versions, EOP significantly strengthens safety and scalability to make it the persistence model of choice. EOP is a feature that is unique to Motoko, as the language and runtime system have been specifically tailored to the properties of the IC.
Configuration
To activate enhanced orthogonal persistence under dfx, the following command-line argument needs to be specified in dfx.json:
Congrats! I know how long and hard you all have been working on this and I’m really excited to see it come to fruition. This was a long-promised feature of the IC. It’s omission at Genesis was a bit disappointing, but we all know when making software, you have to cut scope to ship. It is a testament to the determination of the DFINITY Foundation and its employees that you all keep shipping, filling the gaps, and making good on promises. Many, many thanks from this community member!
Congrats on this huge milestone! I will never be able to fully fathom the complexity of this update, but I will boast that I was here when it happened!
One question, how should we think about theoretical and practical heap size limitations here on out? Thank you!
Limited memory: The IC will initially only offer a limited capacity of the 64-bit main memory, e.g. 4GB or 6GB. This will be gradually increased in the future to approach the same capacity as stable memory.
Huge milestone, @luc-blaeser! Super excited to integrate EOP into the RuBaRu DApp — we’ve been eagerly waiting for this to go live. Also, does the move to 64-bit main memory mean enhanced DeAI capabilities on Motoko Canisters too, as hinted by Dom in his tweets?
Hey there!
I never wrote anything in Motoko and EOP is actually the first reason for me to try it out instead of Rust. Thanks you for this effort!
I have a question about storage and references in Motoko.
Let’s say I have two stable maps. If I store something in one map and then store the same thing in another map, will they be two different objects or the same one? I mean, if I then update one of the entries, will the other one also get updated?
It depends on the value you’re putting in both maps, and how you’re referencing it there. For primitives, i.e stable let x = 5 it’s pass by value, but if you’re referencing an object (i.e. array/map) the reference is passed. So in that case updating the value in one data structure would also update the value that it’s referenced at elsewhere.
Here’s a basic example you can deploy and play around with.