The Future of Solidity: Core Solidity, Argot Collective, Plans & Roadmap

Transcript

It has been the most used smart contract language for a long time. So of course the community around it is also very strong and the [music] tooling is stronger as well. Right. It's meant to have better features for writing safe smart contracts [music] which I think is most important thing. I think that AI in smart contract development should be used. We have course coming up which [music] is a new initiative to make a different language that to some extent learns from some of the mistakes that were probably made in but I think we already now see that people are not writing code anymore. I think the most dangerous assumption [music] is to think that you can roll back systems like uh

>> [music] >> Welcome back to ecosystem project demo. This episode brought to you by EC Institute. Today we are going to talk about a programming language. [music] So if you have ever interacted with DI NFT, perhaps you have guessed what project [music] we are going to talk today. Yes, it's Solidity. Solidity is one of the programming languages uh that runs under the hood for most of the web3 application [music] and today we are joined by Jacob to share more about the project. Jacob is a member of solidity team under the Argot. For people who aren't aware is a nonprofit organization supporting projects for Ethereum

application. Welcome Jacob. >> Thank you very much. Happy to be here. Jacob, I noticed that uh there was an update today as well in Solidity. It was shared on Twitter and I understand this is like a very common practice for the project. >> Um yeah, the what we released today is a pre-release. So that's like a a way the projects can try out a new release before it's actually released. And this gives tooling and like other projects a chance to prepare for for new releases.

So for example, if you have something like hard hat or foundry, you give them a heads up so they have a little bit of time to adjust their tools to support the new version of Solidity. So what we did today is a is a pre-release and hopefully next week the real release will come out. >> That's wonderful. Well, over the next 30 minutes or so, we will be covering the language, the road map and exciting feature that it brings. But before we get into there, tell us about yourself. How do you find web 3? How did you join Ethereum ecosystem?

>> Yeah, sure. So, my story is quite long. Back in 2015, I was studying computer science and I was looking for a topic for my bachelor's degree and I stumbled upon Bitcoin and thought that was interesting and found a professor that was interested in advising me and he had actually just learned about Ethereum uh in early 2015. So he introduced us to that project and we thought it was super interesting and started yeah writing our bachelor thesis about it and after we did so we sent it to the Ethereum Foundation. It was not very big back then in 2015. It was not even on mainet yet. Um and got offered

an internship. So I started I did an internship in this fall of 2015 in Berlin for the FD office. um and worked on the Python client. So there used to exist an Ethereum Python client back then. So that's how I got into the space and then after my internship I joined a company for 7 years I think. We worked on things like Raiden Network which was like payment channels for Ethereum. We did a project called Trust Lines. We did Shter. Uh so a bunch of stuff and also at the same time I've been running the Copenhagen Ethereum meetup group and I'm part of the DoD department of decentralization that is doing different

events like E Berlin and Protocol Burke. So yeah, I've been around for a while by now and also still volunteer a good amount of my time for community and ecosystem things because I I do believe that it's it's important to give back and and volunteer some of your time. And I think it's also just part of my Scandinavian mentality. So I still do that. And yeah, then more recently I've worked at a company called Filax Systems that uh they do security tooling around smart contracts. And now I've just uh a little bit more than a month ago joined um Argo to work on Solidity mostly uh developer relations. So yeah, that's a little bit about my my story to keep it short and not go too much into details.

And that is pretty interesting story because you are one of the oldest people who have learned about Ethereum and kind of started interacting even before it was on mainet. There's a lot to learn from you and I look forward to learn more. I noticed that you shared about a solidity survey where you are collecting some data point from users. Maybe we could talk about that. And I noticed there was a ticket to Don which is a bonus. And for now, maybe we can just uh go ahead and get started with the presentation.

>> Yes, for sure. The survey we're closing it very soon, so it will still be available when the the podcast actually goes out, but yeah, we can still have a link to it, of course. And yeah, I'll uh start my presentation now. Um, just before I do, one thing I think is quite interesting to mention at this point already is how the like I' since I I wrote my first smart contract 10 years ago or more to now the tooling has developed a lot as well. It's been quite interesting to see how this whole scene has um developed over over these 10 years. Back then there was like basically like you almost didn't have anything like ether scan or just the basic tools like that. Uh so it has

