As a complement to @claudio’s one-pager about Long-term R&D for Motoko summarising the big picture, I’ve thrown together a little document outlining some of the Motoko team’s thoughts regarding the language’s longer-term evolution. This focusses exclusively on language design. It does not discuss implementation improvements, libraries, tools, or other related concerns.
(I apologise for the rough shape the document is in. I wanted to put it out there before the holidays and didn’t have quite enough time to polish it properly.)
This would be great! Right now, it’s quite tedious to transform objects.
As a side question, the document makes reference to the Motoko interpreter. I thought Motoko was a compiled language. Where does the interpreter come into play?
I thought Motoko was a compiled language. Where does the interpreter come into play?
If you invoke moc without a file argument, then it will enter an interpreter REPL. Or you can run a file in interpreted mode with -r.
This is not well-documented, because the interpreter misses almost all IC features, so isn’t useful for real apps. But it allows playing around with the language a little.
Before Motoko I liked Elixir/Erlang as a language because it was concurrent by design. It also followed the Actor model. Motoko and canister design really takes that into the future. I can’t see myself programming in anything else at the moment. Can’t wait to learn more about it.
Dumb question, but in the Motoko docs they often say that shared types cannot include mutable data because of security concerns.
How do two actors even “share” mutable data? I don’t get how that would work even if you wanted to do it. Canisters run on different machines with no shared memory, so I don’t quite understand how sharing mutable data is even possible to begin with…
@jzxchiang, distributed mutable state could be implemented using some message protocol under the hood of the language runtime. But given the constraints of the IC, and especially its hardwired messaging model, it would indeed be rather difficult, and certainly very expensive (you’ll need distributed garbage collection, too).
@cyberbowl, Erlang was one of the many inspirations for Motoko, and there still is a thing or two that the IC and Motoko can probably learn from it. The approach to error handling, for example.
Not sure about that doc but sharing stateful objects would break the isolated, shared nothing, communication only by async message passing philosophy of the actor model that let’s it scale from shared memory to distributed implementation.
It’s unfortunate that we chose the keyword ‘shared’ to describe communicable values, given that the term evokes shared memory concurrency, but that ship has sadly sailed.
I like the generalization but I still like the record update syntax in Scala (Motokoized):
let o1 = {a = 1; b = 2};
let o2 = o1.copy(a = 3; c = 4);
I would like records to be more distinct from objects in Motoko. I saw some discussion of that but it doesn’t look like that is going anywhere. Merging objects implies merging behavior and that is a more complex topic than merging values. Scala manages to class inheritance with mixin semantics using clearly defined override rules to avoid the diamond problem.