So much to keep up with crypto, it's easy to miss shit. For anyone still holding Cardano, check out the MELD year-end update below. Keep in mind they been working with Plutus backedn since March 2021. They ain't some random FUDers. Apparently, folks don't even want to work on that shit.
Basically, what MELD is saying lines up perfectly with what Cardano detractors been saying about the smart contract launch and contradicts Charles. This seems like the most truthful breakdown of Cardano that people going to get.
2021 Rewind
meld-labs.github.io
For now, MELD started as a Cardano project and is
determined to stay so in the foreseeable future. Early platforms take time to mature so we have to practice patience more than expected. Nevertheless, as eager developers, we did enjoy the daily challenges. We also prefer to develop from principles and treat products as profound works. As such, being early in Cardano allows us to stay closer to the core progress of the ecosystem itself.
We have to confront the truth that developing on Cardano, or any young ecosystem for the matter, is brutal. Cardano possesses further challenges given its not-very-industry-friendly technical stack. It is sometimes challenging to get the right things up, even for experienced Haskell and Nix engineers. It gets way worse for our interns and newcomers to the ecosystem. The relatively high system requirements and lack of documentation do not help either. A few detailed pain points can be found in
input-output-hk/plutus-apps#180 Plutus on Hackage/Stackage.
As an ambitious R&D-driven effort, we have to recruit and train many engineers to work in the Cardano ecosystem.
A few brilliants have refused to join or given up so far. While we cannot tell the exact reasons, we believe it would be easier to convince them if the developer experience was better, i.e., to help them feel more productive with their time and talents. After all, there are still many good opportunities outside of MELD and Cardano for these bright minds.
Cardano currently has a tight transaction size limit, and for good reasons. However, this limitation makes it hard for dApps to include many scripts in a single transaction for composability and clarity.
We have faced many challenges representing complex application logic within the current limit and had to resort to hacky or semi-trustful designs at times. The aftereffect is that dApp development is very inefficient and error-prone. Sometimes we feel like spending most of the time reasoning about security properties, contract architectures on UTxO, ad-hoc script size optimizations instead of working on actual application logic. It is not the end of the world, but an apparent overhead when expanding dApp functionalities and inviting more builders to Cardano.
www.bloombergquint.com
www.marketcapof.com
Should I buy bitcoin @ 70kNice. How are the transaction fees on Luna? Are they similar to SOL and AVAX?
www.wsj.com
