Tezos breaks a record in the rate of how things become deprecated so quickly

The title is not from me but a quote from a user in a recent conversation about Tezos. Down are other quotes from participants that share similar thoughts like the quote in the title. I have mixed feelings and somehow this sounds a bit true? What are your thoughts about that? One prominent example in the conversation was Truffle, they got annoyed by too many upgrades and left - is that true?

it makes me wonder about the whole self amending concept and how scalable it is when the ecosystem is supposed to grow and adapt itself to these rapid ongoing changes

i had 2 simple private dapps that i abandoned just due to ithaca, which made them totally obsolete + me not having enough time/resources to refactor it all over again

one of the numerous reasons i stopped wanting to run Endless Ways was dealing with fallout from Tezos network upgrades

tezos upgrade cycles are exhausting and, like Joe said above, getting bummed and abandoning projects is a very real risk

It’s still in progress, unfortunately. We’re postponing many features due to too often protocol updates which have a lot of breaking changes, especially Tenderbake.

1 Like

Who is this quote from specifically and can you link to the original post? I think that would be helpful for context.

The ability to innovate quickly can certainly become a hindrance to adoption when that innovation leads to breaking changes.

It would be good if we could poll the community to see how breaking changes have affected delivery teams.

3 Likes

I don’t know what kind of discussion you want us to have. Shall we talk about the Ithaca upgrade in particular (and discuss how things could have been done differently to avoid breaking stuff) or about our culture of deprecation in general?

1 Like

That happened in this chat Telegram: Contact @chinstrap_io - some users were discussing the upgrades and tools that dont work due to upgrades. You can look at the conversation. I think its a good idea about the poll to see how it affects teams.

rafoo both your proposals for discussion are great topics. Could be a great discussion with new insights for outsiders that think the way I presented in the opening message or for everyone in general

I’m not saying I agree with 100% of the above quotes, some of it may also depend on what area you are working in, but I do at least agree with elements of it. Had a similar discussion on Reddit recently asking about hackathons for developer tooling.

On the one hand, its great to see so much effort and research being put in to keep the blockchain tech top tier, and making sure we have the right pieces in place to scale. We’ve shown the world that we can upgrade huge chunks of the chain, and bring in massive new features / changes.

On the other, its frustrating to see new feature + new feature + new feature coming from the core team, while such critical stuff like local forging, michelson SDK’s, wallet creation, encryption, formatting, hashing etc is left up to the community to build from scratch over and over again in different languages.

A post from nomadic went out a few weeks back, talking about all the new layer 2 stuff that will be added in coming protocols. Don’t get me wrong, that all sounds very cool and super useful … but do we need it right now? is increasing the scalability such a massive priority that it needs to be all hands on deck? Personally I don’t think so. I’m writing Swift code for Tezos at the minute and I have to rely on Trust Wallets open source library (which is massive, and incompatible with MacOS for writing desktop apps) in order to create private keys and wallets. I spent days researching how to convert a module of Taquito into something that I could put into an iOS JSContext, so that I can perform local forging. Not only am I hoping that a third party team have duplicated the client code for local forging perfectly, i’m also hoping they maintain it, and I have to manually check for updates and pull them down because its not compatible with my code in its current form. Running through JS also comes with a noticeable performance hit.

I firmly believe the core teams taking a break, and making some of the internals of the client/node available as standalone modules (in C, C++, Rust etc) that all languages can import, is a far more important task than some of the current ongoing upgrades. Dealing with Tezos means dealing with a lot of highly custom, bespoke or advanced topics. I’m not a cryptography guy, I don’t have a degree in computational linguistics or high performance programming. I come form a much more simplistic, higher level / frontend / UI+UX, style of background. Having to spend weeks and months digging through all this stuff is a massive burden. When the Edo protocol was announced that it would be making changes to Michelson, that was extremely costly to teams. There was no tooling or SDK’s provided, only written documentation and example contracts on testnet. Every team had to stop what they were doing and research this new topic and test the hell out of it.

The developer community needs the experts that are building all these core critical features, to make them available, ensure they are maintained, and updated before any proposal is injected. Too much is being expected of the developer community. It feels like the core teams are too focused on the Research aspects of development, and less so on the more production side of things

6 Likes

+1. there were a number of reasons why we shut down Endless Ways and one was, in the three months i was single handedly building the tech stack there were two protocol upgrades that meant i had to either re-engineer parts of my code or fix the indexer, and each of these tasks took a couple of days of work.

the recent change to Ithaca broke the way archive nodes worked, which took my indexer down for a week, and i had to completely re-engineer the front-end to talk directly (and slowly) to the blockchain.

looking forward, just the task of keeping the indexer up to date and running - and taping together fixes when things break unpredictably - was an exhausting prospect. maybe it’s fine if you have a 5 person dev team. but i was working alone, and it was already too much even before we’d made it into full-speed public access mode.

1 Like