This thread is for high-level discussion about Motoko ecosystem gaps. For specific feature requests and library needs, contribute to the Motoko Wishlist 2025 thread.
The Gap
Motoko has strong fundamentals but struggles with production adoption. Most serious IC projects default to Rust, not because Motoko can’t handle the workload, but because the ecosystem isn’t mature enough yet.
Current state:
Most IC projects use Rust due to ecosystem maturity
Motoko lacks essential libraries/tooling for complex production apps
Developer adoption remains limited to experimentation/learning projects
What does Motoko need for it to become the default choice for IC development?
Essential missing libraries - What categories need immediate attention?
Language features - Core syntax and type system improvements needed
Production readiness - What defines “mature enough” for serious adoption?
Tools like Caffeine AI and upcoming WASM Components will help Motoko adoption, but Caffeine AI shouldn’t need to write everything from scratch. A mature ecosystem with robust libraries means AI tools can focus on composing existing solutions rather than reinventing basics.
For specific feature requests and library needs, please contribute to the IC Developer Feature/Library Wishlist thread - this is where we’re building a comprehensive reference for development priorities.
What’s your take on the current ecosystem gaps? What would move the needle for Motoko adoption in your projects?
I think on of the hard parts about this, even as a developer, is coming up with a list of specific libraries that are needed, because each project is different and requires different things. So it seems like a lot are required and maybe there is just a point where its saturated enough to be more broadly adopted.
I think frameworks could be easier to come up with a list of like i just made an HTTP framework Liminal that will make the process of handling HTTP requests much easier.
ORM framework also seems like a solid option.
But still I’m struggling to find specific ones that would be a game changer and have more Motoko adoption.
Also some of these libraries/frameworks are not really possible to do completely due to some current Motoko language feature limitations. Like I have done a serialization libraries, but without some sort of reflection-esque features, we can’t automatically convert from say JSON to motoko, without explicit methods for each conversion.
Any thoughts and conversation would be great because im not sure how to solve this
Tbh its all about the network effects. However since wasm components will allow you to choose any language while still benefiting from the whole ecosystem, that would also make it unnecessary to choose it instead of existing languages that also support the component model. Perhaps the strong integration with IC is a selling point if one is developing for the IC, however you could also perhaps achieve the same with existing languages with some basic tooling / libraries. so all in all, I think wasm components will be a huge boost, but there still needs to be some unique selling point to warrant the investment.
Can you elaborate on specifics, just to make sure im aware of all cases
there is a Json library now
But I think its a big issue that we cant say Json.deserialize<T>(json) in the Motoko language right now due to lack of reflection-esque features
@Lorimer I would be curious on your exact needs
I am actually starting work on a protobuf library for IPLD related things and im trying to figure out the minimum that would be helpful
I don’t plan on doing things like auto code generation, but at least basic parsing
Also could you point me to where the protobuf encoded data is on the IC. Would be a good way of testing
Looking at adoption from a differnet angle and I ask - What is Motoko’s use case outside of ICP? I believe more can be done to promote it as a general language and for other specific usage. Without expanding adoption into other areas of development i think Motoko will always be second class to Rust because Rust is used in many other areas of development. Don’t get me wrong, i do like Motoko but as a business you look at how many developers know Rust vs Motoko and the choice is clear. Just my two cents. Big love to DFINITY and the Motoko team
I think the fact that none of the protocol or application canisters managed by the NNS are written in Motoko is problematic for the language being taken seriously (it certainly doesn’t signal that it’s ready for serious projects).
If Motoko is the official language of the IC, there should be an initiative to migrate all protocol canisters to Motoko. Pain points will be discovered and they can be addressed as DFINITY go.
Agreed
I have talk to the team a few times about this but there really isn’t a great option that we have seen for WASM based blockchain or actor model environment to expand to
When the environments show up, hopefully there will be some movement
Filecoin FVM was supposed to have WASM support but im not sure if the project died or is just on hold
This has been my concern for a while and I wrote a thread about it a while ago but I get conflicted as a dev because the framing is Motoko is the future but at the same time Dfinity doesn’t give it the love because they only use Rust internally
Im not sure what can make that change
Im not sure if anything will change with Motoko support now with the release Caffeine AI and Enhanced Orthogonal Persistance, but I hope so
Thanks @Gekctek, are you able to share a reference to that thread?
@marc0olo, is this something you’re able to comment on, in terms of DFINITY’s perspective and plans regarding Motoko usage?
Will DFINITY ever switch to using Motoko as the primary IC language rather than rust?
I think there are a lot of advantages to having a dedicated language that can be made to prioritise what the IC needs, and also make it easier to develop on the IC. At the moment I think many things are actually harder using Motoko, precisely because it’s not the well trodden path.
Things like orthogonal persistence, build reproducibility, maybe even the ability to compile source code to WASM on-chain (facilitating dapp-based CI pipelines, and automated canister hash verification), are things that could make Motoko the go-to language.
Until DFINITY takes that leap though, I’m not sure why they would expect the community to. I want to make more use of Motoko. but I don’t see it as the path of least resistance - though I really want to.
Fun fact: there is actually one NNS canister written in Motoko: lifeline. From the readme:
The lifeline canister is written in Motoko and uses an alternative technology than the other NNS canisters that are written in Rust and use libraries from that ecosystem. This allows for some degree of “galvanic separation” of technologies, such that the risk of inheriting some kind of common flaw from the compiler (and/or libraries) is reduced.
(Not trying to take away from your point, it’s only ~100 lines of Motoko…)
Well you cannot serialize/deserialize types automatically. You have to manually implement serialiation/deserialization yourself. This is time consuming, error prone, and brittle - if you change the type it is easy to forget to change the ser/de.
Everything ran locally fine. I had the ICP index canister defined in dfx.json as a remote canister, pointing to the released did and wasm. I was using get_account_transactions with the subaccount in the account object defined as Blob. As mentioned, all runs fine locally.
As soon as I try to deploy I get the error that the type is expected to be [Nat8]. Not sure why this wasn’t a problem locally, given that the did I am referencing for the index canister also defines it as [Nat8]. Anyway, I’ve just made the changes locally to use [Nat8] instead of Blob (which seems to require clunky conversions that could just be implicit - Option.map<[Nat8], Blob>(acc.subaccount, Blob.fromArray)).
The trouble is I get the opposite error now locally than I was getting when trying to deploy. Locally the compiler wants Blob for that index canister call (despite the vec nat8 in the did I’m using). I’ve tried a clean rebuild. I suspect there’s something I’m missing that I’ll figure out shortly. This is no doubt an unnecessary paint point though.
I ran into something similar and it turns out there is a bug in the candid compiler/translator. I think @claudio was working on it.
From what I understand, Blob actually compacts much smaller in motoko than a [Nat8](because each value in an array has its own type header inside the memory). The advantage of [Nat8] was, of course, that you could get a part of the blob by index myBinaryData[35] which you can now do on a blob with myBlob.get(35). What we still don’t have(I don’t think) is a .put that would work on a var Blob. (This would be awesome if we had it and would make manipulating fixed-sized files much more efficient.)
So right now, If you are storing unchageing data(or data that you are fine reconstitutin later use Blob and save a ton of space. If you need to change your data often you may still need to use [var Nat8] and then freeze it to a blob before it is at rest.
@gabor and @claudio, please correct me where I’m wrong.
