Good discussions here, I appreciate it. I don’t have strong opinion on Gaia’s roadmap and will stay neutral on the question if CosmWasm is valuable to the Hub or not.
On the technical side of things, Confio is committed eliminate or mitigate roadblockers in case they still exist. 2 years ago, Terra started to hit hard on the software in a large scale deployment. A few smaller bugs such as memory leaks were found and fixed. Dozens of chains joined the party. Ongoing development made the software better every month since then.
As Jacob is not getting tired of writing a lot of text arguing against the use of cgo, please note that I (the person working full time on this software for more than 3 years) disagree with it. Some brief thoughts here:
- C interfaces (FFI) are a standard way to link various software components together. It works well for decades across a variety of languages. It comes with some cost wrt. maintenance but is also not scary by itself. Being able to reuse software adds value. While it might not be Go best practice, it certainly is Linux best practice.
- We developed mature ways to efficiently transfer binary data over that interface, which in many cases does not even require a copy of that data. The hard part here is explicit ownership-based memory management vs. garbage collection, not FFI itself.
- We don’t need other data types than binary data and simple types (like uint64 and basic structs).
- There is no evidence that the performance hit by cgo has any relevance for this use case. The number I can find are in the nanoseconds, which is negligible compared to the time it takes to start a contract (~50 microseconds) or the time it takes to write to storage.
- Apart from now fixed memory leaks, I have not seens any evidence that CosmWasm has a negative impact on memory usage. It has a configurable in-memory cache, yes. Maybe this is why it uses a few hundred MB of memory depending on the configuration.
- I don’t have the numbers at hand, but there is a common educated guess in the ecosystem that read+write access to the IAVL store is the performance bottleneck of Cosmos chains, not the compute part. This store is used exactly the same way by Go modules and CosmWasm contracts.
- The use of a shared library can be avoided with static linking or tools like nix. But then again there is nothing wrong with shared libraries other than a bit of deployment work.
- Most importantly: in contrast to many other parts of the stack, cgo never caused any issues. It just works as it is supposed to do.
It is easy to confuse actual usage and a certain technology choice for load on the node. CosmWasm encouages the use of a chain, maybe makes accessing storage too easy. But then it is rich feature sets that cause the load.
I wish I would not have to defend a technological choice without seeing full stack performance or memory usage benchmarks. But I also don’t want a certain believe be understood as if it was a fact. I think Confio can find some time later this year to write a detailed analysis about our cgo usage.
That being said, back to business. The important question is features and roadmap. Tech will follow.