speaker-0: 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. It's meant to have better features for writing safe smart contracts, which I think is the most important thing. I think that AI in smart contract development should be used. We have Course.com coming up, which is a new initiative to make a different language that to some extent learned from some of the mistakes that were probably made in but I think we already now see that people are not writing code anymore. think the most dangerous assumption is to think that you can roll back systems like

speaker-1: you Welcome back to Ecosystem Project Demo, this episode brought to you by ECH Institute. Today we are going to talk about a programming language. So if you have ever interacted with DeFi, NFT, perhaps you have guessed what project we are going to talk today. Yes, it's Solidity. Solidity is one of the programming languages that runs under the hood for most of the Web3 application. And today we are joined by Jacob. to share more about the project. Jacob is a member of Solidity team under the Arget. For people who aren't aware, Arget is a non-profit organization supporting projects for Ethereum applications. Welcome, Jacob.

speaker-0: Thank you very much. Happy to be here.

speaker-1: Jacob, I noticed that 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.

speaker-0: Yeah, what we released today is a pre-release. So that's like a way the projects can try out a new release before it's actually released. And this gives tooling and other projects a chance to prepare for new releases. So for example, if you have something like Hardhat 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 preview release and hopefully next week the real release will come out.

speaker-1: That's wonderful. Well, over the next 30 minutes or so, we will be covering the language, the roadmap and exciting feature that it brings. But before we get into there, tell us about yourself. How do you find Web3? How did you join Ethereum ecosystem?

speaker-0: 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 in early 2015. So he introduced us to that project and We thought it was super interesting and started 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 mainnet yet. And got offered an internship. So I started, I did an internship in the fall of 2015 in Berlin for the FDEF office. and worked on the Python client. So they used to exist an Ethereum Python client back then. So that's how I got into this space. And then after my internship, I joined a company for seven years, I think. We worked on things like Raiden network, which was like payment channels for Ethereum. We did a project called Trustlines. We did Shutter. 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 F Berlin and Protocolberg. 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 do believe that it's important to give back and volunteer some of your time. think it's also just part of my Scandinavian mentality. So I still do that. yeah, then. More recently, I've worked at a company called Filex Systems that they do security tooling around smart contracts. And now I've just a little bit more than a month ago joined Argo to work on Solidity, mostly developer relations. So yeah, that's a little bit about my story to keep it short and not go too much into details.

speaker-1: 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 mainnet. 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 Dehcon, which is bonus and for now maybe we can just go ahead and get started with the presentation.

speaker-0: Yes, for sure. The survey, we're closing it very soon. It will still be available when the podcast actually goes out, but yeah, we can still have a link to it, of course. And yeah, I'll start my presentation now. Just before I do one thing I think is quite interesting to mention at this point already is how the, since 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 developed over these 10 years. then there was like basically like you almost didn't have anything like ether scan or just the basic tools like that. 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 used to be. All right. Yeah. So I'll talk about. Solidi and its past, present and future to give you a little bit of an overview of where the language is coming from, what's the current state of it and also a bit about where the language is going. As already mentioned in the beginning, Solidi 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 and now. There are a couple of alternatives as well, by far, Solidity is the most predominant programming language for Solidity. it underpins more than, or like around 200 billion in DeFi alone, which is a lot of money comparable to, I would say probably like different traditional banking systems, stuff like that. yeah, with that much money, definitely need to have high security as well. And this is one of the challenges of course, but. We can 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 as much money. There's a lot of stuff to talk about, but yeah, to go little bit back to the origins and small history lesson, the language was 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 language. for those who are more used to traditional programming languages, 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 Solidity. As I mentioned back then, there were a couple of other early programming languages. ⁓ One was a Lisp-like language. ⁓ And the other one was serpent, which, ⁓ was kind of a predecessor to, to what is now Viper. 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 this new, ⁓ 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 happened over the years. And we are still like over time with a lot of hacks. People often get have their like default 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 box. 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. as I said, like safety and correctness gradually became the overriding design factor that shapes the language more and more. now we're at version 0.834. As I mentioned, we just had Pre-release earlier today 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 coming up, which will have some breaking changes. And that has already been mentioned, for example, in our blog. So 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. 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 the year so far. We have a good amount of funding secured for long-term stewardship of the language. We also have a bunch of other projects that I mentioned Solidity. have FAY, which is another EDM language. Then we have Sourceify, which is a kind of like source code verification tool. So you can go and like verify your source code there and you can like, have a big look up of different functions, signature stuff. It's actually a really cool tool that you can use for many different things. Definitely check it out. Then FDebug, it's a debugging tool. and HEVM are both formal verification tools. So we're 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 evolution of programming languages. So yeah, 10 years of development and shifting needs for classic solidity has created some technical depth. There's been a lot of new features, some features included that were not planned ahead or like planned early on, which means that it feels a little bit like, like these extensions that are ad hoc and it's making it harder and harder to reason about the correctness when you're introducing things like this. also, classic salinity is being used in many ways that was not necessarily envisioned early on, like 10 years ago. Most people probably didn't envision that, that smart contracts would be used for all these kinds of things that they are now and hold this much money. So the language has kind of had to adopt to how people wanted to use smart contracts instead of the other way around. if that makes sense. ⁓ 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, which is a rebuild of 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 that call the liddy ads, won't go too much into detail with them. It's not straightforward to explain what all of these things are. And it's also maybe not the most interesting thing, but to name a few, have algebraic data types and pattern matching, which combined make it very, like you can't represent invalid states in your smart contract. And I think this combination will be extremely powerful that you can basically use 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 make it easier 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 Haskell. So this will be a little bit different from what we do now until the day where we use inheritance. Then we have higher order functions and compile time evaluation. And then we will have a standard library in place and this will be community-structured 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 10 years. And a little bit on the roadmap. 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 insectrification, comes out on design. And this is like for Q1 2026 and in Q2, we have the stack to deep error that I talked about that we'll be fixing. think a lot of people will be quite happy about that. And when I was looking through a couple of the early responses in the Solidity survey, this was still mentioned as one of the main. pain points. it's definitely going to be nice to finally address and fix this one. People will be happy, I think. And yeah, then we 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, a linear experimental release. So people can actually start playing around with it as well as we will start ⁓ shaping the standard library with the community. And we will have classic and core, so that we 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. But I'm sure you also have some good follow-up questions on some of these things that we can then discuss a bit.

