FEATURE IDEA DISCUSSION: Smart Contract Multi-language support

[kcelestinomaria]

Wouldn't it be great if you also considered other languages, tools, and frameworks in the kit, that are used across the Algorand developer ecosystem, i.e Beaker, Reach DSL, Tealish, Milkomeda Wrapped Contracts etc.

Is this part of your roadmap in anyway? I think it would be great especially for backward compatibility in projects that may have used one language in one dAPP they worked on, and now they are shifting to incorporating algokit in their workflow.

While from our own dev experience as an Algorand project we really never liked the multi-language nature of ALGO(this makes ALGO less appealing for developers coming from other networks e.g ETH), it is something we all cannot escape because it has already happened and for many developers, as a case, Reach Lang still stands out for them because of its low audit costs and most used by bootstrapped startups, solo devs, small businesses, and global developer communities, PyTeal/Teal is great for low-level work and used mainly by corporates, internal Algorand Inc. & Foundation teams, and researchers as far as I can judge... so, all still have their place in the developer ecosystem, and it would be a good idea to include all options(languages) as well.

Hope you consider this for the better of the Algorand ecosystem as a whole. Thanks!

@achidlow @robdmoore @johnalanwoods @joe-p

[johnalanwoods]

Hey, absolutely, additional languages are in the roadmap. AlgoKit is agnostic.

[Loedn]

Hi @kcelestinomaria, actually with AlgoKit we champion beaker and therefore it comes pre-loaded with a beaker template by default!
Templates are a way for other languages to easily integrate with AlgoKit's functionalities and the repos are open source so each project you mentioned can easily develop a template for it.
PyTeal with Beaker is really good, especially with beaker v1 that is coming real soon 👀
We're currently working really hard for towards algokit v1 release and have a pretty stacked roadmap for the entire year (did anybody say front-end?)

[robdmoore]

Beaker is our default and we are really invested in creating a top class, slick development experience for it, but as per the AlgoKit principles we have built AlgoKit to be modular so that the community can also use it with other tools. In particular, the way we have designed init templates in AlgoKit would allow the community to create (e.g.) tealish et. al. templates and use them with algokit :)

[emanuel]

Hi everybody, Thanks @kcelestinomaria for bringing this up! While the foundation is promoting PyTeal and Beaker, which is totally fine. A lot of developers we've tried teaching PyTeal think that PyTeal's hybrid nature (not just python and not just teal) make it difficult for newcomers to approach PyTeal without knowing TEAL you don't really understand what is Python and what is Teal making the barrier to entry higher that if you learn a more explicit programming language. TEAL is not a bad programming language but no one wants to write assembler level code nowadays and make the job of the compiler.

We think that Tealish right now is a better option for those who want to access the full potential of the AVM and be able to write on a slightly higher level programming language (and in the process learn TEAL at the same time).

On our project, Dharma Network, we've started with Reach but have now fully adopted Tealish. We would love to see support for it in the AlgoKit. We need to strive for programmer happiness so please don't leave tealish out !

Having multiple language options would make the Algorand ecosystem more accessible and diverse, allowing developers to choose the language that best suits their project.

[kcelestinomaria]

Thanks for the clarification, however, please accept one more inquiry, that comes from a struggle within the team I work with.

So, the smart contract development process, especially for high-value DeFi/Open-Finance applications needs security audits, in many cases even 1 or 3 rounds. For NFT apps and the rest, not so much needed, as these other apps don't hold money on-chain.

Everyone is enthusiastic about algokit, but, how exactly will it solve this problem of expensive security audits. I hate to burst our bubbles here, but, audits are not cheap, and for 2 programs we wrote in our team, it went for 24,000$ ( 22,000 $ - negotiated price ) , that's just too much , at least for most teams and is a barrier for everyone and anyone who wants to quickly develop a DeFi app, build and deploy, even an MVP. Reach is an EVM/Algorand DSL, and claimed to solve security audit costs using formal verification, it has not achieved that 100% as formal verifications only helps with tokens not getting lock-in to contracts. Reach contracts, are therefore equally in need of audits if you write them, so, how will algokit & beaker included, solve this issue. One thing that contributes to contract errors is how hard it is to writing/reading or understanding a contract, most errors are developer-caused, unless of course you are a developer from NK and already had bad intentions beforehand.

