 We can start. Great. Perfect. All right. Everybody, settle down. Let's get started here. Oh, wait, not that close. Welcome to the Future of Small Languages panel. I'm Chris Weber. I'm going to be the moderator of this fine event. Now, the other panelists may introduce themselves. So good morning. I'm Ludovic Cortes. I'm co-maintenor of GnuGuile together with Andy Wingo and Mark Weaver, also working on GnuGeeks. Hi, I'm Justin Komak. I work on various open source projects for Docker. My interest in small languages comes from being a long-time Lua user. Hello. I just graduated as a software engineer. I studied at the university where Lua was created. I forgot to say my name. I'm Etienne, and yes, I am very passionate about Lua. Well, great. Well, it's been a year since we did this same panel. It seems like lots of things have been moving fast in the language world. So maybe we should open up with between this and last year. What's been the change in the vision of the future of small languages? What's the interesting things that are happening respectively in Guile and Lua from your perspectives? So I feel like there's been a lot of new people probably coming to Guile, and part of it is due to the fact that there is a new dynamic, I mean, with Guile 2.2 coming up and people are trying new things. So there are people like Chris, for instance, looking at networking and asynchronous programming, trying to take advantage of the limited continuations and this kind of feature that is not unique to Guile, but still quite, you know, you don't find it in every language, I guess. And yes, so there's been a renewal of interest, I would say, in Guile. And also because Guile 2.2 is going to be faster, there's also people looking at things that we just wouldn't even consider before, like doing, you know, game engines and doing that kind of stuff. And that's, you know, you need some sort of performance that we just didn't have before and now it's really getting interesting. We can go deeper and to the lower levels, so I think that's pretty cool. And yeah, apart from that, I should also, I guess, mention Geeks, which is, you know, a package manager and distribution. And I guess a number of people are coming to Geeks because of its features as a package manager, you know, but you get to learn Scheme somehow, even if it was not your intent. And yeah, I'm guessing people are starting to write more Scheme, but also because of Geeks. I don't know, Lua tends to be quite a slow-moving language. And what we find, we've got multiple implementations. I think one of the things I noticed this year is people continue to make more implementations of Lua. We've had people asking me about the Go implementation, the OCaml implementation and various other ones. And while Lua has this great high-performance Lua jet, again, that's kind of divided the community because it's a separate implementation and it's not entirely compatible. So in a way, I think we've got a problem of too many Lua is not too few, and that's one of the things I've already been kind of worrying about this year, that we haven't got a single... I mean, we haven't got a single Lua community so much as I would have hoped. I think that's a matter of perspective because, well, some people in the community tend to sit as different things or look at it. Oh, it's all Lua, it's all in the same family. And the more things I see happening to me, it seems like, okay, there's more people involved and we could just get together and consider the same thing and things would move along easier. But apart from more Lua implementations and coming up, what I have seen changing from last year to now, two things. One, I think that more and more Lua is being in advance in the machine learning field, so there is a framework called Torch that uses Lua jet because of its very fast performance. And it's interesting because there are lots of important companies backing up. If you go to the list of contributors, you see people from Facebook, Twitter, Google. So it's nice to see that there are big companies giving support in the end. It's important and helps a lot. And besides that, I think that Lua also seems like a momentum in terms of community this year. We are having three Lua-related conferences this year, which I think it's a new record ever since it's been following what goes on with Lua. So we have one in Russia, one in Brazil, and we'll have the Lua workshop somewhere. And there's the Lua Devroom, so if you count that as an important community that's four. So there seems to be lots of things going on and lots of people starting to see Lua recently. So this community momentum, I think it's happening right now, and that's very different than it was from last year. We don't have multiple guiles. We sort of do with the multiple versions, but we have so many schemes that I guess we've got a similar problem there. But that actually brings up an interesting conversation about when experimentation with different implementations and divergence, and when divergence, whether it's kind of a linear progression of new features, or actually having different implementations and et cetera, in which ways can this be beneficial? In which ways can it kind of hamper things? Is it net positive? Or what do you all think? So with respect to guile, it's traditionally been pretty much a slow-moving project, I think. And so the approach that we had was to have stable series, which are super stable. They're basically very few new features, if any. And so we would create a new stable series every time we wanted to do something important. And that's a good thing, because people using the stable series know that it's stable, but on the other hand, it gives us as guile developers an incentive to actually go ahead and push as many new features as we can in the new stable release. And so we have a tradition of having new stable releases, so currently 2.2 is in the works, so we call it 2.1, because it's not fully stable yet. But there are many, many new features. It's essentially a new compiler, it's a new virtual machine, for instance, so you can imagine. Well, as a user of guile, that's not necessarily something that you would notice, except that it's faster. But still, I mean, and that's just the surface of things. There are so many new features every time. Largely thanks to Andy Wingo, who has been doing crazy work on this particular release. But in the past, there was also a huge difference between guile 1.8 and 2.0, and we know that for some projects, some users it's been quite a bit of a step to move from one stable release to the next one, and some projects just were relying on internals of the previous stable release, and that has led to problems too. I don't know what the ideal model is. I think there are good things about the way guile has been doing things, but it's also, for users, it's also usually a bit of a step to switch from one version to the next one. I don't know how you handle things. Well, I think that the two main implementations are the standard lower, which is great and fast, and then we have lower jet, which is extraordinarily fast, like orders of magnitude faster, and is native C-speed, and that created a whole different set of applications that people are interested in. And there's things like Snap Switch, which Andy Wingo actually works on, for example, which, you know, is 10 and 100 gig Ethernet switching and user space all written in lower jets, which is, you know, really an application that no one would have even considered doing had there not been a different fast implementation that was designed around performance and had a really easy-to-use CFFI interface. And then there's other people using that cloudflare, using it. They've done an EBPF compiler so you can run the code in the Linux kernel, among other things. And so there's a whole different set of community and different people that came from a different implementation because its performance was so different, and suddenly there's a bunch of, you know, kind of systems programmers and people using it, which is very different, you know, from the kind of games and embedded scripting in other, you know, other use cases. So I think that a radically different implementation can, you know, bring in a whole different community and is interested in different things and had a whole lot of diversity and new ideas and new use cases. So I think it can be really constructive to have something that's not entirely 100% compatible if it gives you new opportunities to try out new things and bring scripting to new areas that haven't been scripted before. I don't think you have much to add in that, but just to explain the current issue between having Logit and the vanilla will besides, that Logit has this incredible performance, so this is a good thing. But the problem is that the syntax compatibility is basically locked in an old Lua version, which is the Lua 5.1. So a lot of people will have, will be, you know, blocked and upgrading their... Yeah, if I find a face and everyone uses... Yeah. ...which is a big chunk that's not compatible. Exactly. But even if you're trying to work with something that is like cross compatible with different Lua implementations, you will, for example, write it in a Lua 5.1 manner so we can run a vanilla Lua and LuaJet. And unlike many of the features of Lua 5.3 that are not present in LuaJet, for example. So this is the problem we have that we are still looking, hoping for a solution. But yes, I am very happy that we have all this new bunch of people using Lua for different problems. So I turn you brought up something that I wanted to follow up on which was about the growth of Lua's community and, you know, in kind of our pre-conversation about this. We all agreed that we were interested in the conversation around community. So I'm interested in what do you think we can all do to improve our communities and what do you think, or just generally comments on community where you'd like it to go, what are our current strengths, what could we do better at this point? So, like I was saying with the advent of Guile 2.2 and before that 2.2 we've been seeing more technically diverse communities around Guile because Guile used to be targeting a very specific community which was, you know, embedding languages like pretty much like Lua in a way, maybe more heavy-rate but still, you know, embedding in a big C application that was the main use case. And starting from 2.0 it's become, you know, a standalone scheme implementation so that has attracted people who just want to write entire programs directly in scheme. And yeah, with 2.2 we're gaining more, again, traction in different domains like I said before because it has better performance and I guess it's similar to what happens with LuaJIT. So that's for the technical part of it. Well, then there are also diversity issues in general but which are not related to technicalities, just like in many free software communities, I guess. I mean, we've been trying to work on it but that takes time, I guess. I think in many ways with a scripting language you have to work much harder on community. There's a lot less commonality between people who are writing enhancements to World of Warcraft in Lua and people who are writing 10-gig ethernet which is software in Lua. It's, you know, the domains are very different and a lot of the stuff, the way they use things, the libraries they use and things. Especially, I think, because Lua doesn't try and force a standard library on you or anything. So it's been quite a difficult process of community building across that sort of thing. I think it has actually started working but you have to have a bunch of people with really diverse interests who are interested in bringing these people together and trying to get them to talk to each other and some of whom are historically people who don't talk much. I mean, the games industry was always one of the early adopters of Lua but they're not very open source-oriented or historically. I think the kind of accessibility of mobile gaming I think has actually changed that a little bit but the big companies are certainly not very open and so I think that's why historically there wasn't much of a community. It was quite narrow. It was the people who are actually interested in implementing the language who formed the community but I think we've been working on that and I think having people who are just interested in way softwares used in very diverse environments really helps. Yes, I mean, not only the game community is historically not doing lots of open source and not discussing lots about what they do and many small companies using Lua embedded as well they're a type of groups who will always be writing everything from scratch and then not something specific to their use cases and not putting in things, not putting in modules on Lua rocks, not using things that are on Lua rocks and now it's a process. I remember Hishan who is the lead developer of our pack manager of Lua rocks he will go personally to GitHub repositories and say, you know, this could be Lua rocks and just like create an issue and people will be like, you know what, that's true. Why not? And then somebody will create the rocks pack and then we'll finally be shared as a library. So, you know, it's a little bit like poking around and talking to people like, oh, hello, you could do this, you could do that. And slowly things start moving around so it's also a matter of convincing people to do community things as well. As I said, it's very difficult to get people together and get them to talk to each other but at some point you just have to say, you know what, you're going to meet a displace, everyone show up and some people will show up. So, oh no, I'm going to make this event and I don't know if you're going to have an important number of people and in the end this is not important, you just create something, people will show up and it grows from there and you have to convince others that this actually works. So, I organized last year a conference in Rio and I had no idea if people would show up and in the end the outside room was full. So I was like, see, things happen so I'm trying to convince some friends to organize meetups in their cities and that also takes a little bit of some folks being proactive and bothering and making things happen. I just wanted to add a note about package managers like Lure Works, I remember we discussed it last year and honestly as a guy person I'm a bit jealous of things like Lure Works or all the package managers for languages and at the same time as a distro person I don't really like them because they are separate, they create new problems but still I mean when it comes to growing a community I think it's obvious now that it's really helpful to have this kind of infrastructure and we don't really have it in Guile because we have Geeks as a package manager but it's maybe not suitable for everyone and we also don't have a standard way to package your software like most people would use auto tools and this kind of stuff to configure and package your software but that's not really something we want to encourage because it raises the barrier to entry and so I think we have a problem that we should fix here in Guile because that's probably one of the things that prevents us from really growing the community. A couple more questions and then we're going to open it up to audience questions but you mentioned infrastructure and I think you were talking about language infrastructure but I'm really interested in the topic of infrastructure generally so what kind of infrastructure support do you have? Would you like to have? Whether or not it's being under an umbrella organization Guiles under GNU or whether or not it's having companies actually use it to implement things and have people be paid what infrastructure do we have and what infrastructure do we want? Maybe we should stop. Oh, give me a second. Could you start? I think Lua's quite diverse and therefore I think one umbrella might be difficult we have a mixture of, I mean Lua came out of originally a university but around a commercially funded project and that kind of is the mix that Lua's always kept there's been corporate sponsorship in various kinds of ways of hiring people to work on things that involve Lua and Lua JIT was, again it was a sort of it was an independent project but always funded by a mixture of people in the gaming industry, Cloudflare other people like that so we've kind of managed without any kind of overarching organization I think that and then the I think it's kind of worked okay I'm not sure that I'm not sure that a central organization or umbrella is necessarily useful I think that the main thing is whether the community is healthy whether people are working on it and so on but it's I think the things like the package management and things it's good to have a single point of focus it's taken a very long time actually for Lua Rocks to become that and other projects are still using their own package management and things like that for Lua packages still so I think those kinds of things it's good to have that around some of those kind of unifying things but overall the little kind of homes that Lua has I mean that around the projects have generally worked quite well Yes I think you're right in the sense that Lua has been doing alright with all this kind of umbrella organization around it but at the same time I think I would like if Lua had one because I think it will make things easier for individuals trying to do stuff especially for someone like me that tries to do stuff within the community and I want to do something that's like who do I talk to about this do I just send an email to Roberto directly this doesn't seem alright it's like I don't know having a group of people who are responsible for I don't know contacting companies getting funds starting projects making things happen and unfortunately in the end it comes down to money and money has to appear from somewhere and it would be easier if there were people responsible for organizing all that so I was involved twice not as an organizer so I was I once participated as a student and last year I participated as a mentor yes yes so there are some things but they are not there's the research laboratory of Lua inside the university so they are the same people responsible for working on the language implementation so they are the PhD students we're doing their thesis and they are the ones who are organizing the Google Summer of Cold because they want to so they are allocating their time you know they are doing something for the community in that sense and they are a very small group of people there are like two or three people who are university professors so the reason one person who is allocated to be responsible of managing this part and I think this would be very useful I think Google Summer of Cold is one of those things where there has to be an official organization for them to consider you so it does it does help that we've got this kind of PhD which we can kind of use as that for some purposes but it's not that's one of the cases where Google doesn't let a community have students for Summer of Cold which is perhaps a bit remiss on their part but you can see why they might want to do that but there are lower projects sometimes in other organizations as well and I think generally you can make Summer of Cold work for other means quite often there's other organizations that are interested in things so I think Gailly is quite different from Lou in this respect because Gailly is part of the GNU project and the GNU project itself gets its infrastructure sponsored by the Free Software Foundation so for instance the servers that hold the websites that hold the git repositories and all that it all comes for free for us we know it's being handled by people who will remain through to their mission and so that's really a great thing to have apart from that I think Gailly is really some sort of a grassroots kind of project in that I mean unlike Lou it's not an academic project initially it's not an industrial project either so it's really a bunch of hackers initially who said well what if we kind of extended this to all of the operating system roughly and they started working on this project and so that has a different feel maybe as to how the project works and maybe that also explains why historically it has had very little corporate funding behind it although well we see now a few companies actually developing Gaill code but that's still a little bit marginal I guess so that's what we have in terms of infrastructure but also being part of GNU means that we can participate in the Google Summer of Code pretty easily because GNU is the umbrella organization so that's another another way where it helps to have an umbrella organization like this one last question before we get to the audience so it seems like to me that we're in an exciting era when it comes to languages back in 2003 or so it felt like it was the world of languages was like don't bother with new languages we've got Java and we've got .NET and just use those and though there was interesting work being done on virtual machines I feel like but now there's so many interesting things going on from type stuff to just about everything so what are you most excited about language design outside of your project outside of Gaill or Lua what are you or it can be about each other but it can also be about a completely different language what's most exciting to you right now that maybe you want to bring into your language or maybe you just think is interesting externally I do think it is it's an interesting time that new languages are taking off relatively quickly compared to compared to the fact that Lua is over 25 years old it's similar age to Perl and Python those languages those languages have served us well they've been incredibly helpful over the years but it's nice to see a whole bunch of different languages I think I've always I was exposed to functional programming quite early on I've always been really keen on strong typing for many use cases I think Rust is really exciting as a language and I've even started trying to write some code in it and I've got some projects I want to use it for going forward so I think that the use of typing in Rust to do different things like linear memory allocation is really exciting I don't think that it will ever affect that scripting languages like Lua should have strong typing probably I think it's still a very different thing but I'm kind of flexible on that there have been some experiments with sort of gradual typing and scripting languages but I'm not sure how useful they really are I sort of sense that in a way that the competition for something like Lua is not big, complicated languages that take time to learn like Rust is really the competition is things like more complicated configuration formats really and you see people having the sort of choice between static configuration or slightly more scriptable and that's the kind of choice that they actually spend their time making so we use a strongly typed language for scripting or a weakly typed language that's not really quite where the choices are well I could use Lua and better than Rust this is a difficult question for me because all the languages I've been using other than Lua languages are like less than Lua but I'm really excited to learn a bit about Alexia I haven't done much functional programming and I've done a lot of Haskell in the university but it was one of those models that I still haven't got your grade you go like and so I really wanted to get back to it and to me it seems like Alexia is a very nice opportunity the community seems active which is something important to me so normally Haskell doesn't do community much and since Ruby some sort of adopted some of the Alexia activities because some important key people who are coming to this both technologies there are things going on and this excites me and some of the language features itself as well so I'm hoping I will get my hands on some Alexia version so for me I see a lot of excitement around Rust and I don't feel like I'm really excited about the language itself I don't know but I'm not super familiar with it either but I'm really excited about what people are doing with it and it seems that it's targeting a very wide range of applications like yesterday there was a talk about a micro kernel written in Rust and I think it's great I think we need memory safe languages and we need to at some point start getting rid of C because we know all the troubles that it gives us so that's really the part I'm excited about when it comes to Rust then I'm very much into functional programming so yeah I see really a lot of momentum around functional programming so we see lots of new functional languages like ML, like closure wait closure is not so new now but I mean there's a lot of work going on and of course the big ones Haskell OCaml and I mean there are so many things going on there because occasionally we start chatting on Haskell for instance and we get jealous about this or that feature of that language so I'm a bit disappointed in a way that there are so many different languages I think people maybe could kind of focus on one instead of creating a new one like Elm for instance I mean there are people working on Haskell yeah Haskell compilers that generate JavaScript that's a more fruitful approach but yeah there are so many things to be excited about in terms of languages and functional languages in particular these days so for Gaela I would like to also explore a bit a way of going a bit closer to some sort of static typing I mean Scheme has macros and people in the racket have showed that you know use and abuse macros to come up with some sort of a typed language and that's really something I would like to explore because yeah I mean there are cases where using purely dynamic typing is kind of you know not so great right so that's one of the things I would like to explore for Gaela cool so let's open it up who has questions from the audience okay so the question was for Gaela about the relatively few amount of language bindings that we have has that over to you right so I mean yeah this is true we have probably much fewer binding than Perl for example I think the situation has been improving though since 2.0 because with the FFI the foreign function interface has become much easier and less cumbersome to write bindings and you know you just write a bunch of Scheme lines and it's pure Scheme you don't even have to bother about having a complex build system or anything and so that's allowed people to actually come up with quick bindings that actually work pretty well and so we've made progress and yeah that's yeah I think I mean one of the reasons for the adoption of Lourgett with an FFI and it does make an enormous usability difference and it's kind of it's part of what I spoke earlier about the division between the two communities because everyone who uses Lourgett writes FFI bindings which are not available for standard Lour and writing bindings for both is twice as much work because they're so different and we talked about some ways to fix that but it's it's difficult because Lour is very straight on we only use standard C and you can't write an FFI binding in standard C so we've got this this division but I mean yeah the ease of writing a very quick FFI binding is enormously better and it definitely makes a lot of difference from that point of view if you want to increase the number of bindings often the FFI bindings are so easy to write you don't go and look for someone else's bindings anymore you just write the C headers import the C headers and write three lines of binding and that's kind of a it's a magically better way to iterate fast on stuff okay we have time for one more question you shut up fast right okay so the question is about generic interfaces for languages so that you can use multiple languages yeah I think it is useful I mean there's two things I think one is that the lowest common denominator is the C API but there are problems about types and structured types I think that I mean at work we spend a lot of time using things like protobufs which is available for quite a lot of languages and is quite good it's quite heavy weight though and I think that there are there are kind of attempts to do something a bit more lightweight but I think that at least there's been a set of projects around what does inter-language communication look like how do we transfer structured data that's in a way that's better than just passing everything through JSON or something like that and I think that I think that those approaches are really valuable because I think that the C interface is really low level for a lot of stuff and it's good for library bindings and it's probably going to be the interface even when we stop using C and we're all using other languages I think the C interface is really convenient for low level stuff but for higher level scripting it's not very convenient actually Gael started his life in the 90s at a project that would unify all the dynamic languages I would say so the story was that we'd have a common runtime system and all the languages would use that runtime that VM essentially and so at the time people were saying yeah we'll have so to begin with we'll have Scheme and EmacsLisp and then we'll have Python and Perl and what not and I started as a strong supporter of this approach I was like yeah this is the way but then people actually started to try to do it and especially in the context of EmacsLisp and you would think that EmacsLisp and Scheme are pretty much the same thing except except there's one tiny difference for instance which is that EmacsLisp has a special value which is nil which means both false and DMT list whereas Scheme doesn't have that it has instead DMT list and false which are disjoint and that tiny detail already causes a lot of headache right and then if you look at Guy too there's a Necmascript JavaScript frontend also you would think JavaScript is a dynamically type language it's not that different from Scheme but still I mean it's too different already so you cannot really interact seamlessly between Scheme and JavaScript that wouldn't work so well so I've become more skeptical of the unified language approach do you want to add anything or should we go to closing remarks I don't think I have much to add to this one I mean Lua has been used a lot as some sort of glue language because it has so many bindings to many other languages but it was mostly on a project based approach where all you need I need this program to talk to that program and they're both written in whatever language and I will put Lua in between and then magically glue them together switch speakers okay well thank you so we've got an exciting room ahead for Guy here I encourage people to close in a little bit so that people can fit but yeah