really improved a lot over time and the same I can say is true for solidity as a language. It's quite different now than it than it used to be. All right. Yeah. So I'll talk about solidity and its past, present, and future to give you a little bit of a of an overview of where the the language is coming from, what's the current state of it, and also a bit about where the language is um is going. As already mentioned in the beginning, Solidity is the primary programming language of Ethereum. It has been so since the very early days. There used to be a couple of other languages in the early days. I'll mention a little bit later. Now there are a couple of alternatives as well but by far solidity

is the most predominant programming language for solidity and it yeah underpins more than or like around 200 billion in D5 alone which is a lot of money comparable to um I would say probably like uh different uh traditional banking systems stuff like that. So yeah, we with that much much money, we definitely need to have um high security as well. And this is one of the the challenges of course, but we can uh talk a little bit more about all of that later as well covering a 10-year-old programming language that holds this much money or like secures this much money. Um there's a lot of stuff to talk about, but yeah, to go a little bit back to the origins and uh

small history lesson, the the language was uh proposed back in August 2014, I believe. And the first public preview was done a couple of months later. And then in July 2015, they started tracking the versioning of the of the language. And for those who are more used to traditional programming languages, uh, Solidity is probably mostly influenced by C++, Python, and JavaScript. And if you know C++ and JavaScript, you also pretty easily can be familiar with the syntax of um, Solidity. As I mentioned back then there were a couple of other early programming languages. Uh one was a list-like language. Um and the other one was Serpent which uh was kind of a

predecessor to to what is now Viber. Back then there was also quite a lot of focus on making the language feel as familiar as possible because there weren't a lot of the big community and a lot of people developing in it. So it also was important that it was somewhat easy to move from what you knew to to this new uh language. Yeah. Then we have 10 years of evolution and I tried to just pin down a couple of the bigger points of improvement that we've seen. I don't want to go too much into detail with it but as you can see there's a long list of gradual improvements that have h happened over the years and uh we are still like over time with a lot of hacks. People often get have their like

D5 protocols have lost a lot of money and it's not necessarily it's not really because of the language but it is just difficult to write code in general that is without bugs and errors but it also means that the language of course is now focused more and more on being as secure and safe to write code in as possible. So this is something that shapes the language quite a lot. So as I said like safety and correctness gradually became the overriding design factor that shapes the language more and more and now we are at version 0.834 as I mentioned we just had pre-release earlier today for the for the next

version. We have quite frequent releases at the moment and very soon we will have one of the most requested annoyances fixed which is a stack too deep error. So that's coming soon. And we also have version 0.9 uh coming up which will have some breaking changes and that has already been mentioned for example in in our blog. So there's there's a decent amount of things going on with Solidity. Something else that has happened recently for the Solidity language is that it now has a new home in the Argo collective. you did mention this in the beginning and Argo is an independent nonprofit that was spun out of the Ethereum Foundation in 2015. So, it's

fairly new and it's the biggest spin out of uh the year so far. And we have a good amount of funding secured for for long-term stewardship of the language. And in Argo, we also have a bunch of other projects. So, I mentioned Solidity, we have FA, which is another EDM language. Uh then we have sourcify which is a kind of like source code verification tool. So you can go and like uh verify your source code there and you can like they have a big look up of different function signature stuff like it's actually a really cool tool that you can use for for many different things. Definitely check it out. Then f debug it's a debugging tool. ACT and HVM are both formal verification tools. So

we are working on a lot of different tools that play very well together and ultimately will make the developer experience of writing safe smart contracts better. Then I mentioned solidity and also we have core solidity coming up which is a new initiative to make a different language that to some extent learns from some of the mistakes that were probably made in classic solidity but also just like follows the natural uh evolution of programming languages. So yeah, 10 years of development and shifting needs for classics literally has created some technical depth. There's been a lot of uh new feature or some features included

that were not planned ahead or like planned early on which means that it feels a little bit like uh like these extensions that are ad hoc and it's uh making it harder and harder to reason about the correctness when you're introducing things like this. And also classic solidity is being used in many ways that was not necessarily envisioned early on like 10 years ago. Most people probably didn't envision that like that smart contracts would be used for all these kind of things that they are now and hold this much money. So the language has kind of had to adapt to how people wanted to use smart contracts instead of the other way around if if that makes sense. um and that just adds