speaker-1: Absolutely. And thank you. This was wonderful. This was a very good high level 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 experts. 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 the evolution. And I also remember there is a roadmap, half a year roadmap. that was published so perhaps we can add the link in our description for people who want to follow more about it.

speaker-0: Yes, for sure. I'll definitely do that. You can also find the blog post easily if you follow the link I showed for Argo. But I'll have a link list.

speaker-1: Right. So, 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 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?

speaker-0: I think if we compare with any, let's say non-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 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 efficient code. So this is something that you have to keep in mind when you start writing smart contracts of any language, but it is ⁓ probably one of the biggest surprises and things that people have to get used to.

speaker-1: 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?

speaker-0: I are some differences. Of course, the syntax is fairly different than in Viper, for example. think one of the bigger things they have is they have to be careful not to mix it up. But I think they don't have the issue with the stack to deep error, for example, because they do everything in memory, which is like a small detail, like can matter to some people. under the hood, like the languages are quite different, but they compile to the same backend. So I guess it's about what you prefer.

speaker-1: Course preference is good here.

speaker-0: Exactly. also have in Argo, I mentioned we have FAY, which is another smart contract language, which also it's quite similar to Rust. You know Rust, you feel quite at home quite quickly in FAY, which is also seeing a lot of development at the moment. So I think FAY is also going to be quite interesting for a lot of people to check out.

speaker-1: 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 Web2 to Web3 world, one of the important constraints is gas that is not considered in Web2 project, but it is very important and significant in Web3. I suppose the user is interested in learning about the roadmap of solidity and the testing plans of gas. testing if that is there on the roadmap, maybe if you could expand a little bit more about that.

speaker-0: So yeah, so gas optimization is like, think that's, mean, 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 optimized, guess, 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 most cases. Luckily at the moment, gas is quite cheap on Ethereum, also on mainnet. And then I think in the course of the, 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 them more like used. Functionality that we have now will be cheaper in Core 7.0.0.0 than it is in Classic 7.0.0.0, but it's still very early days, so I really can't say.

speaker-1: 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, EIPs, and that can help optimizing gas on contract writing level. So I don't know if the user wanted to maybe check on the Glamster Dam proposals, which are there for gas optimization. Has the team considered doing the testing for those proposals?

speaker-0: We will definitely be doing it once it lands on Ethereum, right? Like how it usually works, how it lands in the protocol, how it usually works is that the clients implement it, right? They implement the spec 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 upcodes will just be cheaper for people to use these affected upcodes 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, we have a test suite that has been built over 10 years, right? So testing is done quite thoroughly, I would say.

speaker-1: 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 backgrounds. And some people even call Solidity as kind of JavaScript of a tree. So if someone is coming up from a 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?

speaker-0: think the most dangerous assumption is to think that you can roll back systems. Like if you're doing regular programming on the classic web two 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. So I think that's a dangerous assumption to have is that things work in the same way as they do on web 2.

