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
