Martin Odersky on the Future of Scala, Learning, Teaching and the Quest for the Perfect Language

Summary

In a fascinating conversation hosted by Rock the JVM's Daniel, Martin Odersky, the creator of the Scala language, discusses the journey, challenges, and future of Scala. The talk covers a range of topics including teaching programming to children, the complexities of teaching Scala, and the importance of choosing the right examples. Odersky also delves into the practical aspects and technical challenges faced in Scala’s development, especially relating to language improvements and making it more accessible. With Scala 3, Odersky highlights the focus on making the language comprehensive, with fewer 'foot-guns', thereby enhancing both developer productivity and language safety.

Highlights

• Discover how Martin Odersky, founder of Scala, views the language’s evolution and future. ✨
• Learn why engaging examples are crucial when teaching programming to beginners. 👶💡
• Scala 3 introduces fewer pitfalls, improving the language's overall safety and accessibility. 🚀
• Capability checking could be the next big thing in Scala, making programming more secure and clear. 🔒
• The elegance of blending safety with user convenience is becoming Scala's standout feature. 🤝

Key Takeaways

• Scala blends object-oriented and functional programming, making it versatile for various programming needs. 🎭
• Martin Odersky emphasizes the importance of teaching programming through engaging examples, such as games and stories. 🎮📚
• The evolution of Scala aims to reduce complexities and improve safety, particularly with the launch of Scala 3. 🛡️
• Capability checking in Scala, inspired by security systems, promises enhanced safety and functional clarity. 🔍
• There's potential for Scala to significantly contribute to secure and efficient programming, bridging functional and imperative paradigms. 🔧📈

Overview

In this engaging interview, Martin Odersky, the mastermind behind the Scala programming language, sits down with Daniel from Rock the JVM to discuss the multifaceted journey of Scala from its inception to its current state. They dive into the significance of Scala’s unique blend of object-oriented and functional programming, and how this has set the stage for Scala’s enduring relevance in the tech industry.

They explore the intricacies of teaching Scala, especially to new programmers. Odersky highlights the importance of using relatable examples for effective learning, advocating for approaches like game-based learning which resonate well with children and even adults new to coding. This ties into the broader conversation about making Scala, especially the newer Scala 3, more user-friendly and accessible.

Odersky also opens up about the cutting-edge initiatives like capability checking which are being introduced to further Scala's robustness and security. He expresses optimism about Scala’s potential to reshape secure programming paradigms with these advancements, underscoring the language's commitment to combine safety with ease of use, thus empowering developers with a powerful yet approachable tool.

Chapters

• 00:00 - 00:30: Introduction and Guest Introduction In this chapter, Daniel introduces the video and the format change from regular programming tutorials. He announces a guest, Martin Adki, the creator of the Skol language. The conversation will cover various topics related to Skola, including learning, teaching, improvement process, and its future. Daniel expresses openness to feedback and possibility of similar content in future videos.
• 00:30 - 01:00: Potential Topics for Future Interviews This chapter explores potential topics for future interviews in the programming space, focusing particularly on software engineering discussions. It introduces Martin Odersky, a prominent computer scientist and professor, who is known for creating the Scala language. The chapter highlights his contributions to programming and his ongoing work with Scala since its inception in 2002.
• 01:00 - 02:00: Background of Martin Odersky and Scala's Creation The chapter delves into Martin Odersky's significant contributions to the field of programming language theory, particularly focusing on his work with Scala. His research spans code analysis, static type systems, and programming languages, leading to Scala's adoption by major global companies like Apple, Disney, and Adobe. Odersky also established the company TypSafe for commercial Scala support, which later evolved into Lightbend and AA Incorporated. Prior to Scala, he played a key role in implementing Java generics and the Java C reference compiler, both essential to Java developers worldwide.
• 02:00 - 03:00: Teaching Kids Programming with Scala The chapter is a conversation with Martin ODI Professor Adki, where the discussion revolves around the topic of teaching kids programming. The author expresses excitement for the conversation and mentions teaching kids to code using Scratch, which is a programming tool that uses block-based coding similar to Lego pieces.
• 03:00 - 04:00: Challenges Students Face in Learning Scala The chapter discusses the challenges students face when transitioning from Scratch, a beginner-friendly programming platform, to more advanced programming languages. Many students and educators often choose languages like Python or JavaScript for teaching real programming concepts. However, the speaker advocates for teaching Scala, despite its complexity, due to its potential benefits and their personal preference for the language. The chapter touches upon the idea of introducing Scala to kids or beginners, proposing it as an alternative to the more commonly suggested languages.
• 04:00 - 05:00: Scala's Use at Universities The chapter discusses the challenges of using Scala at universities. The speaker believes that Scala is a suitable language for educational purposes, but points out the need for specialized examples, time, and frameworks to effectively teach it. However, these resources have not materialized, and the speaker admits to not having the time or perhaps the skill to develop them, suggesting that effective teaching of programming likely requires specific expertise.
• 05:00 - 06:00: Student Involvement in Scala Evolution The chapter explores the potential of utilizing video games as a progressive step beyond basic programming environments like Scratch for educational purposes. The speaker acknowledges the challenges and extensive preparation required for such an initiative and admits not being ideally suited to lead it. Despite this, there is intrigue and interest expressed in the possibility of integrating video games into programming education. The narrative briefly touches on the speaker's background, noting their role in teaching advanced programming and methods at the university level, including PhD programs.
• 06:00 - 07:00: Improving the Scala Compiler In this chapter titled 'Improving the Scala Compiler,' the discussion revolves around the educational aspects of teaching Scala to students, particularly young learners. The conversation highlights how a hypothetical scenario with unlimited resources and freedom to design a curriculum could impact the teaching of Scala. The speaker, who has experience coordinating PhD students and conducting advanced research, shares insights into how they would approach teaching the language to kids, focusing on introducing them to programming through Scala. This scenario underlines the balance between advanced programming concepts and making the language accessible to beginners, suggesting a rich curriculum that not only explains basic programming elements but also encourages deeper understanding and application in meaningful projects.
• 07:00 - 08:00: Scala 3 vs. Scala 2 This chapter discusses the teaching of Scala by emphasizing the importance of using good examples. The speaker mentions the use of a mixed functional approach and provides an example involving a program similar to those in Logo, which involves a 'snake' navigating a labyrinth. Despite the presence of mutation in this example, encapsulation and limitation of these mutable elements are considered important. The comparison between Scala 3 and Scala 2 might involve these teaching strategies and how new features are introduced and explained.
• 08:00 - 09:00: The Complexity of Scala and Encourage Simplicity This chapter delves into the intricacies of the Scala programming language, iterating on the importance of embracing simplicity in functional design. The key message is to integrate functional programming elements seamlessly, without making it overly complex or intimidating for learners. It emphasizes starting with basic programming constructs like top-level statements, classes, and methods, fostering a natural understanding of functional programming principles.
• 09:00 - 10:00: Potential of Capability Checking in Scala The chapter 'Potential of Capability Checking in Scala' discusses how Scala programming, particularly with methods and classes, fits into learning progression. The narrative reflects on a speaker's experience, illustrating that visual representations captivate learners more effectively. Examples include using games like 'snake' or interactive storytelling where a character, such as Snow White, engages in programming logic adventures.
• 10:00 - 11:00: Future Hopes for Scala The chapter discusses the potential future of Scala in terms of attracting young learners to programming. It highlights the increasing interest of children in technology, including tablets and phones, and suggests that programming could be an exciting avenue for them. The narrative also touches upon parental interest in integrating technology into learning. An analogy is made to the story of Snow White, possibly to exemplify the charm and appeal these technological and educational tools might have on young minds.
• 11:00 - 12:00: Rapid Fire Questions and Closing Remarks The chapter discusses the importance of imparting programming skills to children. The speaker, who is fond of the Scala programming language, expresses a desire to teach it to kids and explores ways to achieve this goal. Though the initial question is self-interested, the conversation extends to addressing beginner programmers in general, not limited to children.

Martin Odersky on the Future of Scala, Learning, Teaching and the Quest for the Perfect Language Transcription

