What's brewing in Motoko

Developers Motoko
1

There are a few developments in the half-finished to under-review categories for new Motoko features. You can find them under Pull requests · caffeinelabs/motoko · GitHub .

It would help the development team to get a feeling for which of the proposed features there is demand/interest if you could give a quick look and voice your opinion here. I get that most Motoko code nowadays is written by Caffeine, but I am specifically interested in hearing from meatbrains this time…

2

As you know by know, the community didn’t like Caffeine taking over Motoko for several reasons, so not sure if any

still exists that would help out. Anyways best of luck .

3

They do exist, I can assure you. Let me drop here the other channel where I have reached out

4

Let me tag @Seb . plus the req chars.

5

You can deep 6 feat: opt-in non-Candid wire format via `encoder` / `decoder` parenthetical by ggreif · Pull Request #5996 · caffeinelabs/motoko · GitHub and never mention it again. Thanks. :laughing: If we start having all canister on the IC speaking different languages then were even more cooked than we already are. Why did taggr and openChat never take off? I’m almost 100% sure it had at least something to do with not being candid compliant. Everytime I went to integrate something it was a non-starter.

I’m not sure I follow experiment: add do #lab variant blocks and / # narrowing operator by crusso · Pull Request #5987 · caffeinelabs/motoko · GitHub but it sounds like a do? loop that returns a particular variant or a null?..or something..that could be interesting.

I would love a debug {} but for other things. I have a particular project where the canister/module operates in modeA and modeB and for modeB I have some extra things that need to happen…I’d love to wrap them in modeB {}; and then not have them compiled for particular compiler switches.

This is the most important one for me: feat: support fixed-width Nat types as array and blob indices by q-uint · Pull Request #5929 · caffeinelabs/motoko · GitHub … along with possibly adding a nat256 that would just drastically simplify a bunch of math I have to do.

6

This is similar to do ? but you can choose from a variant which one of the legs should play the rôle of null. ! would short-circuit that one, and unpack the other. The prime example would be Result.

7

I just want Motoko to have a self-hosting compiler

skilesare 8

Leonardo Di Caprio Look GIF by Once Upon A Time In Hollywood

9

Two possible interpretations
a) onchain
b) bootstrapped
Or possibly something else?

10

(b) , well on-chain compiler would also be useful.
I mean Motoko compiler being written in Motoko.
It’s not really something we can’t live without, but if it’s doable, would be valuable.

11

@ggreif from the ones in the list → https://github.com/caffeinelabs/motoko/pull/5334
I would like it even more if works well with Motoko’s first-class modules. If canisters/users can communicate and send each other WASM components they can run.

12

i like motko because rust is hard

13

This one is a bit on hold, as it necessitates replica changes. The Motoko team is just one player. But it is definitely on the wishlist.

14

I have just released Release 1.8.0 · caffeinelabs/motoko · GitHub , this has the and-patterns feature!

15

Some of the useful properties/use cases I think will come out of this (with a lot of guessing) based on the problems encountered so far:

  1. Motoko becomes a great secure high-level protocol/orchestration business logic language, where it can use modules (WASM components) written in Rust, Go, Python, etc., giving it access to their ecosystem libraries, optimized with direct memory access.
  2. Motoko becomes something like the EVM, where we use it to write the framework, and contracts are hot-pluggable modules that can be developed in any WASM language. These contracts can be stored as bytes in an app chain like ICRC-3. This would allow clients - other canisters, off-chain clients, browser clients - to walk through blocks and sync their state once they have the exact deterministic contracts referenced in those same blocks, which they can also execute locally.Canister clients shouldn’t need upgrades to fetch and run these modules, allowing many canisters to maintain replicated state following leader through contract upgrades automatically. A single component plugged into the main canister producing the blocks should be able to propagate across the entire client network so everyone can replicate state perfectly.
  3. Customizable systems where clients write their code with AI through graphical interfaces, compile it into modules, and install them into a hub canister where they run alongside other client modules. Something similar to what neutrinite.io does with vectors/crypto bots, but far more customizable.
  4. Motoko canisters acting like an OS kernel. One user = one canister, with users installing safely third party apps as hot-pluggable modules - hopefully with functions that work without await.

I think that’s where this is heading. It feels like it was the intention when Motoko was created and if I’m seeing it correctly, it’s going to be amazing!

16

I tend to think 1 is irrelevant now. Is the library missing? Build it and publish to mops to enhance the ecosystem. I fear the interop/serialization/deserialization layer will become burdensome for any libraries that need efficiencies and we are already battling 5x costs from a year ago…better to take it in the chin and build an optimized native motoko library if you need it so we finally get somewhere and identify the most necessary optimization points in the library.

17

yes, probably not worth it for small libs now that you can make them, I was thinking about more like - vector database (for RaG). I made one in Motoko, but there are a lot of array allocations and gc work.

18

Did some searching around that:
overhead: FFI boundary cost, memory copies, adapter trampolines, layout conversion
what it`s not doing is things like: Candid encode, protobuf encode, full parser
potentially expensive: large nested structures, many tiny calls, cross-component chatter, large string copies
the recommendation: Design components as: coarse-grained service boundaries. not: tiny object-method boundaries.

Let’s say I want to use (Icydb + schema + some actions) from Rust in Motoko as component. The component has its own memory. What will go through that boundary for some actions will be for example setUserFlag(233,2323) → Ok while the machinery inside could be having quite a lot of logic and db queries.

19

You should look into the pure libraries like pureList and champMap. They are much more efficient at making copies of things and letting GC be eventual. Once I get all this next stuff published I’ll try to write an article about it.

20

Yes…it is the scalability that gets you. It is all well and good to say “maintain a thick boundary”, but your first user will decide the best thing to do is build a real time p2p network on top of it and suddenly all the love and care you put into something is now “shitty” :sob:

Jordan spent 3 years trying get azle to work when people told him it wasn’t going to fly the first week. Maybe if people had just done canister-y things with it but every one wanted it to be node.js.