Thoughts on Language Design and Fragmentation by Alex Beregszaszi

so yeah my name is Alex I am part of the solidity team and in this talk I will go through why I think solidity needs to evolve rapidly and will also bring some examples to show that it did evolve rapidly in the past and I think this is very useful and it's actually needed but before we get into some of these details I will provide some some reasons why I think this is like a truthful statement but before we get into that I brought some interesting trivia by digging through the changelog and I think this will this will show some interesting things at this part feel free to maybe interrupt me like once or twice but there will be a longer time available at the end for a Q&A so the domain of the film kind of launched in July August and the first release the solidity according to changelog is zero one zero however it's not even tagged and get and there's no build anywhere so I'm not even sure if it exists but zero one one is the first one which actually exists in terms of a gate tag and it's part of the binary releases but it's not going to get hub release page it was only the next series which which is present on the release page now going into changes in the language the first actual new feature introduced was in 2015 September they did throw statement does anybody remember that still yeah I'm glad it was gone but we you may be able to bring it back for a different reason 9 the same year we had the first two breaking releases so still in 2015 zero one five was the first which broke I guess the API it broke the encoding of storage and also this was the first version I ever used of solidity and then zero point zero point two was the first one which made a break in the syntax the reason for this change here was is a was kind of ambiguous how to parse the old version without the practices now moving on to the next year quickly I mean this was just like three months after there was a new braking really into zero three zero which made some preparations for assembly and also made libraries usable and then moving on still in the same year roughly another like six months later we had another break in Belize and this had quite a few breaking changes I didn't listen here but I counted at least at least sixteen and you guys can see it already had two familiar features of today the immersion program and the payable keyword and also by zero three six does anybody remember the the old formal verification back-end that's also gone for a long while and then we had the metadata and just going on to seventeen all these features are really familiar to everyone and as you can see we had like a really up to this point yet a really steady really schedule we had major improvements every few months and you can see a big break here so end of like 2017 we were midway through the 0.4 series and of course in 2017 the ecosystem exploded a lot of people came into the space a lot of new projects were spawned so at this point we got a bit more careful about making breaking changes and this carefulness resulted in - looking back like two slides back September 2016 was the last breaking release the next one was November 2018 two years after the previous one and this was because of this carefulness that you don't wanted to to make breaking changes because people would complain people to be happy and we didn't want to just slow down anyone but actually what we ended up doing is slowing down people even more because the 0/5 resulted in 60 breaking changes and people didn't wanted to move on and it took quite a few releases in 2:05 until people finally started to move on and this was also the first time we ended up releasing a zero for like a previous version after zero five so we had a zero for twenty six release with serious bug fixes because people who are still heavily using it and somehow we managed to repeat the same mistake with zero six release last December it took a year after zero five and not sixty but turkey breaking changes and so this was some interesting trivia I like but let's go into the actual reasons well I think all of these changes are actually happening so reason what number one is the the goals of the language are kind of shifting and initially we wanted to have a really friendly language to attract a lot of people to this place because both etherium as a protocol in this system and both solid ideas and language were brand new and and basically the concept of smart contracts they did exist prior to solidity but this was really first language which made it usable and unfriendly to people so the goal was to be friendly and to invite a lot of people so because of that we choose a design which looked like JavaScript and did a lot of weird implicit things and was kind of easy to learn so this is what we ended up with people doing an example from 2015 it's such a lovely piece of code such as interest do you guys can I guess you can see my maths so there's an interesting line because we didn't have the new keyword for bytes there was no way to allocate bytes here so because of that there was this nice predefined allocation and in terms of spaces so this was the one of the features missing the second feature missing is we didn't have shifts as it can be seen here and also there was like a weird bug and the comment is wrong but the bug was that if and iterating the the other way around then some fields in the last field I believe was overwritten by the last store um so this is an example that we we didn't have too many features and reversible expects Blissett moving on to 2016 here's another like interesting piece of code what is this doing is trying to concatenate strings and they had no such feature at all interestingly we still don't have a feature for concatenating strings but there's this side effect of ABA encode pact introduced two years after this code was written which can be used to concatenate strings so still at the reason one the goals have shifted in this is what we had in terms of language and and I think at this point we're not trying to be a super friendly language for people familiar with JavaScript that are we trying to be a safer language while the same time also trying to stay friendly and syntax but the goal is safety so because of that we have a lot of we're both syntax a lot of explicit syntax and we really try to highlight constructs for for people which would be risky so as an example here anything which would cause unbounded gas usage is a huge risk because you could end up with a lock-up so for example there will be tomorrow a session about an explicit copy syntax so that could be one of the other cases which where we try to highlight all of these riskiness so that's like reason one reason too is that it here iam is still learning the protocol and DVM is evolving the new feature said it is this one example create - was introduced quite a while back but to fully exploit the the benefits of tree to be needed language support and that also to provide you to integrate because of deciding what the syntax should be also these protocol developers create lots of new restrictions every now and then and they also reprise instructions and all of these have like a profound effect on the language because structures and features switch prior may become unusable or may become a bit risky and as those changes are enacted in the protocol and and lastly even bigger changes are coming there the new protocol is being developed one example is e 2.0 and it also has like a huge effect on the language because it introduces such features which have no concepts in the language right now recent 3 is that the the ecosystem the developers they're still really learning how to use this language and how to use the whole system and they're doing like all sorts of interesting and weird and and maybe sometimes dumb things and we have to really find a careful balance here in the language between providing them good features so they shouldn't be just running around and trying to implement everything from scratch but we shouldn't be too restrictive we shouldn't just tidy hands and the it's really hard to find this good balance between providing enough features but not being too restrictive and we are constantly trying to figure out this balance and I don't think we have found the balance yet um recent for is that experts or auditors they also learning I guess like in 2015-16 when all this started probably it would have been possible to count the number of experts in new VM or solidity in terms of capable of auditing code I would would have been able to count it by hand maybe it was only like 8 or 10 of them but today it's like a quite a healthy ecosystem we probably have a handful of companies with a lot of people in each who are experts in in the complexities of yttrium EVM and solidity as well and it took quite a while for these people to to build all their tools which are needed to aid their work I want to reflect back here to the tree earlier talks where today from ricard occasionally these tools are really variable and important because you guys mentioned that there you have found issues in the language and issues in the compiler itself and I think that's really important that we take all of this advice and reports from you guys seriously and we consider the implications on the language and we should change the language if that's the right right thing to do based on those findings and the fifth reason is that the solidity community itself is still learning a lot had to do things right we are trying to figure out which are the features which language should have and which are the features the language shouldn't have but we should enable people to to build those features on top of the language but I don't mean here that we want everybody to re-implement the same things we want some kind of modularity and it's really hard to figure these things out and so we still don't know what are like good syntactical options and what are bets in tactical options we're trying to youtube to first like choose something which looked okay at the time but probably realize a few months in there together with some other features it may not be the best way to do it so it's nicer to change it and also it's really hard to find a balance between how we're both the language should be or how aggressive the language should be and I think right now we have decided to to be on a really explicit side of the spectrum but it's still unclear but it would this is the right approach to take I think we have to experiment and find out what is the best approach and and lastly just away delivering these changes to the actual depth developers that's also something which was a bumpy ride so far so just going back to 0 for 0 again another reason probably 0 for 0 - quite a bit because developers rely on on frameworks they don't use a compiler directly and they shouldn't be using the compiler directly these frameworks are really useful and helpful for them but I think at the time like in in 0 4 so like 20 18 ish a lot of these frameworks were still early and they may not had like options to to rapidly deliver a new compiler versions I think we have learned over the past like two years had to deliver new compiler versions more rapidly to developers which which also really is really important and I guess one more note on on that is which probably nobody has heard about but we do have a tool called solidity upgrade or update I think it's upgrade which can be used this this exists for 0 5 and 0 6 and it can be used to automatically transform in the case of the 0 5 0 4 piece of source code to the 0 5 syntax and of course it cannot do everything but it can do a lot of the manual work and so I think we learned quite a bit how to deal with these changes more quickly to developers so I think these five reasons show that we need all of these changes and we need these changes to happen fast because we're still really early in terms of the protocol the D language and ecosystem I think you're also quite lucky lately that it turned out that solidity is extremely popular and this is also showed by the two new compilers which have surfaced for solidity and we also lucky to have these two new compilers to take part of the summit today I think so we'll have a talk later on and tomorrow or so Lang will also introduce you compilers and I would like to take the opportunity here for four to reach out to you guys and to say they will be really nice to you to work together on the language design because it's important to they're the consistent language across all of these compilers and it's important to have the feedback from everyone so I guess what remains now is just to show how any of this design is happening it's probably not everybody is aware that a design process is quite open you may think that this is something restricted and we are liking in our dungeons and we discuss in hiding but is extremely not the case all of the discussion all of the important discussion is really happening on github issues on the ETM slash solidity repo unfortunately some of these issues go back to 2016 and it's really hard to get feedback to some of them and to engage people a lot more but we do have sometimes we do have ad hoc discussions Gator Gator or we do have in the team to weekly meetings on Monday and Wednesday in many cases we do discuss some of these features and in like a more fluid manner on these two mediums but in every single case when we do that at the end of the discussion we do record our findings on the issues and and lastly we do have to sum it here with the main goal to discuss actual actual language design questions and but let's see how could we move on to the future so I collected like three different options for going into the future and the first one is we could have some kind of a focus group and which still tries to have a similar development cycle as we have today and this practically would mean to have regular meetings to brainstorm some of these issues so you can think about this as kind of like a mini solidity summit on a regular basis and I guess as we move much more into the future we could have more structured proposals just like Python perhaps or this fifth evolution but I think this might just slow down development right now too much but I think we can take some learnings from them and and finally I guess in the in the really far future we could have some kind of a language committee but I wouldn't advise to to consider that for now so my conclusion is that we need to keep all of these we need to keep making these changes at the current pace and maybe we should consider just this focus group I think I don't have too much time maybe for one question but I will be hanging out on Gator to it soon as for any questions thank you