160 ICP!
Since #3 and #4 are connected I’m going to release them together. I also adjusted the scale a bit to make it easier to get through the list. I still have the 80k at the top, but I would really love to do an ICCon in Austin. We need a hell of a benefactor though.
#3 Dfinity should mirror all system canisters with motoko reference implementation. If libraries are missing that would enable this they should build or fund the building of them.
This will drive dev growth and the ability to develop a broader group to review system canisters changes
Rust is apparently a great language. It also has memory management at its core and as a result, it is not going to take the world by storm. Not having a higher-level language that is performant and easy to start programming with will continue to be a hindrance to IC development. It will limit IC development to only the most skilled and most dedicated developers.
You Rust guys/girls are AWESOME, but there are not enough of you.
Tech like Demergent lab’s Azel and Kybra are great gateway drugs and we should find ways to promote and fund them. They get people into the IC and help them understand the concepts. There is likely a large chunk of the IC that can be built on those pieces of tech by your ‘more average’ dev, but at their core, they require running a virtual machine that limits their performance.
Since Motoko currently compiles straight to Wasm it has the ability to be as or more performant than rust. With deterministic time slicing and new garbage collection, it can be very competitive especially given the mental capacity advantage it has over rust.
Encouraging DFINITY to dog food motoko will make it a much stronger language. Recent examples like the BTC team forcing the growth of memory when actually trying to write a canister show the advantages of attempting to use your own language.
#4 Motoko should be generalized for other wasm platforms like filecoin’s vm.
Motoko does have a weakness in that it is an IC-only language. You have to be pretty sold out to the IC to commit to learning it and becoming an expert. An easy way to do this is to extend motoko beyond the IC.
Many new chains are using Wasm as an execution layer. These chains should be studied and we should apply motoko to those chains. We may need to lose some features like the async behavior that is specific to the IC, but many of the other features would map well to synchronous platforms. Many of the libraries we need built are synchronous and have other uses for them makes it more urgent to develop them.
It is also likely that those systems have asynchronous functionality that we can map to and help abstract asynchronous programming on those platforms.
I’d suggest starting with the filecoin VM as it is one of the biggest threats to the IC’s tech lead and bridging the devs focused there to the IC may be a way to maintain and demonstrate that tech advantage.