EOSIO Developments Series #4 - EverythingEOS Panel Review
While we can't yet dive inside the super-secret Block.one GitHub repositories, to learn more about the long-awaited financial product and other secret developments, we can view the ongoing public improvement of eosio and envisage future capabilities.Â
In this eosio developments series #4, I take a deep dive into the recent panel discussions on the longest-running EOS Podcast EverythingEOS. I’ll take a look at the concepts from my own experience working with and creating products on eosio.
Zack Gall, from EverythingEOS, recently held a development panel with some of EOS & eosio's most knowledgable, well-known and respected community influencers.
source:
- Bart Wyatt - Block.one, VP of Blockchain EngineeringÂ
- Tal Muskal - LiquidApps.io, Co-Founder and CTOÂ
- Raman Bindlish - BlockstartVentures.com, Managing PartnerÂ
- Syed Jafri - ProtonChain.com, VP of Blockchain / Founder, Bloks.io
Zack kicked off the discussion by addressing Dan Larimer's sudden and now infamous departure from Block.one. Dan's resignation letter provided little information about the decision. Dan provided more clarity in the follow-ups on his blog. Bart wished Dan well but couldn't offer any further explanation.Â
The panel then moved onto a hypothetical question of what each would do if Block.one hired them to fill Dan's seat as the CTO of eosio.Â
Much of the conversation focused on building community and bringing developers to the eosio ecosystem. Syed raised several points, which, in my view, would be extremely beneficial to decentralised app developers. I formed a similar position while running a team that was building on the eosio open-source software.Â
When I began working with eosio technology, I would answer many questions, ranging from simple to complex. However, the most common question which stood out related to the programming language used to build and generate eosio smart contracts?Â
Merely referring to C++ would prompt and initiate a whole host of questions. Ultimately, developers asked why C++? Why is this the only supported option? Can we use something else? C++ isn't as common as it once was, or we're familiar with other languages. Can we use them? Â
Syed struck the nail flush on its head. The modern enterprise focuses on digital and web-based services. Many businesses skew the majority of developers towards frontend products, leaving backends in situ for years, even decades, with minimal change.
Domain-specific technologies like Javascript, TypeScript or abstracted languages and frameworks are now the foundation of many Enterprise IT environments. In my experience, Syed's analysis was spot-on and correct. C++, while powerful, turns away many digital developers. Should the eosio community rectify this situation and build a bridge between the technologies, it would open up eosio to a significant number of currently under-represented devs in the crypto-verse.Â
Another aspect raised during the conversation was composability. During our proof of concept development, my team found the async nature of contracts confusing and complicated. Workarounds are possible as eosio is extremely capable, but optionality would be beneficial. I think it’s worth more discussion.
During the discussion, the subject of roadmaps and open development was a common theme among all panellists. A comparison was made between the React Framework, created by Facebook, and Block.one's approach via the Strategic Vision. It was primarily agreed and perhaps even conceded that B1 has not done a great job in communicating the roadmap in a way that fosters community engagement and participation. Tal pointed out B1 code got dissected by the community immediately upon release and Block.one may better serve community developers by releasing more frequently, with slightly less polish. I strongly agree; any insight B1 can offer around developing apps on eosio, even if buried in open-source code, would help builders, form some relative standards.
For example, I worked on a project to build a custom AMQP style connector service for eosio. Only now to find B1 has written an eosio plugin that effectively deprecates the need for something external. Knowing in advance would have improved our delivery and resulted in less wasted effort. There are numerous stories like these in the eosio community.
Finally, the discussion considered the possibility of the Ethereum Virtual Machine (EVM) being the ultimate winner of the blockchain contract execution environments. Proposed was that EVM has won the war, and eosio chains could conform to EVM as a standard. While I agree, enabling a simple migration from Solidity to an eosio smart contract would be interesting, it would not be one of my priorities.Â
Eosio should continue to forge its unique value for its developers and users via EOSVM. Enterprise application developers care little for the hypervisor running in the data centre or the cloud, and not once during my projects was someone concerned about the divergence away from EVM. People aim to solve problems and work with technologies that fix their issues, reduce the time spent and allow them to go home on time each day.
Not all feedback was positive. @RUDEMUDCRAB on Twitter argued Wyatt provided few clear answers and didn't add much to the conversation.Â
Everyone in the EOS community knows Block.one is controlled and, in many cases, cryptic when it comes to their public message. Whether this is to avoid the potential wrath of regulators or an effort to keep a lid on expectations is currently unknown.Â
Eosio is a fantastic technology, but as history shows, a fantastic technology does not always prevail. Listening to the community of developers and users is what keeps technologies in the running for large scale adoption and widespread usage.Â
Learn how to earn…
Become part of our community.
Telegram - Discord - Facebook Group
Follow our socials.
Subscribe to our podcast.
YouTube - iTunes / Apple - Spotify
Subscribe to this publication.
It’s free (for now)