complexity especially over time and it's difficult to safely extend the language now to meet user demands. So the solution to this is core solidity uh which is a rebuild of uh like a new language from the ground up but still using a lot of the same things you know from solidity but still with a lot of other features that will help you write safer smart contracts. So some of the new features uh that cause a lady adds I won't go too much into detail with them. It's not uh straightforward to explain what all of these uh things are and it's also maybe not the most interesting thing but to name a few we have algebraic data types and pattern matching which combined make uh it very

like you can represent invalid states in your smart contract and I think this combination will be extremely powerful that you can basically use these two these two concepts to make sure that you cannot by accident send the wrong amount of funds to an address or something like that. So basically this will will make it easier to to write safe smart contracts which is important. Then you have generics and polymorphism and traits type classes similar to what you have in rust or hasll. So this will be a little bit different from what we do now in where we use inheritance. Then we have high order functions and compile time evaluation. And then we will have a standard library in place. And this will

be community stewarded and we will work together with people power users from the ecosystem to define this so that it makes the most sense for everyone and also so that the most projects supported out of the box so that most features are supported out of the box. So the hope and the goal is to have a language that is let's say more up to-date with the needs of smart contracts in 2026 or later and that also utilizes some of the more modern programming languages features that have popped up or have matured over the last uh 10 years and a little bit on the road map. So I did talk a little bit about the future but

short term we have SSA cfg initial integration which is what the like the pre-release today is actually covering and then we have like course in syntax refinement comes on design and uh this is like for Q1 2026 and in Q2 we have uh the stack to deep error that I talked about that we'll be uh fixing. I think a lot of people would be quite happy about that. And when I was looking through a couple of the early responses in the solidity survey, uh this was still mentioned as one of the main pain points. So, it's uh it's definitely going to be nice to finally uh address and fix this one. People will uh be happy, I think. And yeah, then we're also starting work towards the 0.9

releases that I mentioned earlier that will have some breaking changes. Looking a little bit further ahead, then we will have a core line experimental release so people can actually start playing around with it. Uh, as well as we will start uh shaping the standard library with the community and we will have classic and core solidity coexist at the same time. So yeah, that's a little bit about our plans and I actually think that's where I'm stopping my presentation here to keep it fairly high level and not dive too much into anything. Um but I'm sure you also have some good follow-up questions on on some of these um things that we can then discuss a bit.

>> Absolutely. And thank you. This was wonderful. This was a very good highle overview which was required for the kind of listeners we have. We have both set of listeners who are fairly new and people who are expert. So this provides a very good overview of people who are relatively new. You talked about having over $200 billion industry supported. You talked about uh the evolution and I also remember there is a road map half a year road map that was published. So perhaps we can add the link in our description for people who want to follow more about it.

>> Yes, for sure. I'll definitely uh do that. They can also find the blog post easily if they follow the the link I showed for for Argo. But I'll I'll have a link uh list. >> Right. So uh solidity as on date is over 10 years and for someone who has been either watching from the sidelines or are relatively new want to enter into this um programming world what would be the one thing that about writing solidity today can be genuinely surprising for them if they compare solidity with any other language. So I think if we compare with any let's say non-s smart contract language then I think something like the constraint of gas. So we have in ethereum we have this

concept of gas which is like a representation of the price that each each computation has and this means that you have constraints to how much compute or how many computations your code can actually do. So this is something people are definitely not used to these days to think about the resource management and writing uh efficient code. So this is something that you have to to keep in mind when you start writing uh smart contracts of any language but it is uh probably one of the biggest surprises and things that people have to get used to.

>> In the presentation it was mentioned that there are a couple of other smart contract languages that have evolved over a period of time. If you have to compare it with them, would there be any significant difference? >> I mean there are some differences. Of course, the syntax is is fairly different then in VIP for example I think one of the bigger things they have is the I have to be careful not to mix it up but I think they don't have the issue with the stack too deep error for example because they do everything in memory uh which is like a small detail like can matter to some people. So under the hood like the languages are quite different but they compile to the same back end. So I guess it's about what you

prefer. >> Of course preference is good here. >> Exactly. We also have for like in in Argo I mentioned we have Fay which is another smart contract language which also it's quite uh similar to Rust. you know, Rust, you'll feel quite at home quite quickly in Fay. Um, which is also seeing a lot of uh development at the moment. So, I think I think Fay is also going to be quite interesting for a lot of people to check out. >> That's good to know. We received a question on Twitter about the cast optimization. You did mention that for a developer who is transitioning from web 2 to web3 world one of the important constraint is gas that is not considered

