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,

and now the other panelists may introduce themselves. So, good morning. I'm Ludovic Cortes. I'm co-maintainer of GNU-Gile together with Andy Wingo and Mark Weaver. Also working on GNU Geeks. Hi, I'm Justin Cormack.

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 the 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 maybe the change

in the vision of the future of small languages? What's the interesting things that are happening respectively in Gile and Lua from your perspectives? So, I feel like there's been a lot of new people, probably, coming to Gile, and part of it is due to the fact that there is

a new dynamic with Gile 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 Gile,

but still you don't find it in every language, I guess. So, there's been a renewal of interest, I would say, in Gile, and also because Gile 2.2 is going to be faster, there's also people looking at things that we just wouldn't even consider before, like doing game engines and doing that kind of stuff,

and that's 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. Yeah. Apart from that, I should also, I guess, mention Geeks, which is a package manager and distribution.

I guess a number of people are coming to Geeks because of its features as a package manager, but you get to learn scheme somehow even if it was not your intent. Yeah. I'm guessing people are starting to write more scheme 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 here 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. While Lua has this great high-performance Lua JIT, again, that's 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 Luas, not too few. That's one of the things I've already

been worrying about this year, that 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 see it as different things or look at it, oh, it's all Lua,

it's all in the same family. 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 it the same thing and things would move along easier. But apart from more Lua implementations 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 JIT because of its very fast performance. It's interesting because there are lots of important companies backing it 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. 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 I've been following what goes on with Lua, so we have one in Russia, one in Brazil, and we'll have the Lua workshop somewhere.

There's the Lua dev room, 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. Well, we don't have multiple guiles. Well, we sort of do with the multiple versions, but we have so many schemes that I guess that we've got a similar problem there. But that actually brings up an interesting conversation.

When experimentation with different implementations and divergence, and when divergence, whether it's 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, yeah, 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 like super stable, like they're basically very few new features if any. So, we would create a new stable series every time we wanted to do something important. That's a good thing in a way 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. 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 like 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, right? Except that it's faster. But, yeah, 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, yeah, I mean,

in the past, there was also a huge difference between Guile 1.8 and 2.0. 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. Some projects just were relying like on internals of the previous stable release and that has led to problems too.

So, 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. So, I don't know how you handle things.

Well, I think that the two main implementations are the standard Lua which is great and fast, and then we have Lurgit which is extraordinarily fast, like orders of magnitude faster and its native C-speed. That created a whole different set of applications that people are interested in. There's things like Snap Switch,

which Andy Wingo actually works on, for example, which is 10 and 100 gig Ethernet switching in user space all written in Lurgit, which is 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. Then there's other people using that CloudFlare, they're using it, they've done a EBPF compiler so you can run the code in the Linux kernel among other things. 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 systems programmers and people using it, which is very different from the games and embedded scripting in other use cases.

So, I think that a radically different implementation can 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 percent 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 read in that, but just to explain the current issue

between having Lurgit and the vanilla world besides that Lurgit has this incredible performance. So, this is a good thing. But the problem is that the syntax compatibility is basically locked in the node version, which is the Lua 5.1.

So, a lot of people will be blocked and upgrading their- The EFFI interface in Lua, 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 on vanilla Lua and Lurgit. I like many of the features of Lua 5.3 that are not present in Lurgit, 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, Aytan, you brought up something that I wanted to follow up on,

which was about the growth of Lua's community, and 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 Guide 2.2 and before that 2.0, we've been seeing more technically diverse communities

around Guide because Guide used to be targeting a very specific community which was embedding languages, pretty much like Lua in a way, maybe more heavy rates, but still embedding in a big C application that was a main use case. Starting from 2.0, it's become 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 switch software in Lua.

The domains are very different and a lot of the stuff the way they use things, the libraries they use and things, I mean, 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. They're not historically. I think the kind of accessibility of mobile gaming, I think this has actually changed that a little bit, but the big companies are certainly not very open.

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. Well, I think we've been working on that, and I think having people who are just interested in way software used in very diverse environments really helps.

Yes. I mean, not only the game community is, as I said, historically not doing lots of open-source and not discussing lots about what they do.

Many small companies using Lua embedded as well, they're a type of groups who'll always be writing everything from scratch and not something specific to their use cases and not putting things, not putting new modules on Lua Rocks,

not using things that are on Lua Rocks, and it's a process. I remember Ishan, who is the lead developer of our Packet Manager of Lua Rocks. He will go personally to GitHub repositories

and say, you know, this could be Lua Rocks, and just 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 it will be 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 gonna meet at this place, everyone show up, and some people will show up. So, you'll say, oh, no, I'm gonna make this event, and I don't know if we're gonna 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 auditorium was full. 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, LuaWorks, I remember we discussed it last year, and honestly, as a guide person, I'm a bit jealous of things like LuaWorks, 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 nowadays that it's really helpful to have this kind of infrastructure, and we don't really have it in Guile,

because, yeah, 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 yeah, that's not really something we wanna 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.

Okay, a couple more questions, and then we're gonna open it up to audience questions, I think. But you mentioned infrastructure, and I think you were talking about language infrastructure, but I'm really interested in the topic of infrastructure generally, right? So what kind of infrastructure support do you have, would you like to have, whether or not it's

being under an umbrella organization, Guile's 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 LuaJIT was, again, it was a independent project, but always funded by a mixture of people in the gaming industry, Cloudflare, other people like that, and so we've kind of managed without any kind of overarching organization.

I think it's kind of worked okay. 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 I think that 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, and so I think those kinds of things, it's good to have some focus around some of those kind of unifying things, but overall, the little kind of hymns that Lua has, I mean,

