# Motoko Design Evolution **URL:** \ **Category:** Language Support\ **Created:** [December 17, 2021, 3:58pm UTC](https://forum.dfinity.org/t/motoko-design-evolution/9761 "2021-12-17T15:58:25Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![rossberg](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/rossberg/32/795_2.png) [@rossberg](https://forum.dfinity.org/u/rossberg)\ **Post date:** [December 17, 2021, 3:58pm UTC](https://forum.dfinity.org/t/motoko-design-evolution/9761/1 "2021-12-17T15:58:25Z")
As a complement to @claudio’s [one-pager](https://forum.dfinity.org/t/long-term-r-d-motoko-proposal/9394/3) 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.) ---
**Author:** ![jzxchiang](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/jzxchiang/32/2592_2.png) [@jzxchiang](https://forum.dfinity.org/u/jzxchiang)\ **Post date:** [December 17, 2021, 11:29pm UTC](https://forum.dfinity.org/t/motoko-design-evolution/9761/2 "2021-12-17T23:29:16Z")
> [@rossberg](#): > > Object Composition > > Currently, objects can only be constructed using object literals. It is not possible to construct an object in terms of another, preexisting object with some fields updated or added. > > Some functional languages provide forms of _record update_ , where a form of object literal is provided that replaces or adds individual fields of a pre-existing object. In Motoko, this could easily be generalised to object _merging_ , akin to type intersection: > > ```auto > let o1 = {a = 1; b = 2}; > let o2 = {a = 3; c = 4}; > let o3 = o1 with o2; > > ``` 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? ---
**Author:** ![rossberg](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/rossberg/32/795_2.png) [@rossberg](https://forum.dfinity.org/u/rossberg)\ **Post date:** [December 18, 2021, 8:33am UTC](https://forum.dfinity.org/t/motoko-design-evolution/9761/3 "2021-12-18T08:33:17Z")
> 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. ---
**Author:** ![cyberowl](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/cyberowl/32/3635_2.png) [@cyberowl](https://forum.dfinity.org/u/cyberowl)\ **Post date:** [December 19, 2021, 3:01am UTC](https://forum.dfinity.org/t/motoko-design-evolution/9761/4 "2021-12-19T03:01:44Z")
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. ---
**Author:** ![jzxchiang](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/jzxchiang/32/2592_2.png) [@jzxchiang](https://forum.dfinity.org/u/jzxchiang)\ **Post date:** [December 19, 2021, 8:08am UTC](https://forum.dfinity.org/t/motoko-design-evolution/9761/5 "2021-12-19T08:08:36Z")
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… Thanks! ---
**Author:** ![rossberg](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/rossberg/32/795_2.png) [@rossberg](https://forum.dfinity.org/u/rossberg)\ **Post date:** [December 19, 2021, 10:55am UTC](https://forum.dfinity.org/t/motoko-design-evolution/9761/6 "2021-12-19T10:55:59Z")
@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). ---
**Author:** ![rossberg](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/rossberg/32/795_2.png) [@rossberg](https://forum.dfinity.org/u/rossberg)\ **Post date:** [December 19, 2021, 10:59am UTC](https://forum.dfinity.org/t/motoko-design-evolution/9761/7 "2021-12-19T10:59:58Z")
@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. ---
**Author:** ![claudio](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/claudio/32/322_2.png) [@claudio](https://forum.dfinity.org/u/claudio)\ **Post date:** [December 19, 2021, 5:32pm UTC](https://forum.dfinity.org/t/motoko-design-evolution/9761/8 "2021-12-19T17:32:53Z")
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. ---
**Author:** ![dsickles](https://avatars.discourse-cdn.com/v4/letter/d/71c47a/32.png) [@dsickles](https://forum.dfinity.org/u/dsickles)\ **Post date:** [December 22, 2021, 5:06pm UTC](https://forum.dfinity.org/t/motoko-design-evolution/9761/9 "2021-12-22T17:06:39Z")
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.