in web two project but it is very important and significant in web 3. I suppose the user is interested in learning about the road map of solidity and the testing plans of gas testing if that is there on the road map maybe if you could expand a little bit more about that. So, so yeah. So, gas optimization is like I think that's I mean a lot of things that's about gas optimization, right? But I think there's like a balance between optimizing and readable code and it's always that balance that you have and I would always say that you should write readable and secure code over optimized or fully optimiz gas optimized code. So yeah, it's a choice

that you have to make. And if you want to write really gas optimized code, then you're writing it in inline assembly, which is not as easy to read for most people. So I think I think that's like how it will be in in most cases. Luckily at the moment, gas is quite uh cheap on Ethereum also on mainet. And then I think in the core for gas, we will have the same constraints, but the standard library might be something that will see a lot of optimization. So maybe some of the more like used functionality that we have now will be cheaper in cognit than it is in classic LED but it's it's still very early days so I really can't say.

>> So my understanding is like if this kind of gas optimization we are looking at it should be coming up with certain kind of proposals EIP and that can help like optimizing gas on contract writing level. So I don't know if the user wanted to maybe check on the Glamster proposals which are there for gas optimization. Has the team considered doing the testing for those proposals? >> We will definitely be doing it once it lands on on Ethereum, right? Like how it usually works, how it land when it lands in the protocol, how it usually works is that the the clients implement it, right? They they implement the spec and and they basically have the rules. So if they have optimizations for gas prices, like if you just change the pricing for

a specific up code, that does not necessarily actually have anything to do with the Solidity language, right? We still have the the up codes, it will just be cheaper for people to use these affected up codes or more expensive. So a bunch of these things will not really affect or not really require changes in Solidity itself. But of course if there are things that could potentially drastically change it we have a test suite that has been built over uh 10 years right so so testing is done quite thoroughly I would say >> that is good to know and I think you have mentioned in the presentation at this point as well like there are many people who are coming from different background and some people even call solidity as kind of javascript of web

three so if someone is coming up from general purpose language background. What do you think is the most dangerous assumption to begin with when they are working on solidity for application development? I think the most dangerous assumption is to think that you can roll back systems like uh if you're doing regular programming on the classic web two uh with central databases you are kind of used to being able to just roll back your database to a previous state if something bad happens or if a user by accident I don't know makes a wrong transfer to a wrong bank account you can kind of like stop the transfer or roll it back. that is not the case on the

blockchain in general. Uh so I think that's a dangerous assumption to have is that uh things work in the same way as they do on web two >> reversible. It's not always possible to reverse the transaction or like you can get it back. >> Yeah, exactly. Because of the the immutable and and decentralized design of blockchains, you you cannot just uh say hey I want to revert a transaction. If you have implemented your smart contract to have that functionality, then people will most likely not want to interact with it because it means that you are an admin with the power to to do whatever you want and that goes against the whole point of a blockchain, right?

>> That's absolutely correct. Well, I love the idea that team is trying to share the survey form and try to collect feedback. My understanding is at the end of the day they would like to follow up with these feedbacks try to fix things which are broken and things like that. I'm trying to understand here the other way around for a developer or tooling if they are watching this episode. Do you think there is a gap that they can jump in and fill it kind of lowhanging fruit for anyone who wants to start working with solidity?

>> That's also a a good question. I I think lowhanging fruits for tooling. I I think most of that has been done by now. At least I I don't have any uh really good ideas of of what uh is a lowhanging fruit to to build for tooling. But I also think you can always find existing projects to join or to make small contributions to like there are a bunch of different I don't know editor like IDE editor extensions for solidity that might uh need a a hand with a small I don't know improvements stuff like that.

So so find a small project like a small tool see how you can help out. uh we have a bunch of project as I mentioned in in Argo and we have usually some nice first issue or like low hanging fruit that people can can check out and I think that's a fairly common thing to do when you're developing uh open source code that you allow like you have a list of of things that that other projects can or that that people can start working on. Um but like full I don't think there's like uh any that are low hanging fruits. I would love to see uh more work being put into something like step through debuggers for smart contracts but that is not an easy thing to do or better or different language servers that you can run in in your