around the projects have generally worked quite well. Yes, I think you're right in the sense that Lua has been doing all right 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 all right. I don't know, I have 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 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 who are responsible for working on the language implementation, so they're the PhD students who are doing their teases,

and they are the ones who are organizing the Google Summer of Code because they want to, so they are all locating their time, they are doing something for the community in that sense,

and they're a very small group of people, there are two or three people who are university professors, so the reason one person was allocated to be responsible of managing this part,

and I think that this will be very useful. Yeah, I think Google Summer of Code is one of those things where there has to be an official organization for them to consider you, so it does help that we've got this kind of, PUC which we can kind of use as that for some purposes,

but it's not, yeah, that is one of the cases where Google doesn't let a community have students for Summer of Code, which is kind of 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, from other organizations as well, I mean, and I think generally, you can make Summer of Code work for other means, I mean, quite often there's other organizations

that are interested in things. So I think Gail is quite different from lower in this respect, because, so Gail 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 holds the websites,

that holds the key repositories and all that, this is all, it all comes for free for us, so to speak, and it's, we know it's being handled by people who will remain true to their mission, and so that's really a great thing to have. Apart from that, I think Gail is really

some sort of a grassroots kind of project in that, I mean, unlike Lua, 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 what Emacs does

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 Gail code, but that's still a little bit marginal, I guess. Yeah, 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 way where it helps

to have an umbrella organization like this. One last question before we get to the audience, and that's, so it seems like, to me, that we're in an exciting era when it comes to languages, right? Like 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, don't, like, you know, and though there was interesting work being done on virtual machines, I feel like, no, like there, but like now, there's so many interesting things going on, you know, from type stuff to just about everything, so what are you most excited of

about language design outside of your project, outside of Guile or Lua? What are you, or it can be about each other, but it could also be about something, a completely different language. What's most exciting to you right now, that maybe you wanna bring into your language, or maybe you just think is interesting externally? Do you wanna start?

Yeah, I mean, I do think it is, it's a good, interesting time that new languages are taking off relatively quickly compared to, I mean, you know, compared to the fact that, you know, consider, I mean, Lua is over 25 years old, it's similar age to Perl and Python, those languages,

and those languages have served us well, and they've been incredibly helpful over the years, but it's nice to see a whole bunch of different languages. I think, I mean, I've always, I was exposed to functional programming quite early on, and I've always been really keen on strong typing

for many use cases, and I'm, you know, 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 that 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. It'd be interesting. I mean, there've been some experiments

with sort of gradual typing in scripting languages, but I'm not sure how useful they really are. I mean, I sort of sense that the, in a way that the thing that's, the competition for something like Lua is not big, complicated, or 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 rather than, shall we use a strongly typed language for scripting or a weakly typed language? It's the less of a, it's, that's not really quite where the choices are. Well, I could use Lua embedded in 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 Alex here. I haven't done much functional programming yet.

I've done a lot of Haskell in the university, but it was one of those modules that as soon as you get your grade, you go like. And so I really wanted to get back to it, and to me it seems like Alex here is a very nice opportunity.

The community seems active, which is something important to me, so normally Haskell doesn't do community much, and well, since Ruby, some sort of adopted some of the Alex here activities

because of some important key people who are common to this, and is 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 Alex here

very soon. Yeah, 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 am really excited about

what people are doing with it. It seems that it's targeting a very wide range of applications, and like yesterday, there was a talk about microkernel 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, right? 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 closure, where 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. I mean, there are so many things going on there that occasionally, we start chatting on Hashgar,

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 M, for instance. I mean, there are people working on Haskell, yeah, Haskell compilers that generate JavaScript.

I think that's a more fruitful approach, but yeah, yeah, there are so many things to be excited about in terms of languages and functional languages in particular these days. So for Guile, 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 Racket have showed that you can 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 not so great, right? So that's one of the things I would like to explore for Guile, yeah. Cool, so let's open it up. Who has questions from the audience?

Okay, so the question was for Guile about the relatively few amount of language bindings that we have.

Pass that over to you. Right, so I mean, yeah, this is true. We have probably much fewer bindings than Perl, for example. I think the situation has been improving, though, since 2.0, because with the FFI, the foreign function interface, it's 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 LuaJIT was that it came with an FFI, and it does make an enormous usability difference, and it's kind of, it's part of what I spoke to earlier

about the division between the two communities, because everyone who uses LuaJIT writes FFI bindings, which are not available for the standard Lua, and writing bindings for both is twice as much work, because they're so different, and we've talked about some ways to fix that, but it's difficult, because Lua's very strict on,

we only use standard C, and you can't write an FFI binding in standard C, so we've got 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. I mean, often the FFI binding is 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, so. Right, okay, so the question is about

generic interfaces for languages,

so that you can use multiple languages. Yeah, I mean, 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 heavyweight, though. And I think that there are,

you know, 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 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 gonna 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 high level scripting it's not very convenient. Actually, Guile started its 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, so to begin with we'll have Scheme and Emacs Lisp, and then we'll have Python and Perl and whatnot.

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 Emacs Lisp. And you would think that Emacs Lisp and Scheme are pretty much the same thing, right?

Oh yes, except there's one tiny difference, for instance, which is that Emacs Lisp has a special value, which is nil, which means both false and the empty list, whereas Scheme doesn't have that. It has instead the empty list and false, which are disjoint. And that tiny detail already causes a lot of headache.

And then if you look at guide two, there's a NECMA script, JavaScript front-end also. You would think JavaScript is a dynamically-typed 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 wanna add anything, or should we go to closing remarks? Yeah, 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 Guile here.

I encourage people to close in a little bit so that people can fit, but yeah. Thank you.