speaker-1: reversible. It's not always possible to reverse the transaction or like you can get it back.

speaker-0: Yeah, exactly. Because of the immutable and decentralized design of blockchains, you cannot just say, I want to revert that 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 do whatever you want. And that goes against the whole point of the blockchain, right?

speaker-1: 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 low hanging fruit for anyone who wants to start working with Sanitakini.

speaker-0: That's also ⁓ a good question. think low hanging fruits for tooling. think most of that has been done by now. At least I don't have any really good ideas of what is a low hanging fruit 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 need a hand with a small, I don't know, improvements, stuff like that. So find a small project, like a small tool, see how you can help out. We have a bunch of projects, as I mentioned, in Argo and we have usually some nice first issue or like low hanging fruits that people can check out. And I think that's a fairly common thing to do when you're developing open source code that you allow. Like you have a list of things that other projects can, or that people can start working on. ⁓ like food, I don't think there's like any that are low hanging foods. I would love to see 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 your editors. Stuff like that would be great, but it's not on the easy side.

speaker-1: All right, I think you already have given a very good suggestion. Perhaps start with the good first issues, try to work with the project, and if they find some developers challenges, then perhaps that could be good tooling to be worked on.

speaker-0: Yeah. I think building tooling and especially like open source tooling. 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 Argo building open source tooling, right? So it's like funding is always a question. So it's also. Yeah, my point is just like, it's usually not where people, if you start contributing to a project, they should probably expect it to remain unpaid, but it's a very good way 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 Dow Fund, which are focused on giving donations and funding some of these open source, not for profit projects. I think that's extremely... important as well and it's important to put some focus 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.

speaker-1: 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, 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 someone who's trying to understand what this project is all about, is it something a different programming language or is it a part of classic? ⁓ What is the distinction between these two? And yeah, let us know if they are meant for different developers groups.

speaker-0: 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, these optimizing steps, stuff like that, they are things that will carry over directly to... And they will be compatible with the two languages and Classics Lidi will still continue to be developed as well. Core Lidi is an alternative, let's say, to developing smart contracts. If everything goes according to plan, in a year or two years, I hope that everyone who joins and starts like writing smart contracts and writing, building new protocols, they will actually be using. Causality because it's meant to have better features for writing safe smart contracts, which I think is the most important thing. So yeah, they're complimentary and they will coexist. And as I mentioned, lot of the work being done and Classic at the moment carries over directly to also benefit Causality and some of the work that is being done on Causality might also go back to Classic's validity, if it makes sense. Yeah, but they're two different languages.

speaker-1: different languages yet complementary to each other.

speaker-0: Yeah, exactly. And they still both compiled to the EDM in the end. they will add similar to what Faye will also do and Viper. So they still have to complement each other in that way.

speaker-1: That makes sense. Well, we were talking about support to these projects which are generally meant for public good. Solidity is one of those. Our goal is there to support solidity. I'm curious to understand what does the team think about sustaining of 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?

speaker-0: That's a good question. think of course the community can help by, for example, filling out the Solidity Survey that we've discussed. It has been going off for a month and we received, what are we at now, like 1300, 1300 responses, I think. So at least doing that, giving your feedback, providing the feedback in a constructive way. It's fine to be dissatisfied about things and wanting features that we don't have, stuff like that. But if you like... you presented 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 simple smart contracts. We need all of it to create a small video and put it on YouTube showing people how to write a smart contract, like all these kinds of things. Right. And then as I mentioned, we also trying actively to. For calls, we need to the community into shaping what the standard library will look like. This will be a bigger topic and something 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 whole, I believe that it's also been very community driven and built. the community from the very early days. Now, of course, we see a lot of institutional players as well. It's not just a niche anymore, that's anyway, 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. I would say one thing that is also worth mentioning is that it also requires like a lot of, ⁓ 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, right? I'll make the users and explain the why 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 so interesting because it can address a lot of the things that people have been wanting for a good while.

speaker-1: It's good to hear that. Definitely there are more than one event news. I also noticed that there was solidarity 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 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, agent AI and everything, I'm curious to learn where Sanity 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.