It would be a good idea to cover this with algokit. I have seen on the docs, that audited/standardized contracts will be possible, curious how this is going to be achieved, a self-auditing toolkit will be available, right? Humbly request your consideration to this question to help us in our painful developer journey across Algorand figuring out the right tools to trust and develop with.

Thanks.

cc : @johnalanwoods @Loedn @robdmoore

[kcelestinomaria]

On the above, I think that, the first audited/pre-standardized contracts we can start with, would be Smart Contract Vaults in TEAL, it would kill more than two birds with one stone.

Why? Vaults are the most common smart contracts for De-Fi apps, just looking out there shows it all:

1. Algo Governance Apps use Vaults e.g AlgoFi Vault
2. Option/Futures Contracts use Vaults e.g Option Vaults on AlgoRAI Finance
3. Stablecoin Contracts use Vaults e.g Gard Vault, xBackend Vault
4. Sythetics Contracts also use Vaults(to lock in a token and mint new tokens)
5. Lending contracts use Vaults e.g Folks Finance

So, Vaults, would be the best option to work on using audited/standardized contracts.

Thanks.

cc: @johnalanwoods @Loedn @robdmoore

Thanks.

cc: @ johnalanwoods @ Loedn @ robdmoore

@kcelestinomaria hi there, and ty for your feedback. Please note that as a general (generally on github/other issue-trackers) rule:

• do not use ALL CAPS IN TITLES ETC.
• do not ping / cc too much and repetitive (devs/interested parties observe the issues anyways)

[kcelestinomaria]

Ok, no worries, but shouldn't there be public turnaround times for the same, because that is the reason there is always an urge to ping/cc, without turnaround times you never know when an issue will be picked up, who would pick it up, or if it will ever be picked up at all @abebeos . For Caps, just used general English grammar rules for titles, as well as to show urgency, sincerely no bad intentions. Do caps bring any issues? If there is a better way or a public standard also, then there won't be such issues.
Another thing is to create a standard that helps differentiate an issue that needs a response and one that's just for viewing, that will help as well.
Thanks!

shouldn't there be public turnaround times for the same

Yes, there should. But it is not common in Open Source Projects.

Usually only commercial projects have SLAs (Service Level Agreements, that assure Users/Clients response-times).

Do caps bring any issues?

Just lookup "ALL CAPS, basic netiquette"

Another thing is to create a standard that helps differentiate an issue that needs a response

You can start your issues titles with a [CRITICAL] tag. Just be aware that if you use it too much, then people will start to ignore it (as any other emphasis).

Then there is discord, see https://github.com/algorandfoundation/algokit-cli#learn, which can give sometimes faster/more responses than one can handle. Possibly give it a try.

[kcelestinomaria]

Gotcha on the Caps, sincerely didn't know that., you don't really get that netiquette notice anywhere, learnt it first from you.

Also forgive my skepticism, been building on Algorand for like a year and a half, and most times we would push issues and they won't be picked up at all, so you can see the confusion + despair someone would have on how things actually work or get successfully pushed, actually, it was a surprise for me that issues we recently pushed here got picked up let alone get a response, so probably things are getting better, right?

Also, for Discord, you can't really track up an issue in history. We use Discord all the time by the way, and even have our own Discord. And no one wants DMs because crypto shillers & scammers misuse them. Communication shouldn't be exhausting. I think the discussions tag should work though, I mean Reach.sh community used it and it was very effective, also the founders and leading teams weren't shy of DMs, which is why they built a strong developer community, Algokit can pick ideas from there, cause you can't share everything on public channels, not everything can be consumed from the public channel.

Also forgive my skepticism,

Nah, all good. AlgorandFoundations issue-tracking mentality is not the best (see e.g. algorand/go-algorand#5240), but then, let's hope that things will become better here in this repo/project (which is a quasi-end-users/builders facing one).

Btw: we are violating basic issue-tracking protocol: too much sub-issues/off-topics. This stuff usually gets lost.

---

@ maintainers: this issue should be moved over to discussions.ideas (https://github.com/algorandfoundation/algokit-cli/discussions/categories/ideas).