editors stuff like that would be great but it's it's not on the easy side >> right I think uh you already have given a very good suggestion perhaps start with um good first issues try to work with the project and if they find some developers challenges is then perhaps that could be good tooling to be worked on. >> Yeah. And and I think building tooling and especially like open source tooling of course it's not the thing let's say that the VCs look for. It's not where the most money is being focused. So we also in in Argo building open source tooling right. So it's like funding is always a question. So, so it's also yeah, my point is just like it's it's

usually not where people if you start contributing to to a project there, you should probably expect it to to remain unpaid, but it's a very good way to to get started, of course. And luckily, we have a bunch of projects like Octant and in the past Gitcoin and now we have the DAO fund which are focused on giving donations and funding some of these open-source not for profit profit projects. So I think that's extremely important as well and it's important to put some focus on on these things so that we can actually continue to build these very important infrastructure tools that shouldn't be shaped or directed by VC money or anything like that.

>> Yes, that's a very good point. There are definitely a lot of public good funding sources which can be used to have this open-source projects which would be helpful for more than one of course programming languages. Well, you mentioned about uh I don't know if it is a new stream or new product about core solidity. Right now we do have classic and core is expected soon for uh someone who is trying to understand what this project is all about. Is it something a different programming language or is it a part of classic uh what is the distinction between the these between these two and yeah let us know if they are meant for different developers group. They're not meant for different developer groups. I would say they are different languages, but they have a lot

of overlap and a lot of the work that we have been doing in the last year or so and the work that we are doing right now. For example, the SSA, CFG I mentioned, uh these optimizing steps, stuff like that. They are things that will carry over directly to Corey and they will they will be compatible the two languages and classic will still continue to be developed as well. Corality is an alternative let's say to developing smart contracts. Um if everything goes according to plan then in a a year or two years I I hope that everyone who joins uh and starts like writing smart contracts and writing

building new protocols they will actually be using coreity because hopefully it or because it's it's meant to have better features for writing safe smart contracts which I think is the most important thing. So yeah, they're they're complimentary and they will coexist and as I mentioned a lot of the work being done on classic at the moment carries over directly to also benefit core solidity and some of the work that is being done on core solidity might also go back to classic solidity if it if it makes sense. So yeah but they're two different u languages >> different languages yet complimentary to each other.

>> Yeah, exactly. and they still both compiled to the EDM in the end. So they they will similar to what FA will also do and and Viper. So they still have to complement each other in that way. That makes sense. Well, we were talking about like support to the U projects which are generally meant for public good. Solidity is one of those. Argo is there to support solidity. I'm curious to understand uh what does team think about sustaining of uh this kind of project at this scale. Do you see a role of community there? If so, what does healthy stewardship would look like? How can community help projects like solidity?

>> It's a good question. I I think of course the community can help by for example filling out the solidity survey they briefly discussed. that has been going now for a month and we received what are we at now like 1300 1,300 responses I think at least doing that giving your feedback providing the feedback in in a like a constructive way it's fine to be dissatisfied about things and like warning features that we we don't have stuff like that but if you like if you present it in a constructive way and come up with a suggestion for how a feature could be added of course that always helps then on a different level like you can be doing whatever meetups, trying to teach other people how to write uh simple smart contracts.

We we need a hold of it, create a small video and put it on YouTube showing people how to write a smart contract like all all these uh kind of things, right? And then as I mentioned, we also trying actively to precautionally include the community into shaping what the standard library will look like. This will be a bigger topic and some thing that requires a lot of back and forth and a lot of different stakeholders, but we really want to make sure that the community is involved in all of this. And if you look at Ethereum as a as a whole, I believe that it's also been very communitydriven and built by the community from the very early days. Now of course we we see a lot of uh institutional players as well like uh

it's it's not just a niche anymore but that's anyway I think the community is where Ethereum is really the strongest and you can say the same about solidity that it has been the most used smart contract language for a long time. So of course the community around it is also very strong and the tooling is strong as well. Right. I would say one thing that is also worth mentioning is that it also requires like a lot of uh you have to be very careful as well when stewarding a programming language that has this much money locked in it because you cannot just go out and break things. You always have to think on backwards