speaker-0: Yeah, I think this is a great question. think in general, you should be very careful about what smart contracts or what's the validity code or anything like that, that your AI is writing. At least you should always 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 people's money, right? And you don't want people to lose their money. So I think that AI in smart contract development should be used ⁓ as any other tool. It can definitely help you prototype faster. It can definitely help you have a working like minimum viable product, but like the security of it, you still need to really spend a long time doing. And I hope you won't see too many like purely vibe coded, close my eyes, look the other way as smart contracts that will be ⁓ deployed to mainnet. But we will probably start like. eventually see a lot of smart contracts popping up here and there. And there's already now a lot of security tools for AI out there. know AIs have found a bunch of bugs in different places already, which is great, but it's like ⁓ a two-edged sword. If we can use AI for good to find the bugs, it also means that people who want to do exploit protocols can also use AI to find the bugs. But I actually, think you also asked about it, but like for what we're, we're not doing anything specific with core solidity or solidity in terms of like making it more or less friendly towards AI. Of course, there's quite a lot of solidities code that AI's can be trained on by now. And I know 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 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, there's like pattern matching will be, it's something that AI's managed value will. 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 handling of these cases. So I think a lot of the choices made for CourserLinux will be choices that will benefit AI agents that write code in the future.

speaker-1: Yeah, I mean, it seems like it's more than evident that in the next few years, perhaps the first draft could be coming up from the AI.

speaker-0: I think it already does for most people these days, to be honest. think most people these days, myself included, if I'm writing something or adding a new feature to something, I ask an AI to do it first and then we start making adjustments after. Because often the boilerplate or whatever, I think the good thing is 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? I think that's one of the good things about AI coding agents.

speaker-1: 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 First Elated 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?

speaker-0: That's also, I mean, I think it's the same for Solidity 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 check that is actually doing what you expect it to do. But I think we already now see that people are not writing code. anymore, really, at least 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 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 a programming language or something like that. then. making, the AI to build what it should, right? But it is definitely going to be interesting. And we are definitely very much in the middle of a huge shift right now in what the role of developers is and also just like the role 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 instead. So I think the barrier of entry into computer programming jobs will probably be more difficult. It's going to be interesting to see what happens the next five years and also when things slow down a little bit, if they do, because the pace things have developed over the last year has been crazy, right?

speaker-1: 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. So maybe you can respond in one word, one sentence, one minute answer, whatever works.

speaker-0: Sounds good.

speaker-1: Alright, so if you were writing a brand new protocol from scratch tomorrow, which would be your first preference, Viper or Solidity?

speaker-0: Solidity, both because I want to keep my job, but also because it's the one that I'm the most experienced in. But actually, if I was doing a new project or a new protocol, it might be fun to do Viber to actually get more familiar with it and compare the two. But if it was something I was planning on putting to production, definitely Solidity.

speaker-1: Alright, so my next question is one feature from another language you wish solidity had stolen earlier.

speaker-0: I think pattern matching.

speaker-1: 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?

speaker-0: Since I only joined the team fairly recently, I don't really know. I don't have a good example. Next time I'm on here, I will make sure to share it with you when I've gone through the survey answers.

speaker-1: I'm sure there would be a report out. we can follow that. Remix ID or local tooling, what do you use for day to day?

speaker-0: for sure. I use remix if I have to do a very quick 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 like bigger size, I definitely do a local environment of foundry.

speaker-1: That's interesting. Formal verification, is it over-hyped, under-used, or just waiting for the right tooling moment?

speaker-0: It's definitely not overhyped. Maybe it's underhyped. I think it's an 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. You still have to pay an auditor or whatever, quite a lot of money to spend time 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 done on formal verification from the very beginning, but it's just tough not to crack. It's a hard problem, but it's, think if every protocol could be formally verified, that would be amazing, right? I would find a lot of bugs and it would also mean that you could trust the correctness of the smart contracts that you interact with. So definitely not over-hyped.

speaker-1: What's the one EVM limitation you would remove if you could?

speaker-0: 30, the stack too deep, the stack size, basically built into the EVM. But I think that would be 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 much more, like no constraints for compute. But yeah, as I said, wouldn't work, but could be nice.

speaker-1: That's great. And where can people find you or the team?

speaker-0: on Twitter most, yeah, Twitter or in, we have a couple of public matrix rooms. we, in Argo, we use a open source stack for everything internally. Matrix slash 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, our website and follow the blog there. And if you want to meet in person, then Some of us will be around in SCC in Cannes in a couple of weeks. And I think there will also be a link to my Twitter, at least in the show notes.

speaker-1: It will be there and we'll try to add all other links that you have mentioned in here so people can follow. Thank you, Jacob. It was really interesting. We enjoyed having this conversation and solidarity and hope that we get more contributors. It's a public good project, so we hope that it is supported by community as well.

speaker-0: Sounds good. Yeah, thank you for having me. It was a pleasure.

speaker-1: Dear listeners, you want to help shape where Solidity goes next, respond to the survey while you can. Please follow Teams and resources. Links are added in show notes. Follow ECH Institute's podcast for more 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!