• 00:00 - 00:30 hey everyone this is Daniel for the jvm and in this video we're going to do something different instead of the regular programming tutorial that I usually come up with on the channel today I have a guest and I have none other than Martin adki the creator of the Skol language and we talk about all things schola about learning and teaching schola about the schola improvement process and the future of schola and so much more this is a wide ranging conversation and this is a first for me so if you like this video let me know and uh I might make more of it and
• 00:30 - 01:00 uh I can talk to other influential people in the programming space about a wide range of topics that are important and relevant to us as software Engineers so let me know if you like it and I'm going to take this feedback into account in the meantime let me introduce Martin ersi Martin is a computer scientist researcher and professor of programming Methods at epfl in Switzerland and the creator of the Scola language since 2002 he has been working on Scola as a direct and practical implementation of much of
• 01:00 - 01:30 his research on code analysis static type systems and programming language Theory skull is now used at major companies in the world including Apple Disney adobi data breaks X also known as Twitter and many others he also founded typ safe a company focused on Commercial support for Scola and major Frameworks based on Scola which then turned into lightbend and then AA Incorporated before his work on Scola Marton was instrumental to the implementation of java generics and to the Java C reference compiler which pretty much every Java Dev developer uses so please
• 01:30 - 02:00 enjoy this wide-ranging conversation with none other than Martin ODI Professor adki Martin thank you so much for making the time for this conversation I was super excited and I've been waiting for this for a long time um I wanted to start with uh teaching kids to code I uh I'm teaching kids to code in scratch which is a programming uh tool based on these little blocks that look like Lego pieces
• 02:00 - 02:30 and many uh scratch programmers that uh say overgrow the scratch language they asked me for a programming language to teach them real programming and uh Scala is obviously my favorite language but most of the answers that I usually get when that I usually uh get suggestions for is something like python or JavaScript or things like that have you ever thought about teaching scholar to kids or to very beginning program gmers
• 02:30 - 03:00 how do you think about this um I I'd like to be able to do it definitely uh and I think Scala would be quite suitable for that uh the issue is that it requires a lot of um specialized examples and time and Frameworks and somehow this just doesn't didn't materialize so I I don't have the time to develop that myself um I'm probably not very good at it because I imagine to to teach programming you probably want
• 03:00 - 03:30 to use some sort of video games or things like that as an example as the next step step Beyond scratch or something like that and that requires a lot of preparation and I'm not probably not the best person to do it but I find it very intriguing and uh it would be cool if if we could do it definitely I um just imagine if you had if if you did have the time obviously you're teaching uh more advanced uh programmers you're teaching in University you're teaching uh programming methods and the PHD
• 03:30 - 04:00 student coordinating PhD students and research and stuff so obviously you're doing far more advanced stuff than just teaching the very basic elements of programming but if you had all the time in the world let's say um you had completely free Reign Over uh a uh curriculum or things that you would teach to kids what would you focus on and how would you approach teaching scholar in particular to kids oh H uh
• 04:00 - 04:30 I guess the the importance is always to come up with good examples uh so i' I'd probably teach them um uh in a sort of mixed functional approach but I I guess a popular first example is something like uh what they did in logo like a snake or something like that that that goes through a labyrinth or things like that and that's obviously the there's mutation but you would uh limit
• 04:30 - 05:00 imitation to essentially things that they see moving on the screen and the rest I guess uh you would make functional without without making a big a big uh deal about it I mean you would I wouldn't even use the word I guess just use it naturally I guess uh and otherwise you just start with a simple thing probably yeah uh I mean just top level statements things like that introduce like the uh classes and and and and methods well top statements then
• 05:00 - 05:30 methods then classes that's probably a natural progression yeah in the in my experience sorry to uh uh disrupt the the FL thought um in in my experience I I saw kids very um very receptive to the these visual things like uh uh snake games or even programming stories like Snow White walks three steps and then asks the uh fairy whatever and the fairy gives Snow
• 05:30 - 06:00 Snow White the apple and Snow Snow White says something and the little message displays on screen so they these step-by-step things and they they seem to be quite attracted uh to this sort of thing um I was wondering how you would think about something like that because obviously there are a lot of kids that would like to learn programming they're attracted to technology they spend uh an increasing amount of time on uh with screens and laptops and tablets and phones and things like that and also parents they're very interested in uh
• 06:00 - 06:30 imparting this sort of skill to uh to kids so I was I was very curious how you would approach that obviously Scola is my favorite language and I would be very very happy to teach that thing to to to kids um I ju I was thinking about about ideas of how to do that so this was essentially a very self-interested question uh so um yeah um in in terms of the beginner programmers that you that you saw not necessarily kids but also
• 06:30 - 07:00 adults have you seen uh anything in particular that people struggle with when learning schola obviously you have a lot of experience teaching University students and stuff uh I was wondering what uh what kind of struggles students have when learning to code in schola and uh how you think of approaching that so the the one thing which comes completely natural to us but which I seems students struggle with is
• 07:00 - 07:30 recursion so they seem to have problems with that a lot of them in the in the first weeks or so do just wrap your minds from this uh mindset where where you think in Loops uh to to to think in terms of recursion and decomposition so that's that's hard uh uh I I noted that I I used to give um when in the early days of type save we had like a two-day course and uh I the course course was
• 07:30 - 08:00 the first day we did like the basics and which was like language elements pattern matching recursion these sort of things and the the second day we did like more Library stuff like Collections and things like that and I noted they did a lot better the second day than the first day and and I think the answer is well yes because if you think in terms of recursion or or or Loops or pattern matching you think you need to put many steps together for the final results whereas with collection operations a
• 08:00 - 08:30 bulk operation I just essentially fuse a map with a with a with a fold or or something like that and that's much simpler because there are fewer steps to to sort of conceptualize in your mind so that was interesting uh have you seen anything go ahead please yeah I think I think recursion is really essential but hard for for newcomers in particular probably newcomers who who started with imperative languages and that's basically every everyone
• 08:30 - 09:00 have you seen uh people learn Scola as their first language obviously as a not necessarily as a kid so uh as a um say a wouldbe programmer and learning Scola as their first language have you found this to be the case as well with recursion in the sense that recursion is hard to conceptualize I I don't know because I I haven't really uh seen that uh play out in uh that people actually started with
• 09:00 - 09:30 Scala well they tell me about it but I wasn't able to observe closely to see by what steps did they do this and things yeah yeah the reason I'm asking is because I heard and I know a couple of stories from my own experience with rock the jvm as well when people learn Scola as their first language obviously there are very few but uh they learn as they learn Scola as their first language or functional language as their first language the kind of stuff that we we consider hard as imperative programmers
• 09:30 - 10:00 they're not as hard for them because there's nothing for them to unlearn or wrap their heads around and bypass their current way of thinking they directly think in mathematical terms or rather uh conceptualized recursion as oh the function calls itself for sure I mean yeah and uh I was wondering if you uh if you have seen this sort of this sort of phenomena or if if you know some stories
• 10:00 - 10:30 uh I don't know any part I can well imagine this is this is the case but I think the point is uh even if you start out that wait let's say you start out with an imper with python an imperative language then there is we know there's a progression from like simple statements left go left go right go up to a loop so that that takes some getting used to the loop so basically we go simple statements then if then else and then loops and and in functional it's it's sort of the same thing so calling simple functions is easy but the step to
• 10:30 - 11:00 recursion which is the analog of a loop takes some extra getting used to and I guess I guess probably it helps if you don't know no loops and probably it's it's true that those people have less problems with recursion but I mean even in mathematics recursion is a subtle concept so it's not at all trivial yes yes that that's definitely the case put my academic head on here yeah yeah because I remember when I was uh learning programming I'm I'm one of classical programmers they've learned C
• 11:00 - 11:30 and then C++ and that that sort of stuff and when I when I uh stumbled upon the four Loop like the four structure in C that's completely non-trivial there is a lot of thing there are a lot of things going on in a four Loop in in C there are these components that you have to remember and I remember have struggling with that structure and remembering which piece meant what and stuff I imagine that if I'd learned recursion first I would probably spent pretty much
• 11:30 - 12:00 that same amount of time but obviously that's a that's a hypothesis um so uh yeah uh it's it it would be a very interesting experiment to see Scala being taught as a first language do you know uh people using scol and University to teach beginning programmers yeah yeah there there exist courses like that uh uh even though I I guess for nowadays if the kids start learning learning programming at University more than half
• 12:00 - 12:30 of them have already prior experience but there's for instance the courses by BN regnell uh he's at Lun University in Sweden and he changed the curriculum from I think it was Java before and now they they have the first year scolar and the second year Java and he actually did some some statistics and measurements and had very good experiences with that so the the bottom line was at the end of year two the programmers who underwent
• 12:30 - 13:00 that curriculum scolar 1 Java 2 were better Java programmers than people who's had two years of of java so you see fascinating yeah yeah that was very interesting to read also I think there's another course at Trinity College and uh Lola there there number maybe around 10 universities who teach SCA first year that would that's amazing and and it's fascinating that that uh if you measure the performance of the the Java
• 13:00 - 13:30 programmers after two years of java versus one year of Scola and one year of java this there's definitely proof that scull makes you a a better programmer which is something that we've known anecdotally really but it's yeah to have the data to to back that up yeah I I wish I had aggregated more more data from from uh Rock the jvm but uh all I know is stories but they they really corroborate with uh with this sort of
• 13:30 - 14:00 conclusion yeah um how about your your own students at at epfl how are they finding schola um yeah I think it's it's going uh it's going well we teach it in second year so for historical reasons we actually do start with Java in first year and okay then in second year in a course on software construction uh it's it's a challenging course uh the course has changed a bit over the years so now it's a heavy
• 14:00 - 14:30 course eight credits uh and they they they learn not just programming functional programming scolar programming but also software engineering so it's sort of all in one course uh but generally yeah we have I mean we have very good evaluations students seem to like it uh and um yeah we always get like the occasional student who comes up in the break and says well yeah but you know Scola isn't Scara way too slow uh uh there shouldn't we program everything in C or some
• 14:30 - 15:00 something like that I mean there are lots of misconceptions yeah but of course it's uh it's fascinating that your course is so is so complex I I was I I was under the impression that you're teaching Scola in a in a sort of um programming Paradigm style like a functional programming and teach the the foundations of how how are you incorporating the principles of like software full-blown software engineering into the course um
• 15:00 - 15:30 the essentially teaching the scientific method uh which so it's an I believe it's an interesting approach it was it's my co- collaborator clont pit clell who designed this part of the course so essentially you teach them debugging as an application of the scientific method not using a debugger uh these sort of things but basically what is debugging so I I observe a behavior I have to find out what uh what what I would expect uh
• 15:30 - 16:00 I have to essentially be very meticulous in writing down when the wrong Behavior happens uh and essentially then I make hypothesis I make experiments and uh I keep track of everything like I would be in a lab and uh where I also I can't be sloppy and just mix sub chemical substances and hope for the best I mean you're very systematic you're very very um yeah yeah systematic and uh precise
• 16:00 - 16:30 in doing that and the same thing goes for debugging and essentially also all sorts of software engineering that's fascinating that that sounds like a a course that I wish I I'd had in University if I if I was a student again I would apply for for that course yeah yeah it's fun yeah this is this is great um I I was wondering how uh uh how your your students are involved in the evolution of scol itself I know you have PhD students and
• 16:30 - 17:00 collaborators how are they involved in the uh evolution of scholar well we have uh so right now the team is a mixture of uh of uh Master students who are uh who who essentially spend part of their time in the lab uh PhD students and uh two post talks and um the the students starting with the master students they
• 17:00 - 17:30 actually do a lot in the in the Practical work also they start writing papers but they also do a lot of um uh for instance one does the CI uh the the other student has is is is currently figuring out how to uh get around some um deep sitting problems in overloading resolution these sort of things they love that so they go into that and says okay so we have a problem with overloading solution uh I have an idea
• 17:30 - 18:00 how to make it much better that was already quite quite some while ago unfortunately scalar test breaks um because scalar test using uses some very funky P pattern of overloading resolution and with scalar test basically the 2third of the ecosystem break because they're all using scal test so you can't do that so so the big question is how can we get to San overloading resolution and and and have scar test not break and that's what what he's currently working on so it's sort
• 18:00 - 18:30 of interesting and details to see well yeah we we we identify a problem maybe many people are not aware of the problem but it's a problem nevertheless how can we fix that so so in the case of overloading resolution it was kind of weird um that we um uh what was it uh essentially we uh we use the the uh so uh methods have multiple
• 18:30 - 19:00 parameter lists and we use the first parameter list for overloading resolution so to pick a winner we only look at the first parameter list but sometimes that's that's ambiguous and uh then uh what you think you would do is you would say well let's pick those that are sort of in a tie in the first in the first round and that's among them let's use the second parameter list for a tiebreaker right but but in fact that's not what happens in Scala right now what
• 19:00 - 19:30 happens is you just basically throw away the first match you say they're all everybody's equal now so maybe you find a winner only looking at the second parameter list even though they lost the first one and that's kind of this sort of reasoning is kind of non monotonic and it's it's kind of weird and and we don't want that but it turns out that as always uh that uh once once you have a certain weirdness then there's already software out that exploits it and our case it was Scala test which is of
• 19:30 - 20:00 course a bit problematic yeah so stuff like that this is this is very interesting and I wanted to uh stay here a little bit longer because I uh I think that very few people understand and appreciate the kind of process that goes into the The Scholar The Scholar Evolution uh it's very easy to criticize it's very easy to consider I don't know hey the compiler is slow or that that sort of stuff but you can't really say that until you appreciate app the kind of the kind of work that the compiler is
• 20:00 - 20:30 doing so that you can have the strength of the type system so uh I have several questions here that I mean this is this can Branch out uh in many ways one that comes to mind is uh how is uh you T you said something about scholar test breaking your intended change in the uh in the scolar uh in the scolar compiler I was wondering how the process works in general if you want to add a feature in in the language or if you want to make a
• 20:30 - 21:00 change if you want to fix a bug uh what's the general process how how does this work and from inception to the Scola 365 or whatever the version is okay so first uh there there would be typically an issue that's opened and then uh somebody will get assigned to it uh or somebody volunteers to do it uh and uh then one looks at the issue one has a
• 21:00 - 21:30 hypothesis how one might possibly want to fix this uh so you go in the compiler you do the fix uh then you see what what tests break so we have maybe about around 10,000 tests or something like that so you see whether where the tests break uh if all tests succeed then you check in the CI uh we also have um about 30 30 no about more like 40 projects in the community build which is like most
• 21:30 - 22:00 of the big ones like Scala test is one of these AK Zio cats effect these sort of the The Usual Suspects um so they they must all be green or maybe some of them if if some of them are are R then you have to go into their code and analyze well is that actually something that uh uh should be a bug because sometimes we have like things soundness problems or tightening of the rules where we say well some code out there uses a thing which is actually known to
• 22:00 - 22:30 be unsound so in then in in that case we have to make a a proposal that they should fix the code and we have to sort of see uh in our version in our Co copy of the code to see whether we can fix it for them and then Upstream a PR for for for their thing so we do that yeah go ahead please and if all that is green then uh every week or so uh this uh verus lab has the open Community build which is about 1,500 projects which uh
• 22:30 - 23:00 essentially runs with the with the current version of Scala and uh which flags regressions and if there are uh regressions then they get flagged as separate issues we have to look at them we have to decide whether these regressions are serious or not and uh whether we have to maybe roll roll back our changes which often which often happens uh as well or whether we we say well these recessions are actually also uh problems in in the in the code of
• 23:00 - 23:30 these projects which which is fixable they workaround so we can maybe ask them to fix it so that's sort of a typical process of a a bug which is not completely trivial of course most of them but some of them are fine it's it's a clear bug we fix it everything stays green we move on so not everything is as complicated yeah and we're talking about the scolar compiler here it has dozens of phases I I think it has how many phases does call compil have well it has
• 23:30 - 24:00 close to 100 okay these are well I have to I have to uh qualify that these are not really faces they are called mini faes so they batched into into faces uh and those micro phases that run the mini phases those that are run standard for every program are about about 10 maybe a bit less than 10 something like that yeah yeah what I wanted to say is that the scull compiler is not really your your day-to-day piece
• 24:00 - 24:30 of uh software it's a a complicated thing and I I often consider compilers and uh uh operating systems as pretty much close to the most complex software that there is uh because there are so many things that can go wrong and uh everybody relies on everybody relies on you and you have to have a a massive amount of accountability and uh responsibility to uh be able to get into that into that
• 24:30 - 25:00 sort of thing I I certainly uh would think many many many times before I would commit something to something like this to the scull compiler so I just wanted to say that I I appreciate this the the kind of work that you and your team are doing uh into the scolar compiler uh what do you think is the uh the bottleneck for you right now in in terms of the evolution of the Scola language where the Scola
• 25:00 - 25:30 um I think the the bottleneck is uh contributors who are experienced enough that we can essentially rely on them to work without handholding there are we have them we're fortunate to have them but we we could always use more of them and you become somebody who is has that level of seniority only by being first a junior contributor and then essentially
• 25:30 - 26:00 progressing uh so so but it's sort of the most the most the bottleneck is really people at the end of that progression that have to Mentor the others that's a very limited resource yeah uh I imagine that's uh uh it's a big burden on their on their time and on their schedule because not only do they work on some of the most complex software there is but they also need to Mentor other people and uh help them or guide them uh I don't know something breaks on their ends the CI breaks or a
• 26:00 - 26:30 project a community project build fails or or something like that so I met but overall I I think we are in in reasonably good shape now so it's it's it's I think the compiler itself is relatively stable uh we haven't heard many complaints about compilation speed maybe computers are getting faster the compiler also got got faster yeah uh I guess it's also that a lot of the competition got slower or maybe people
• 26:30 - 27:00 are waking up to that not every compiler is as fast as go or Java C which are compilers that can be very very fast because well first there's a lot of Engineering in them um but also what they compile is a lot um less dense than what Scala Scala compiles so if you say a a typical scalar program is maybe a tenth of a Java program just to pick a number maybe it's two or five instead then uh you would expect that at least
• 27:00 - 27:30 given the information density the compiler would be 10 times slower and people wouldn't complain yet they do complain uh because it just feels to them that uh yeah it's definitely the case I mean uh how do you uh how do you convince people that uh I don't know scholar 3 is the language to go or that they should migrate or that they should rely on scol 3 for their business or for their project um well we we had uh
• 27:30 - 28:00 a we have a constant series of talks in which sort of say where where scalar 3 is better than scalar 2 so that clear advantages to changing it's a it's it's an allog together better language and quite a Quantum Leap I would say so it's it's not a all the same as SC to U but then well it's it's up to the well we we we were fortunate that I think the
• 28:00 - 28:30 ecosystem of the core libraries uh that they M grated in reasonable time so some were faster than others but by now basically they're all on scalar 3 uh so so that's really good that means that uh it's really a extremely extremely long tiny tale of projects which well no let me qualify that uh I think the big problem is spark but even spark is so that you can use it from Scala 3 because
• 28:30 - 29:00 Scala 3 and 213 are uh are interoperable and Spark is B I think basically now on 213 it's on 213 yes yeah yeah yeah that's right yeah so so even spark is basically solved now even though it would be nice if there were in Scatter 3 but well that's uh that's isn't in our power to yeah to that yeah it's it's going to come at some point I I imagine um I was wondering what would you what you would say to people um about the so
• 29:00 - 29:30 you mentioned that the scar 3 is a is a league ahead of Scar 2 as a Quantum Leap ahead um in what way is scar 3 uh and I'm asking for the the audience here that would like that would like to understand the details in what way do you uh do you think that SCA 3 is a giant leap ahead of Scar 2 some people would consider scull and the reason I'm asking this because I see some comments in my own private
• 29:30 - 30:00 community at Rock the jvm saying that Scola 3 is just Scola 2 with a few keywords changed like using given instead of implicit uh using like a few uh a few bits and pieces tweaked here and there uh but they are not necessarily getting the idea that SCA 3 is a completely different language with complete a complete a completely replaced foundation so I was wondering what you would say to uh this sort of comment uh yeah so so I mean you don't see the
• 30:00 - 30:30 foundations so so it it is built on a different Foundation or but on a on a let's say scalar 2 uh the foundations haven't been really developed very much with Scala 3 we had them that that influenced the language design uh but then on that level I mean it's not it's not a completely different language it's still scalas right so so two to three uh but it's still it's still the the the language family it's still
• 30:30 - 31:00 recognizably Scala uh the the main difference is uh a lot less foot guns so a lot of the things that uh people were got got bitten in Scala 2 where they say for instance stay away from implicits implicits are super super dangerous and things like that I mean they're very powerful they can still be dangerous but I think we removed a lot of the of the things that bit you and that where people developed cumers and workarounds and things like that and we're still
• 31:00 - 31:30 doing this so we we're just now shipping the the Reversed priority of implicits which solved a lot of problems so uh we we see that in existing code that everybody uh had sort of super complicated hierarchies of uh manual priority of implicits that where essentially the implicits in your libraries were added in in many different versions and uh uh that's no longer necessary or another example is the the way we do uh import
• 31:30 - 32:00 suggestions uh and and the way we we reorganized the scoping of implicits uh in scalar 2 people were uh bitten a lot by just missing a crucial implicit import right you say why does my my program not run well well you should do this uh this incantation import cats do syntax do do underscore something like that and if you didn't do this you were completely on your own just nothing would work anymore and these sort of
• 32:00 - 32:30 things they they are behind us in Scala 3 so in scalar 3 it's clear it's uh first the the way we uh we organize implicit systems you should in with newly designed libraries you should rely a lot less on the sort of uh Wild Card Imports that import the world for you I don't think that with a well-designed systems that's not necessary anymore and second even if you need still need to do that the tooling
• 32:30 - 33:00 gives you hints and doesn't doesn't block you so so it's part tooling and it's part uh part language uh language came first but I think with tooling we also made important advantages advances this is going to this is going to be very interesting and valuable and I'm saying this because I Was Bitten in the past Myself by the lack of knowledge of which kind of magical UT I should add to my code and and no nothing would work I would see red everywhere and uh I would
• 33:00 - 33:30 frantically search Google or stack Overflow or here in these days you would ask a Claude or an llm hey what's what what which import am I missing um but uh this is going to be very interesting if if you don't have to rely on these magical Imports because it's really a bottleneck uh if you're obviously if you're experienced and you know the library inside and out if you don't know HD HTP fors or cats effect or whatever if you know them by heart then yes you
• 33:30 - 34:00 have all the Imports you have you you write them by reflex you don't have to think about them but somebody who doesn't know that which is basically 99% of the people including myself they get they get bitten by the lack of uh the presence of implicits how a how a system like this work I mean you said something like that uh uh if you design your library well you shouldn't rely on on implicits uh without getting into too many details because we're we're speaking right now and it's hard to to look at code How would how would
• 34:00 - 34:30 that look like no on implicit Imports it's implicit Imports yes not not on implic themselves sure they're mostly there for instance all these syntax inputs are mostly there to support operators U and uh the it's essentially the way we put extension methods with given together that avoids that so you can now basically write these methods where they make sense and you'll automatically get them you don't need a a special import support to essentially support some some some
• 34:30 - 35:00 operator Syntax for these implicit libraries so that's a main advantage that you don't need that anymore this isy how how Givens and extension methods play together okay yeah yeah extension methods is another thing where I really think that that was a breakthrough because uh uh I mean other languages have extension methods like cotlin has them and dart has them I think yeah uh uh but the way that we can actually essentially have
• 35:00 - 35:30 abstract extension methods in a base class like for an implicit where we say we have I don't know an ordered and it has a less than or equals operator and that's just essentially an abstract extension methods in the order ordering uh class uh so you get that when you have an ordering you get you get the infix operator you don't need to import that with a separate import that's and and that works because extension methods can be abstract uh which I'm not sure they can be in C and because they can be punched together in a in a class which
• 35:30 - 36:00 are sort of um this punching together is something that dark new and uh so we sort of combined the best of both both worlds and I'm I'm I like to talk about it now because this was really actually very very hard I think we went to through three or four designs with that I knew we wanted extension methods in the end uh but the first designs were always improvable and uh so we're very happy with the final
• 36:00 - 36:30 final version we have for that they are pretty cool and uh just a note to people that this kind of work is hard and uh I I wanted to send a personal note of thanks to you for this for this work because it's important work and it's and it's very difficult and we never see this uh if we did if we saw like 1% if we had to do that the even 1% of the work that you're doing to like fix like the tiniest thing I think we would all get a much more appreciation for the uh for the kind of work that you're doing in into the scolar language um you said
• 36:30 - 37:00 something about tooling that that tooling is going to also help with these sort of issues that used to bite in scolar 2 uh how are you thinking about this how are tooling uh how are tools evolving in that sense uh so so so I think where we made advant advances was this particular mechanism of import suggestions uh it's not only
• 37:00 - 37:30 for for for Givens but also extension methods and others um uh the the other thing is really the engineering of the error messages where uh I think Scala 2 was for its time um state-ofthe-art but the state-ofthe-art has advanced a lot over the last 10 or 15 years so we're not alone other languages have much better Arrow messages now as well but I think SC in got to three a lot more space uh like they are longer they have
• 37:30 - 38:00 hints they they explain stuff and thought has has gone into error messages than than before and that's also uh helps learnability discoverability of a language and we could improve further so for instance it would be nice to have more tool tips or things like that to say if you have an error you could maybe maybe um already give them a hint how to fix it or things like that or maybe even suggest it then in in an IDE to to have the IDE fix it for you so that's sort of
• 38:00 - 38:30 a would would would be a nice further Improvement that would be amazing and U also in the age of llms where you would have to like I don't know ask cursor or uh the IDE to solve it for you yeah and and again it's a lot of detail so so one one thing that was particularly uh innovating in scalar 2 for is that you say uh let's say it's a type mismatch and it says found list of tea required
• 38:30 - 39:00 list of tea I said what what what what are you talking about and you you do get these things so they maybe maybe not all the time but you do get them and uh what we do now is that if that happens in the the essentially the error message handling we'll figure that out and we say oh yeah of course they're two different T's otherwise he wouldn't have an error and then it would say well if there are actually two things that both print T but they're different then it will explain to you that will'll give little superscripts on both of them and
• 39:00 - 39:30 we'll explain to you what they are and where they come from so that so you're not you're not in this in this uh puzzled state where you say I have no idea what the compiler is just telling trying to tell me here yeah error messages are uh really I mean they save the day uh if they're designed correctly and uh I'm really happy that this sort of work is being added into into scull um and also into tooling because in the developer experience you you have uh you're dealing with errors literally all
• 39:30 - 40:00 the time so as as you're writing code you don't end up with correct code from from the outset so you have to you have to be guided by the error messages and you know you're making progress as a programmer when the error message changes so when you you get into an error then you you fix something and you get a different error that's progress you know yeah so yeah uh this is this is super important uh and speaking of tooling I was wondering if you uh or how do you deal with uh the pressure from
• 40:00 - 40:30 the community or the industry to balance uh language changes or the the evolution of the language itself versus this sort of developer experience kind of problems like tooling or uh error messages or compiler speed or that sort of thing how do you how do you balance the two um that's uh um I don't think there's a clear
• 40:30 - 41:00 partition between the two um mostly we try to do both but uh with the resources that we have but it's it's sort of a lot of it is opportunistic so um it's not really like let's say improving error messages uh we don't really have a person who is tasked with doing that it's sort of if somebody sees a problem and they see an error and said oh this could be formulated better then
• 41:00 - 41:30 it would be great if this person has has time to actually work on that or tell somebody else whether they could work on that uh it's it's a it's a bit of a but it's true that I mean we should it would be nice to have more resources to to do that generally the tooling things are well if you if you talk about smallish language changes and which we didn't really do many anything different
• 41:30 - 42:00 than smallish language changes the effort that goes in tooling is at least on order of magnitude higher so so these are trivial compared to like even fixing one type inference bu yeah I mean yes because it has so many moving parts and if you break something in the type inference then the whole work can break really typically new feature is Green Field so you don't conflict with anything uh of course you have to make sure the syntax is unambiguous and things like that but these are sort of known Technologies techniques to do that
• 42:00 - 42:30 this is not very hard and how about the the uh the desire from the community to implement or remove features in the scar language itself like the requests of the language itself how how do you deal with them is there a process or how does this work so there's the the zip process the Scala improvement process and uh that uh so we have a there a very detailed document that that writes up how how how that works so
• 42:30 - 43:00 uh anybody can make a proposal what you do if you have a proposal is you first go on the contributor Discord U uh and you uh you you make that proposal there uh you get a community discussion going on the proposal if the community discussion is generally positive then you're encouraged to submit that as a pull request to the zp website where once there's a pull request it will be assigned a number and the committee will essentially give it a first review and
• 43:00 - 43:30 uh then the committee can essentially say well we want we accept that uh uh or we want refinements or we don't think this is a good a good fit for scar that's POS possible outcomes if it gets accepted then uh then it's not in yet that's the implementation phase then then essentially the the community or people or is invited or sometimes we take take it on ourselves to do it to to to actually have an experimental
• 43:30 - 44:00 implementation so then it's typically under an experimental language import uh that you can turn on to get the feature and then there's a second vote after some experimentation and experience to say have any problems come up with this feature if if not if every and it looks like we still want to have it then uh the second vote is also positive then this makes it into into the language now we actually have even a another stage that we optionally will have for many of
• 44:00 - 44:30 the new features that's a soal So-Cal preview stage which says that but the thing is in the language but for One release or maybe two releases you have to still uh enable a preview flag to get it but preview is sort of much less U drastic than experimental experimental is sort of really uh behind a lot of security fences that you say if you have something which is experimental and you put that in a library then all your clients must be experimental as well so
• 44:30 - 45:00 experimental is viral to in order to prevent this the the virus escaping from the thing that's such a good idea because I mean this kind of prevents the being bitten kind of phenomenon that that we used to see right yeah we we we learned from that for compared to the Scala 2 macros which was exactly this case so we were not ready to release scolar 2 m and everybody made libraries with scar macros and were I obviously exactly yeah but but we said
• 45:00 - 45:30 well at the time we said well it's it's fine we just make them experimental that will signal the community that they're not ready yet to to to make this a standard feature but of course nobody cared they just turned on experimental and in their Library uh but then of course the the the the end clients didn't have to do anything they could just use it so we learned from that to say and maybe we're too strict now we we're really very very strict with these experimental things maybe we have we should Len up a little I don't know I
• 45:30 - 46:00 mean it's probably a lesson that will evolve in time uh because uh the Scola Mac the Scola 3 macros are are also incredibly powerful but they're also very sane so I think people will still continue to build uh really powerful libraries and uh like they a very similar magic to you what used to exist in in scholar 2 but with also the uh nice fencing and security and good practic being built so I think this is an evolution right yeah yeah you learn
• 46:00 - 46:30 the main issue with macros uh was that there were two issues but one of one issue was that uh they really expose the the compiler data structures whale so they all were basically you just got got at them the way the compiler was treating things that's that's the view you had in the macros and that means that once we once we did a new compiler for scalar 3 uh these MCR had to die because they were tied to the old compiler so and we so so essentially you
• 46:30 - 47:00 can't can't swap your compiler without swapping the macro system and of course that's not a good State of Affairs you need to abstract you need to say well essentially how can we represent meta programming without reference to a compiler with all its galy flags and options and things like that uh how do you think the uh the the ecosystem is uh evolving towards scar 3 given that so many powerful libraries were were based on Macros obviously those macros had to
• 47:00 - 47:30 be Rewritten how how how do you feel the evolution has gone in that direction well I have the impression that there they have basically the the the large majority I don't know of any important cases of libraries using macros that have not migrated uh there is probably a long tale so that we have to live with that but all all the big ones have my migrated and that that is the one bit
• 47:30 - 48:00 which where migration from 2 to three is really difficult because you have to rewrite this code and sometimes even change your whole approach because maybe the old approach that was based on untyped trees or something like that wouldn't work anymore so that that was a lot of work uh we we knew we had to do it because well if you want a new compiler you you can't have the old micro system uh and I'm glad that that's most behind us now so from now on it should be much simpler yep um how do you uh
• 48:00 - 48:30 what do you think at this point so Scala has evolved throughout the years we're upon the 21st birthday of Scala this year um what do you think scala's strengths are right now at the as it currently stands and the reason I'm asking is because scull used to be at least when it was propelled into the mainstream it was this very interesting and fun language that Blended uh
• 48:30 - 49:00 functional programming and object-oriented programming in a very expressive package and so it gardened a lot of interest with a lot of U very enthusiastic developers like hey this is a fun language this is super powerful we can write distributed systems oh my God we wrote we wrote Twitter uh we we can now process billions of tweets and whatever with with a a pretty uh vanilla version of scol obviously they made their libraries Futures and all that but the uh pretty basic usage of Scola what
• 49:00 - 49:30 do you think scola's current strengths are at at this point so one so I think so first Scala is a combination of object and oriented and functional uh the industry has uh I mean has moved a lot into that space so essentially a lot of the previously object oriented languages like Java became more fun functional over time that means they adopted more
• 49:30 - 50:00 features that you typically find in functional languages they didn't adopt so much the philosophy to have as little mutation as possible but uh but the features are there so lambdas streams pattern matching records all these things that got added to Java um the the other thing where where Scala shines is this combination of um safety and uh and convenience and I would add Simplicity uh uh as as a
• 50:00 - 50:30 third one even though people are scared but I think that this being being scared of Scala is mostly that it it's so expressive because it really gives you no no restrictions that don't make sense it's not a it's not an agglomeration of features it's more really an orthogonal uh Fusion of of function and object oriented so I think overall conceptually the language is very simple uh and uh at the same time very powerful so
• 50:30 - 51:00 uh that the other languages don't have so much because they are more agglomerations of features you could say you bolt on some functional stuff to essentially an imperative object oriented core but I think Scala always shines and continues to shine in this combination of safety and and uh and convenience uh that that you say it's it's it's it's a low ceremony simple thing things generally work like they they they advertise to do so essentially
• 51:00 - 51:30 if you write a thing then it does what you think it does and at the same time Alo in that sense it's quite close to let's say python for to mention another language but it has a really solid powerful expressive type system to sort of uh uh save you have your have have your back if uh if you want to scale things up so that's that was always the the advantage of Scala and I think it
• 51:30 - 52:00 continues in that direction to to be a Pioneer so we try to make it both simpler and more convenient and safer so that's essentially the the idea yeah this is an interesting combination of safety and convenience because the way that scull was originally advertised was this scalable language in sense that you could start like a prototype in just a few lines of code and then you can still stay within the same language and obviously get exposed to the entire jvm
• 52:00 - 52:30 ecosystem but literally stay in the same language and build a product as big as you want while maintaining yeah yeah and and the the or original adopters of Scala a lot of them came from from Dynamic languages like PHP or Ruby in the case of Twitter uh and that was so sort of the same thing so they found the dynamic language is very convenient no ceremony and boilerplate of static type systems at the time but they wanted the safety so
• 52:30 - 53:00 Scala gave them both I think and and and it ran on a solid platform the jvm that's also important and how what would what would you say to people uh that are scared of the apparent complexity of Scala uh just by virtue of the fact that Scala gives you so much power that it's overwhelming really because you if you look like if you look at let's just say uh look at uh the features of scull you have higher
• 53:00 - 53:30 kinded types you have uh various contextual abstractions uh and somebody gets scared of the kind of power that they use that they can use that's on the one hand on the second on the other hand in the in the realm of safety uh you can design libraries that are so restrictive that it's overwhelming uh the amount of complexity that you have to go through just to make things work so uh for example uh if you look at uh
• 53:30 - 54:00 effect systems they can get really really complex like really powerful and uh if you look at a library like http4s if you want to spin up an HTP server you kind of have to sit for 30 minutes just to make the compiler the compiler work uh and not it's not the fault of the compiler it's just how the library is designed so that it doesn't compile until you have everything set up whereas in Python you write like two lines of code like import serve serve serve. serve at Local Host 880 right and so by
• 54:00 - 54:30 by this contrast you could uh you could argue that there is a an apparent complexity to schola that could scare people off how could we make sure or uh encourage people to try it out and see rather the convenience or the ease of use of Scala in the style of python even though you can go the other way and how the the apparent complexity well I mean it's it's true so
• 54:30 - 55:00 you can go away you can go the other way also in lots of other languages so for instance if you look at a typical Enterprise Java codebase is probably also quite quite scary and complex and unwieldy and things like that uh the thing is that uh usually you say well Java is you don't say Java is complex you say Java ecosystem is complex uh because a lot of the stuff is actually not Java it's XML and and and other
• 55:00 - 55:30 other files and whatever and I think in in Scala the problem is it's all sort of it all has all the complexity you see is in a file with a DOT Scala extension so it must it must be scalar there's there's very little I can do about it I can only appeal to to the community to sort of uh use the principle of least power and keep things as simple as as as appropriate and I think that we
• 55:30 - 56:00 are uh generally not doing so well in that thing in in the community I mean there are things that for instance you mentioned like web servers and things like that I mean you could have used cusk cusk is basically directly inspired by python flask and it's I bet you it would be much simpler to get that running um the so the one thing where I believe we are we we're seeing a change is uh that a lot of the uh justification
• 56:00 - 56:30 of this complexity came essentially from two sources uh one was uh reactive programming because we didn't have uh virtual threads or cortines on the jvm you had to invent something so so AKA invented actor actors and CIF effect invented essentially the the effect systems and Zio is is another example of that uh and underneath them in both cat effect and z are essentially very sophisticated
• 56:30 - 57:00 heavy duty schulist that essentially let you run massively uh concurrent applications that can process millions of events and things like that which are sort of masterpieces of Technology I'm sure but they are sort of for this specific use case where you need the scalability if you're Netflix or Disney or something like that you need that that stuff not everybody does what do you think would be needed in for like product development in in that sense U can just like easy libraries to
• 57:00 - 57:30 use or what would you well I I so I compiler is so I I basically only work on compilers I don't have time for other things and compilers are very specific things because compilers don't like any sort of dependencies yeah no not adding things into the compiler I was uh if I look what other people are doing then I I think some like like how you stack is probably a simple simple way to get
• 57:30 - 58:00 started and uh I talked with how and he said he's actually deployed that widely at data bricks and there there 10,000 servers running this thing and uh and it's it's very very scalable even with normal processes and it should better once you have Loom and cortines so I think that that's the one SE change that you say now that essentially uh fine Grand concurrency is built into the jvm with loom and uh uh we we also have it in Native with cortines and even ways to
• 58:00 - 58:30 do it in in web assembly in JavaScript or there might come soon so once we have that uh we don't really need to to have our own Library based uh super uh lowlevel schedulers and things like that they might still have the edge I don't know I mean there they're good pieces of Technology but there's definitely competition they're not the only the only game in town here so so so now you can just use what the what the platform gives you and I think the other thing is
• 58:30 - 59:00 that there there was a and still is I think a bit of a um glorification of uh uh of uh pure functional programming and um and uh super super refined types uh I'm not against that at all I mean I'm I'm I'm in wg2 2.8 which is the the working group on functional programming and I'm good friends with Simon pton Jones and
• 59:00 - 59:30 Phil wler and all the people so I know what it is and but I also know that it can be exaggerated so so there they are diminishing con returns for everything and that includes uh full Purity and and uh essentially uh uh expressive expressiveness with typing so you have a choice in Scala you can be as fine Grant and Co Grant as you like and as usual the the the the the optimum is somewhere
• 59:30 - 60:00 in the middle and not on one of the extremes is is my is my opinion here so I think that's sort of if the the the community can sort of take uh follow a bit more that that advice then I'm sure we would have simpler software in the future and I think we I'm seeing seeing a path to there so uh I'm reading this as um just write simple Scola because Scola is powerful enough and will'll give you pretty much all you need if you want to go like super complex you can go there
• 60:00 - 60:30 but it will get you very far just with exactly yeah yeah yeah yeah okay uh I was wondering if you uh I mean this was a uh this was a question that I had in mind while while you were explaining this U uh this blend and the the the trade-off between uh Simplicity and uh con convenience uh not the trade-off but the the the blend um mhm and I was wondering if you have if you if we were
• 60:30 - 61:00 in not in 2025 but we were in 2012 or 2013 and we we would go to Java conferences again and start talking about Scala but the way it is now what do you think would be a an underrated or uh really valuable piece of Scala that would be very appealing to Main stream programmers you mean in 20 2012 13 or
• 61:00 - 61:30 now now so with the current state of Scola how would you uh how would you appeal to the mainstream the mainstream yeah yeah um that's a good question um the it's it's diffic so so the the thing is
• 61:30 - 62:00 you can say well we have lots of uh uh a very good blend of features that work well together but it's hard to sell that right you you say well every language has sort of similar features nowadays and everybody says well but I can do this in my favorite language uh in in a slightly different way but I don't see the problem or things like that so you can say well it's really put together well it's simple to get into it's very safe uh it's uh quite powerful in terms
• 62:00 - 62:30 of runtime because of jbm um the the other thing is if you want an edge like this functional objectoriented was when Scala came out that Scala was quite in that in that thing then what we are betting on is that the the the next kind of edge is uh systematic um support for capabilities uh that's that's still but that's sort of what what I'm betting is that I mean rust is making
• 62:30 - 63:00 quite a splash uh deservedly so I think it's quite a quite a big step ahead but simple it is not so uh I think there will be quite a lot of per people very soon who are burned by rust and say well no this is super complex because the way it typically works and we've experienced that Firs hand and Scala is the first generation that gets into into a language is uh ex is excited uh is very
• 63:00 - 63:30 excites others uh uh they the Trailblazers and they're typically technically quite quite quite good because otherwise they wouldn't be looking for new technologies and then the second generation comes when the first has long left the project and they see all this code which means nothing to them which just looks super complex and they they then uh go away and bad mouth the thing and say well this is terrible terrible Coke B and things like that and I believe every technology is sort of
• 63:30 - 64:00 software technology has sort of this life cycle you can't avoid that and I think rust is sort of at the beginning of that life cycle it will come that people will find impenetrable code bases that are very very hard to to to to to change why am I saying that is because I think that with capabilities we can have something which has the functionality of what rust gives you today in a much much simpler package so that's sort of the BET and I can't really substantiate that
• 64:00 - 64:30 yet much because it's we're still working on it uh I'm quite excited what what what we have and what what we're doing next so it's looking really interesting but it's it's working progress so what is U uh for the people who are listening uh or watching here on on YouTube or other platforms what is capability checking and how does it work okay so um the the basically
• 64:30 - 65:00 accountability is just a a value an unforgeable value that gives you a permission to do certain things so cability systems have been with us for for very long they are essentially a proven mechanism in in the security field probably the longest standing most solid mechanism there the operating systems built around capability there's even experimental Hardware that supports it U uh so they are a way to make large
• 65:00 - 65:30 systems safe because a capability lets you interface with untrusted code uh without uh without violating without fear that this code might call you back and violate some of your invariance so basically capabilities let you let you mix trusted code code that you've written yourself you you trust your code hopefully with uh other people's code or maybe code that's untrusted where you don't know what it is because every piece of
• 65:30 - 66:00 code every component can only do uh what it is permitted to do with a capability that's basically the idea so if somebody calls you back with let let's say a critical internal API and it's untrusted code you don't know what they do then you can protect yourself by saying well if you want to perform this operation then you have to present the capability to do so and if I haven't given it to you beforehand then you won't have it because capabilities are unforgeable values you can't just forge it so that's
• 66:00 - 66:30 that's the idea and it's it's very very old the the first cability system is from 1966 so it's almost uh 50 years old uh but it's been an important technology um now you could say well why hasn't it hasn't it made it into mainstream there have been a couple of of of attempts like Joey by Mark Miller for Javas script and things like that but why hasn't it made it m mainstream and I
• 66:30 - 67:00 think the answer is well capabilities are values that you have to pass as to code with essentially uh to the methods that you want to invoke so you have to pass them around quite a lot and that's just tedious I mean you might end up with I don't know dozens of capabilities that you have to handle and you have to pass them around imagine all these horrible parameter lists for these things so that's why it hasn't caught on that a pure capability system is super simple you just pass these things around as parameters basically and there's
• 67:00 - 67:30 little else you can do with it you can't store them in global values so things like that it's a plal dependency injection all over again right I mean uh yeah in a sense yes in a sense it's exactly the same it's why dependency injection had these millions kinds of Frameworks for doing the same thing because all the dep hard to parameters exactly yeah and and Scala has has the answer with implicit parameters that uh is is a is a very solid way to to use that and a way that we know really works
• 67:30 - 68:00 so if you if you use it in this way then then you won't see any of the tedium of passing around these capabilities and the the way we do it that you can even avoid them having them to pass them at all at run time so you could say well maybe you don't have to write them but it's still a dragon a system to have to pass all these parameters it depends how you set up your capabil ities but there exist the thing of what we call erased capabilities which which you need only
• 68:00 - 68:30 at compile time that so that the type Checker says well you really have the permission to do these things you don't need to have a proof at runtime to present that so so that that's that's also possible okay so that's essentially the the capability based systems uh and the the tricky bit what we what what's new what we need to do is so these capabilities typically you have to make sure they don't escape so you pass that capability to something so what you want
• 68:30 - 69:00 to avoid is that other party stashing away your capability maybe in a global variable or some object field or something like that or maybe hiding it in the function result so that uh you you return an object or a Lambda that still can has access to this capability because then you can't b b bound the the capability is lifetime so you want to say well I have I give you capability to change this piece of store uh but when when you return to me that capability is cancelled you you won't be able to do
• 69:00 - 69:30 that anymore so you need a type system that tracks that or or a runtime system but in our case it's a type system that tracks essentially where capabilities can be propagated uh so you can prevent them from maybe being stored in variables or being returned in in in hidden in in results or things like that so that's the first thing and then the second thing is that you also want to have another restriction which says with capabilities you want to have a notion
• 69:30 - 70:00 of an exclusive capability so for instance I have a database and I want to write the database and I can't have a concurrent right with somebody else I want the capability exclusively on the other hand if I just want to read it maybe that is a shared capability that I can share with others uh so you want to distinguish the two things and once you are there then you are essentially you have a capability based uh uh conceptualization of what R would
• 70:00 - 70:30 typically do with a borrow Checker so R the Bor Checker doesn't work with capabilities but it's it's essentially the same power and we uh the hope and I believe the expectation by now is that it will be a lot simpler than than a borrow Checker it will be a lot less notation and a lot s a lot simpler to to write correct code with that with that notion and how is the uh uh how's the uh capability tracking uh going right now
• 70:30 - 71:00 how's the how's the progress uh so we are um uh we are about to roll this out that it can be more more widely used so uh in one of the next versions hopefully very soon we'll have a standard library that is uh annotated with capabilities because the point is right now you can use it so it has a it's a language import it's called language import language. experimental capture checking
• 71:00 - 71:30 um but uh the the issue is as long as the standard Library isn't annotated you can only do little stand alone projects where essentially you have your own data types that that you annotate with your with your thing um so the next step would be to annotate the standard library and collections that's done also uh but um we still have to make that widely available in a release that other people can use it so we we have been using this internally for a while
• 71:30 - 72:00 already um and then the the the next thing is to um uh essentially add this to to to to to a to code to a library stack so there again we have made some progress so we have this gears project that by now is also capability checked uh so that for instance lets you uh say if you have an asent context so that's a context where you can suspend so you
• 72:00 - 72:30 can't basically try to suspend in code that g doesn't give you the right to suspend and you can't you can't sort of leak that that capability either uh and then the next step after that is these exclusive capabilities which are sort of right now they're not merged yet but they are very they soon to be merged maybe tomorrow or something like that we'll have this W okay still Edge yeah so uh at this point you're going to make it experimental and uh then you're going
• 72:30 - 73:00 to roll it out to a wider uh to a wider group or how do how would this work to yeah then we roll it out we hope that once it's uh out as experimental and we sort of have caught up with the docks and things like that and are actively promoting that that other people will use it give us feedback and depending on how that goes it might find it way in in a future Scala I I hope it will but uh I I can't promise anything yet I think we
• 73:00 - 73:30 have a have to do a lot more experimentation with this but to find out whether it has legs or not just to make sure this is this is going to be uh backwards compatible with uh the scar 3 generation and this is going to get into the scar 3 yeah yes it's it's it's going to be backwards compatible so we are not uh yeah it's going to be possible to make it backwards compatible and for and we will in the first versions yeah so there are other things that uh might you
• 73:30 - 74:00 where where you might want to exploit um a new library design because capabilities give you more power so for instance um in the in the Scala Library we have these immutable Collections and mutable Collections and and the common collection super type that can be both uh basically the super type says uh you can't M mutate but somebody else can mutate the collection and that is uh I
• 74:00 - 74:30 think a solid design but with capabilities you can actually do get a much simpler design you can have the same array let's say which is both mutable and immutable depend depending on what kind of capability to you attach to it so uh notationally you would say if it's a mutable array then you would write write array of T hat with the Arrow so that gives you the right to mutate this array but you drop the hat and then you can only read it and if you
• 74:30 - 75:00 return a fresh array then uh the in in a and you don't um you don't return it with a hat then that's actually an immutable array so it gives you the sort of transient capabilities where uh you can mutate the array and uh to initialize it say and then you say you're done and then from then on it's it's it's an immutable array right now we can do do this only by copying the safely we can do this only by copying the the mutable array into a fresh copy
• 75:00 - 75:30 but in the future we wouldn't have to do this so these are sort of sort of technical advantages but to exploit them you'd need to redesign your collections to some degree so right now we're not ready to do that because I think that would be too too radical so I think we will give you the technical advantages with the library design that that also profits of course but uh uh maybe it's not optimal yet yeah so what is your hope like long term for uh
• 75:30 - 76:00 the the capability checking what do you want to get to give scull an edge over uh languages that have over the over the years have borrowed features from from the from Scala what do you think would be the uh advantage or the U not just an advantage the competitive advantage for capability checking so so I think it's it's a logical next
• 76:00 - 76:30 progression step for Scala particular because it came from this Fusion of object oriented and and functional uh or object oriented functional with a bit of imperative so it lets you do imperative but it it it as well imperative it's not it's not uh predominantly imperative and it also lets you write functional code so where we were and it's that particularly typed of course so where we're lacking is precisely at this interface between imperative and
• 76:30 - 77:00 functional we were lacking the types right so you could do anything from from a function it could have arbitrary side effects and it was still uh syntactically a function um and uh the pure functional libraries say basically they go the way to say no no you shouldn't have that so let's just forget about mutable variables and mutation in in scy you shouldn't use that if you want to be pure functional they are not good features but I think that from the
• 77:00 - 77:30 philosophy of Scala the philosophy is is is a bit different the philosophy says well you can use them and you should use them when they make sense they can make certain things simpler and more more efficient but we want to control them with a type system so you so you want to say when you use them it should be apparent in the types that this function has a side effect that it can might let's say mutate Matrix or something like that so you basically want to uh to specify in the type within the time
• 77:30 - 78:00 system when it makes sense and when it doesn't make sense to for example mutate something or produce a side effect like within the type system yeah yeah so the the the problem with global mutable variables and Fields of global objects and things like that is that it's you you can have you can do you have incredible power by just using them for side side effect effect and you can also do incredible damage by doing that to your system because your system becomes very unpredictable if you do that I mean
• 78:00 - 78:30 we all know that so um the the language response to that is to say well if you do that you should pay a price for that and the price will be more complicated types so you need to sort of declare that you do that and in a sense the further away this variable is the more complex the type tends to be that talks about it what this function can do and that should be an incentive for you to to minimize these things so previously we've sort of have appealed to Good
• 78:30 - 79:00 Sense common good sense don't do these a lot don't do it if you if you if you if you if you're not happy with it and people have generally responded to this but there's the other uh mindset which says no no we have to we have to have guarantees in place we can't just appeal to to come in good sense in particular maybe you work with a team where you don't know all the members and you you want to protect yourself against against these things and then I think a type Checker that actually manages these
• 79:00 - 79:30 things is a is a good answer and it's very much in the if we can make it convenient enough it's very much in the in the Scala philosophy to do that Scala as a as a bridge between these these these different paradigms and as as a language that encourages you to essentially mix them in a beneficial way this is uh this is very interesting and uh sounds like it's a it's a very powerful uh set of features that would
• 79:30 - 80:00 encourage and not only encourage but rather enforce safety or Varian V various versions of safety to the degree that you can Define them so these this capabilities essentially give you the possibility to Define what safety means to you and then enforce that like ex Define a policy and then enforce that policy yeah how uh how do you plan on uh keeping the convenience part of it cuz uh this feature sounds to me uh and
• 80:00 - 80:30 uh maybe I'm uh I'm speaking uh on behalf of at least some of my audience that this uh uh this capability tracking would have at least the potential if you don't if you don't know how to use it right to uh bloat the types or make the make the program very rigid or very strict uh in the in a similar sense to how a library like http4s doesn't allow
• 80:30 - 81:00 you to spin up an HTP server until you provide everything and have all the bits and pieces in place how are you thinking of maintaining or encouraging convenience and also give people the power to express their own policy and then enforce them in large code bases well that I mean that is definitely the goal that we can get there but to get there essentially it's it's just a succession of uh of trade-offs and design decisions and
• 81:00 - 81:30 sometimes inventions to say often we we don't find a good way until later and then we say oh no yet yeah now we found a way that is light white enough to actually do that uh what we saw so far is uh surprisingly good uh initially I I was actually I I have to tell you I was scared of this project I thought well this is beyond what we can do in a type system and initially I was trying to do a static analysis so basically a
• 81:30 - 82:00 separate phase not in the types of the compiler that would sort of verify certain things in these things and and uh then the problem with the static analysis was that it at some point you have to tell the system what your expectations are and the best way that we know to do that is with the types so then we were back with the types the static analysis can infer lots of things to you but the problem is then presenting what it found and comparing it against your expectations that's that's why static analysis are very hard to to to to to use typically so we said
• 82:00 - 82:30 okay but a type AR isn't it going to be incredibly ver Bose but then through a sequence of sort of steps we arrived at something which is truly very light white so uh I give you one one example let's say I have a map on lists so map uh can be and I want to not restrict it so the function I can pass to the list can be be can be can be impure can can can have side effects M and um and the the way I write that is
• 82:30 - 83:00 uh exactly as I write it before not a single letter I need in addition so so it it just works out of the box and it works out of the box because now for us the double arrow means it's a it's a function that can have a side effect but the result is strict so we have a we have we get back a list and we essentially we encapsulate all possible effects we don't need to talk about them um then if you say instead of a list I want an iterator I have a map with an
• 83:00 - 83:30 iterator of the function so now I have a problem because I say well if I I return an iterator with a map of a function function could have a side effect so the iterator can have a side effect as well right when I call next it calls a function it has a side effect so what I say there is that in terms of capabilities I just need to say that the iterator hangs on to the function I do that with hat and curly bra open F which is the function name curly brace close that's it m there is some additional
• 83:30 - 84:00 notation that's true but I would argue it's actually very useful notation because if you have something and you say okay so here's this thing and it might have a side effect when you call these things through some some some parameter that they've given uh then it's actually quite useful to know hey this thing will I pass the function f to my iterator map function but the iterator will actually hang on to F and call that that's for you probably good info to know uh so to understand what
• 84:00 - 84:30 your program does and generally we found that the notations we needed were um mostly actually of this kind that they were very helpful so it's an improvement you know you you know better what your system is is going to do so so far it has worked out well but we're not done yet and it might still be bad bad examples yeah but for instance the other thing that we we have which is also brilliant I find is um so for the for the equivalent to borrow checking the exclusive capabilities let's say you
• 84:30 - 85:00 have a function and it wants to multiply matrices so that let's and let's say it's not returning a matrix but it you you give it two matri input input matrices and an output Matrix as three parameters so the way we write that is that we say Well it uh it gets a matrix and a matrix we just write Matrix whatever the type is and then the third Matrix that it writes is a matrix hat so the Hat it says hey I'm I'm I'm going to mutate this thing I'm going to need an
• 85:00 - 85:30 exclusive capability to this thing and then what the system would do is it would verify that the two input matrices are not the same as the output Matrix because if they were then of course your multiplication wouldn't work again wouldn't work anymore so you get this sort of alas checking and separation checking and all you needed is a single hat on the output Matrix and there again I would argue well that's actually very useful because it for you it makes a big difference when they say you get let's say an RA or a matrix are you're going
• 85:30 - 86:00 to mutate that thing or Not So that obviously makes a big difference and it's it's good to have sort of an indication in the types and what we have is sort of the shortest possible thing with this with this little hat at the end this is interesting so uh with uh some a little token next to the type uh so you're saying like a m hat or mat Matrix hat the the little hat that that's the up Arrow right um is uh that that
• 86:00 - 86:30 signifies the ability to be mutated or uh does it signify any sort of capability that you can track uh it signifies actually both yeah so so the hat is basically the can say capability polymorphic thing or you could say the top in your capability hierarchy so that could be any capability uh that that that is connected to that yeah uh
• 86:30 - 87:00 but the uh so the Hat gives you essentially the the power that this could be anything but for the um for for the Matrix example what it also gives you is to say Well it the the things you could change with the hat are separate from anything else you can see so I passed three parameters a b c c gets a hat so the Hat could potentially do anything but it can't affect the a or the B because you see so basically you
• 87:00 - 87:30 say well I have I I slice up my universe of things and I I I have various names that I know about if something has a hat it says well uh this is something that could change and it will be separate from anything else you can see so it's sort of you you won't hit a problem that you you do a a mutation in this by calling a method and suddenly something else you that that that you see has changed so that that that's an effect that can't happen that's very
• 87:30 - 88:00 interesting okay I'm very curious to see how this pans out have you used this in uh so you mentioned gears uh that that uses uh uses this can you can you explain uh for uh the listeners what gears is and uh what its goal is Gears is a uh a library for uh direct style Futures and channels so it's essentially a lowlevel concurrency library that uh uh that represents that presents concurrency as essentially the
• 88:00 - 88:30 active elements are Futures and they they don't need a a monatic uh bind to be called you can just call you say future da wait and that that will wait for the result of the future and they can these Futures can also communicate with channels so channels are sort of the the passive elements of communication so it's Futures and channs they can also of course simply return results functionally if you
• 88:30 - 89:00 want that's what gears is it runs on loom on the jvm and on Scala native continuations okay uh I wanted to um uh bring the um uh the conversation to the the state of Scala in general and uh I I wanted to ask ask if you see something uh that would make Scala uh a really popular mainstream
• 89:00 - 89:30 language the way I believe it was meant to be um and uh I'm asking this because Scola has a lot of power and because of that power uh many uh very capable programmers came to the Scola ecosystem and they invented these very potentially complicated Technologies and they're very powerful they're very good and the they added a lot of safety into the products that use these tools for
• 89:30 - 90:00 example like the effect systems and uh uh the Octor models and stuff uh but since other languages that are more mainstream like Java uh or to a degree uh cotlin as well uh borrowed the features that made Scala interesting when it was launched like the blend of objectoriented and functional programming that kind of LED Scola to differentiate Itself by its most powerful stuff like the higher kinds and meta programming uh and
• 90:00 - 90:30 contextual abstractions and now this the capability tracking um and so the differentiated audience now for scholar is essentially the pure functional programmers that that are doing basically effect systems so I'm curious how you see scull progressing to a mainstream language uh with uh the kind of things that you know will added or will be changed in in the language and I have a a little qualifier to that but I'm going to uh leave you to to this
• 90:30 - 91:00 question for now that's a good question uh because um and um I I'm actually not sure I don't think these things are planable at all so essentially all you can do is uh develop some technology and tooling uh hope that it will interest people and then it
• 91:00 - 91:30 depends very much on the other people what they do with what you put out there and uh so so it's difficult so what we did with scalar 3 is essentially smooth all the edges uh um make make it look more more modern and uh simpler syntax I think I think is a lot simpler it appeals should appeal to people coming from python which is basically all the kids nowadays
• 91:30 - 92:00 this sort of whether that will help or not is is a different question I don't know uh it depends on who next picks it up how they how they use it how they evangelize this whether it becomes a a movement or whether it becomes sort of gain steam or not I'm not sure yeah yeah there's uh there's definitely an intuition there with a gaining steam because what I wanted to qualify the question with was the fact that uh at
• 92:00 - 92:30 least in my mind in my mental model SC as a kind of like a product in the programming languages Marketplace or not even a not even just a product that would quote unquote sell to people and as in convince people to use it and uh base their software and their careers on them um but also a platform in the sense that a programming language has this the same property of a platform in uh in terms of
• 92:30 - 93:00 network effects and a language has Network effects in two ways at least in my conception one is the network effect of people joining in the E uh joining the ecosystem and talking about it which is what Scola did uh like 10 years ago when it garnered this interest of this blend between object-oriented and and functional uh parad dimes in a very nice and fun package that uh gathered a lot of uh interest and excitement which
• 93:00 - 93:30 caused people to build all these amazing libraries and tools and whatever so that there one that's the people with the network effects and two the network effect of the ecosystem of libraries and tools which is something that you can that could explain the immense popularity of things like python JavaScript and typescript because new libraries are being built every day there is this public repository of all the stuff that you can build with on the server side on the front end with
• 93:30 - 94:00 various um visualizations various data processing tools and everything else that you can build in these languages so I'm wondering how you see Scala uh evolving or gaining steam uh to use your words in terms of these Network effects um I I I think I completely agree with with your theory that that's what it is but uh as to the
• 94:00 - 94:30 second part of the question I don't know uh I mean I don't know what U um so when I see that like the first wave was uh typically uh junior well maybe not Junior but small teams of Engineers or maybe even graad students just doing something so they were uh uh intrigued by the technology uh functional object
• 94:30 - 95:00 or it was new at the time and they built some stuff and then that became large so for instance Twitter by the time they adopted Scala there were all together 25 people so that was size of the company fairly small company but then they became big and uh and Powerful or spark was the work of a handful of GR students at Berkeley uh so that that that used that um so I guess what we're doing is
• 95:00 - 95:30 wait for the next spark or the next people who pick it up and then the question is why why would they pick it up uh and so there must be some unique advantage to it and the advantage must be polished enough that it they they actually can use it in a product very quickly not just conceptual say and um that uh so I I believe that as as a first
• 95:30 - 96:00 step the the capability story is a powerful story uh and uh because it it it could be a game Cher for security and it could be a game Cher for the sort of systems that have to be efficient but should be safe as well so by having sort of a a an amount of mutation that you can have in your system without worrying about about uh possible possible data
• 96:00 - 96:30 races and things like that so so I think that's that's a possible game Cher in in some some parts um in the long run um I'm also not sure so we had in in in scolar days 23 there was an interesting talk by Andre uh on uh the uh essentially combination of programming languages and LS and AI where he was arguing that life started life first was essentially slime so MOS
• 96:30 - 97:00 and things that and higher life started when uh you uh the skeleton was invented when people invented bones and and carasses HS first who bones came later um and he thinks with languages it's sort of the same thing to say llms are sort of the the origins of this thing but you need clear structures in which you can build higher level things and have security guarantees and I think for that thing Scala is is a good Contender
• 97:00 - 97:30 maybe it won't be Scala but the language like it that's also possible uh of course I wish it would be it's it's SC and I'm working towards that what with what I can uh but I think there there is a a thing to that that you say uh if we have llms and code generation will become incredibly cheap because it will will just give it to to copil to cursor or whatever then um you have still the
• 97:30 - 98:00 price to ensure that this uh this thing does what you want that this is the right thing that it doesn't have hidden bugs and things like that and there all all the help you you you can get you should you should take because that's the that will be the hard part that remains in the programming job and a strong and expressive type system is one of the best tools we have now and with capabilities will be even stronger so so my my saying well
• 98:00 - 98:30 my potential future would be that these things will become important in particular with AI this is uh I'm also very very curious especially since Scara has historically pioneered many of the stuff that we now kind of take for granted and uh we'll probably soon see a sort of capability tracking in other languages as well obviously in 15 years not because I think there we have a have a mo so to speak because for this
• 98:30 - 99:00 to work in practice that we you need to have two features in the language which for now Scala is quite unique in having them one is uh implicit parameters so read not many languages but maybe maybe bin is getting something like that uh after all but not many languages have them yet and the other is a light white dependent types as types that can talk about uh program variables
• 99:00 - 99:30 uh parameters and things like that and uh they also Scala is quite unique that it has these sort of types not many languages do do have that so I think there will be some catching maybe other languages will catch up but it will will be some time until they do that yeah I mean Java added pattern matching what 15 years after the uh sure yeah yeah yeah yeah yeah yeah but it's not that they couldn't have done it from the start I mean Java's pre precursor well not precursor
• 99:30 - 100:00 but the my my Java compiler precursor was pizza which was language we did and pizza had pattern matching but at the time uh we presented that to to the Java people they said well uh we we don't um uh because Pizza had three things it it had lambdas param matching and generics and they said well we don't need lambas we have inner classes that's good enough at the time
• 100:00 - 100:30 that was like end of the '90s pattern matching is completely unob oriented we we want none of that but we want the generics so can you can you maybe please write our compiler um and or take this and and make it the next Java compiler so that's how that happened so generics came then in in 2004 and the lambdas in Java 8 in 2011 or something like that and now finally P matching also made it into yeah I mean uh yeah there's a a lot for uh for that stuff to catch up
• 100:30 - 101:00 to but P magic in a sense uh more it's less less deep than dependent types so dependent types would be it's more it's more a surface feature a very important one and also full of sort of complexities with exhaustiveness checking and these sort of things but it's more a surface feature in my my categorization um what is your hope for Scola over the next few years um and
• 101:00 - 101:30 over the long run so first I hope that we uh we will uh move the community uh more of the community a lot more to scalar 3 and I think that's happening so we very encouraging that the first companies are migrating and more companies are more young companies are just starting and for them it's obvious to start with Scala 3 yep so I hope that will continue
• 101:30 - 102:00 uh the the next hope is that the as a community we will put more emphasis on on Simplicity uh simp simplest possible solutions and thereby also make the language more accessible to newcomers MH uh yeah and the third hope would be that at the end of this period maybe we have a good a good um uh good foundation and and a good good language for capture checking for for capabilities so that's
• 102:00 - 102:30 that's sort of the the lab Lab thing yeah I mean yeah uh there's a lot of potential there and uh I'm as a uh as a teacher of schol and as a scholar developer I really I hope to play my part in it um to make scholar more accessible and easy to get started with um as I wanted to move to some uh
• 102:30 - 103:00 uh more let's say quicker or rapid fire questions before we uh draw this conversation to a close I want to be respectful of your time and uh uh I really appreciate you making the time for this long conversation the time just flew by for me uh I want uh I wanted to ask you if um uh if you have a uh a programming language that you admire even if you're not using it or if you draw some influences from while
• 103:00 - 103:30 designing Scola um let's see uh so right now I'm actually learning lean and I find it very very uh intriguing uh lean is essentially an interactive theorem prover uh so I find it quite tedious uh it's surprisingly tedious to actually have to develop these proofs and things like that but it's definitely intriguing what it what it can do that you essentially you can State Properties any
• 103:30 - 104:00 property and uh and prove it in the same program so um you have know your program is a proof in a sense for the property it states itself so this is quite cool uh and lean has a sort of uh in in its um notation and things like that it just has a lot of cool things and maybe we can steal some of them for Scala in the future I don't know uh in in terms of
• 104:00 - 104:30 what would you steal from it uh so there's for instance there's this thing called sections uh where a section is not is sort of like an object but it's not a separate object so it's it's more like sort of a block of extension methods but it's not link to extension methods in this section you can declare essentially common parameters and types so you can say for instance a uh like f your ous f is is a monard or something
• 104:30 - 105:00 like that and that's a parameter in the whole section so every time you mention this F in a parameter list of let's say an actual parameter things like that it means this definition so basically rather than repeating the same type the type parameters and formal definitions for every method you just mention them and uh it will pick them up from the section I I'm I'm not sure what I I it can work quite nice in in sort of
• 105:00 - 105:30 avoiding the repetition and things like that it feels a bit like avoiding the thing the common prefix in the way we do bulk extension methods but um I that was kind of intriguing um to do that the other thing yeah the other thing is it it has a I'm not sure whether I should be scar by of that or or or intrigued it has it has a really cool system to change your notation so so you
• 105:30 - 106:00 you can have a very flexible thing that uh that you you define yourself and that uh that can is then notation you can use in your program because lean is very math heavy that's important because mathematicians are very creative in their notation so the language supports that quite well um yeah so that was sort of some of the some of the smaller things yeah this is very interesting I'm going to uh I'm going to put this into the uh
• 106:00 - 106:30 comment or um the description of the video um Martin I wanted to thank you so much for uh for the taking the time to uh take part in this conversation I really appreciate it before we uh wrap the conversation is there anything that you would like to share with my audience or any uh um now I think we covered we covered a long a large range of of of topics thanks for your
• 106:30 - 107:00 questions all right so for everybody who's listening we're going to leave links in the so-called show notes if you like this conversation let me know give me a feedback or comments in the uh in the next to the videos or uh wherever you see this or wherever you listen to your favorite stuff and uh if you wanted to to uh hear more from Martin I'm going to leave a link to um to his profile and
• 107:00 - 107:30 uh you will uh find a link to the scholar language as well and to Martin's work so Martin thank you so much for taking the time thank you Daniel it was a pleasure