compatibility. So that's also a challenge and something where even if we potentially really wanted to add a feature or do something that the community is requesting then it's not always possible because it would maybe jeopardize security or safety. So we also have to be able to go back to the community or they the users and explain why we we cannot do that. And I feel like in most cases they people are fairly understanding around this. But again it's also one of the reasons why core solidity is is so interesting because it can address a lot of the the things that people have been wanting for a good while.

>> That's good to hear. That means um definitely there are more than one avenues. I also noticed that there was solidity summit during deaf connect. So that is one of the places where we can learn more about it and we can share our feedback in a constructive way. Definitely helpful uh for the team to follow up and support the ecosystem. Education is important. So if people can educate more people about how it works and where to reach out if they need help that is definitely going to help. Well you mentioned about 1,300 plus survey responses. I'm sure team is going to have a good time, fun time following with all of them. But I also understand that AI can come into picture and help a team figure out what actually users are

looking for in the era of like aentic AI and everything. I'm curious to learn where solidity stands. Do we see AI support as a support to the language or are we looking at some different kind of thread because people are now using code copy pasting it as is. could be dangerous. I wonder what team thinks about it. >> Yeah, I think I this is a a great question. I think in general you should be very careful about what smart contracts or what solidity code or anything like that that your AI is writing. At least you should always uh make sure you read it carefully and that you understand exactly what it is doing because as I mentioned earlier, it might be that your smart contract will

actually hold uh people's uh money, right? and and you and you don't want to people to to lose their money. So I think that AI in smart contract development should be used yeah as any other tool. It can definitely help you prototype faster. It could definitely help you have a working like minimum viable product but like this the security of it you still need to really spend a long time doing and I hope you won't see too many uh vibe like purely vibe coded uh close my eyes look the other way smart contracts that will be uh deployed uh to mainet but we will probably start like eventually see a lot of uh smart contracts uh popping up and here and there and there's already now a lot of security tools for AI out Yeah, I

know AIs have found a bunch of uh bugs in different places already, which is great, but it's like a a two-edged sword. If we can use AI for good to find the the box, it also means that uh people who who want to do exploit protocols can also use AI to to find the the bug. But I actually I think you also asked about it but like for what we we're not doing anything specific with core solidity or solidity in in terms of like making it more or less friendly towards AI. Of course there's quite a lot of solidities code that AIs can be trained on by now and I know that that they've gotten much better at writing solidities which I think is good. My point is just don't trust it blindly.

And then another thing is that I recently read like a report where someone had been comparing a lot of different programming languages to see which ones AI managed to use them the best and had like the lowest token usage and stuff like that. And the language that won actually has quite a lot of like similarities feature similarities to what core solidity will have. So for example, this like pattern matching will be it's something that AIS manage fairly well and it also means that because the compiler will catch cases that you haven't covered then it's easier for the AI to get that feedback from the compiler and then implement the like

handling of these cases. So I think a lot of the choices made for cogability will be choices that will benefit AI agents that write code in the future. >> Yeah, I mean it seems like it's more than evident that in next uh few years perhaps the first draft could be coming up from the AI. >> I think it already does for most people these days to be honest. I I think uh most people these days uh myself included if if I'm writing something or adding a new feature to something I ask an AI to to do it first and then uh we we start uh like uh making adjustments uh after because often the boiler plate

or whatever like I think the good thing is that that you can spend time thinking about the hard things now and you don't have to waste a lot of time doing the mundane tasks so to speak, Right. Um I think that's uh one of the good things about uh uh AI coding agents. >> That's right. And actually that brings me to my last question in this section about the role of developer like we see that maybe first draft is coming up and people are more involved in fixing it and making it work. What do you see the role of solidity dev in future? Would it be more focused on auditing and understanding the language in a better way? Where do you see developers contributing the most?

>> That's also Yeah, I mean that I think it's the same for for Solidity as as many other programming languages in general that you as a developer will have to be more like guiding and designing the protocol and yeah of course looking through the code to check that it's actually doing what you expected to do. But I think we already now see that people are not writing code anymore. Really, at least I I a good amount of the people I follow on Twitter that are outspoken about using AI have said like that they have not been writing any code for the fair amount of last three to six months or something like that. So [snorts] I think it's it's

all about understanding the concepts and knowing what you can do or can't do within a specific like programming language or something like that and then making getting the AI to build what it should right but it is definitely going to be uh interesting and we are definitely very much in the middle of a huge shift right now in what the role of developers uh is and also just like the role of of a lot of people Right. One thing I think unfortunately is like it's probably going to be more difficult to be a junior developer these days. I think that's like a main talking point is like at least a lot of the things that a junior developer can do, you can

easily get an AI to do uh instead. So I think the barrier of entry into computer like a programming jobs will probably be more difficult. It's going to be interesting to see what happens in the next five years and also when things slow down a little bit if they do because uh the pace things have developed at over the last year has been crazy. Right. >> Absolutely. Yes. Yeah. It will take a little bit of time to settle down. So we know where we are at and we'll take it from there. Well, I think I would like to move on to the next section which is called rapid fire round. So here we are going to ask you a few questions. U maybe you can respond in one word, one

sentence, one minute answer, whatever works. >> Sounds good. >> All right. So if you were writing a brand new protocol from a scratch tomorrow, which would be your first preference, Viper or Solidity? >> Solidity. both because I want to keep my job, but also because it's it's the one that I'm the most um experienced in. But actually, if I was doing a new project or new protocol, it might be fun to do Vibra to actually get more familiar with it and and uh compare the two. But if it was something I was planning on putting to production, but definitely Solidity.

>> All right. So, my next question is one feature from another language you wish Solidity had stolen earlier. >> I think pattern matching. You mentioned that the team has received over 1300 responses. So what is the single most surprising piece of feedback that the team has received? >> Since I only joined the team fairly uh recently, I don't really know. I don't have a good example. Next time I'm on here, I will make sure to to share it with you when I've gone through the survey answers. >> I'm sure there would be a report out. Perhaps we can follow that.

>> For sure. >> Remix ID or local tooling, what do you use for day-to-day? I use Remix if I have to do a very quick uh prototype or example or if I'm doing like a workshop where I need to make sure that everyone has the same environment and don't waste time setting up a development environment. But for anything of uh like bigger size, I definitely do a local environment of foundry. >> That's interesting. formal verification. Is it overhyped, underused, or just waiting for the right tooling moment?

>> It's definitely not overhyped. Maybe it's underhyped. I think it's a extremely important tool to have. Underused, yes, but it's also not that easy to use yet. There are no like super easy out of the box tools. Uh you still have to pay an auditor or whatever quite a lot of money to to spend time to to formally verify your protocol even though there are tools for it. But they still require manual interaction as well. So I think it's like the right tooling moment would be yesterday basically. There's been work uh done on formal verification from the very beginning but it's just tough not to crack. It's a hard problem but it's uh I think if every protocol could be formally verified that would be amazing right would find a lot of bugs and it

would also mean that you could trust the correctness of uh the smart contracts that you interact with. So uh definitely not overhyped. What's the one EVM limitation you would remove if you could >> pretty the stack too deep like the the stack size basically built in to the EVM? But I think I think that would be a a good candidate. I mean if you could do whatever then maybe fully removing gas but that would break everything. So that doesn't really make sense but it could be cool to have um much more like no constraints for for compute. But yeah, as I said wouldn't wouldn't work but could be nice.

>> That's great. And where can people find you or the team >> on Twitter? Most like yeah Twitter or in uh we have a couple of public matrix rooms. So we in Argo we use a full open-source stack for everything internally. Matrix/element is our chat our communications app and we do have some open rooms that anyone can join. And then we have the solidity forum as well and of course checking out the argo.org or our website and and follow the the blog there. And if you want to meet in person, then some of us will be around in SEC in cans in a couple of weeks and I think there will also be a link to my Twitter at least in the show notes.

>> It will be there and we'll try to add all other links that you have mentioned in here so people can follow. >> Sounds good. >> Thank you, Jacob. It was really interesting. We enjoyed having this conversation [music] and solidity and hope that we get more contributors. It's a public good project. So we hope that it is supported by community [music] as well. >> Yeah, thank you for having me. It was a pleasure. >> Dear listeners, if you want to help shape where Solidity goes next, respond [music] to the survey while you can. Please follow team and resources. Links are added in show notes. Follow EC Institute podcast for more [music] projects supporting Ethereum public goods and share them to increase the reach. We'll be back with another project. Till then, enjoy the updates.

Cheers.