The Standup with ThePrimeagen - 2 Language Creators vs 2 Idiots

Episode Date: August 18, 2025

When traffic spikes, Neon’s serverless Postgres autoscales to meet demand, without all that extra ops work. Get the free plan at https://neon.com https://twitch.tv/ThePrimeagen - I Stream 5 days a Week https://twitter.com/terminaldotshop - Want to order coffee over SSH? ssh terminal.shop Become Backend Dev: https://boot.dev/prime (plus i make courses for them) This is also the best way to support me is to support yourself becoming a better backend engineer. Great News? Want me to research and create video????: https://www.reddit.com/r/ThePrimeagen Kinesis Advantage 360: https://bit.ly/Prime-Kinesis 00:00:00 - Intro 00:02:13 - neon.com #ad 00:03:23 - Why Functional Programming Failed? 00:10:20 - Erlang is Functional AND OOP 00:15:00 - The Ruby to Rust Pipeline 00:26:00 - Ginger Bill Rust Rant 00:29:53 - Are Macros Good or Evil? 00:43:30 - Printing in Rust VS Odin 00:48:00 - Mechanism Not Policy 00:57:45 - LSP Hater VS LSP Lover 01:04:20 - are Package Managers required? 01:21:10 - Advice to Future Language Creators

Oh, nice. Oh, hey. Oh, hey, I'm here. Hello. Wow. On time. Like, right on the dot. That's incredible.

You know, there's a first time for everything. Welcome to the standout. So I haven't eaten anything all day yet. That's good. We got all time. It's the standup. We can eat. No, you cannot.

The last time I did stand up, I used to eat like toast and stuff in the mornings. It was great. That sounds very British. It's been like seven years ago. Yeah. We eat toast in America, too. No, no, no, only we eat toast. Don't you know this?

We invented the concert of toast. No, he didn't, TJ. And basted eggs. No, it's lies. TJ's just trying to fit in. Don't listen to him. Drew. Sorry.

I've never had toast before. I just wanted to be part of something. Yep. Okay. It's okay. Don't worry. Yeah, yeah, yeah. Yeah.

Yeah. Anyway, sorry. All right. Today on the stand-up we have with us, Jose Valim, and Ginger Bill, creators of Elixir and Odin, respectively. Today, the stand-up, which is streamed every day, Wednesday at 11, and Friday at 11 a.m. Montana time. That's the best time, right?

We are now, let's see. What is the topic again? Oh, yeah. Why didn't functional programming take off? And we brought on two of the greatest language experts that I could possibly convince to come on to this show to tell us why this did not happen. So obviously, Jose,

You probably have a slightly different perspective even on that statement, considering the whole elixir thing going on and probably the community you're surrounded by, makes it feel like functional programming is quite successful, if that is true. But I guess- Is that implying it's not? I mean, he just won. Hey, he's in top three most loved languages, prime. That's true.

Neil Vim's number one most loved editor, it doesn't mean it's popular. Well, it was popular, though, anyways, but that's fine. Sorry, I couldn't hear you over Gingerbill typing. What is this a stand-up, Ginger Bill? Yes, it is. It's a stand-up. I was just typing. Sorry, just a friend on Discord. That was all. So, shoot.

Just tell them, just go away. Hands left. Teach, teach, teach, I've got a billion-dollar idea. I've got a billion-dollar idea. I'm listening. What if we use state-of-the-art GPT rappers to monitor live streams for ATIQ keys being leaked? Isn't that a little too niche?

It's pronounced niche. And of course not, according to my lived experience. It's very common to leak API. I just need you to set up a database that can handle my scale. All right, all right. I'll use Neon so you can scale up in cases happens. On the rare chance you don't get any traffic, it'll scale down so it doesn't cost you a fortune.

Oh, we'll need scale. Hey, Teach, uh, you know that site we made about protecting API keys? Yeah, dude, you were totally right. We didn't need to have a database that could handle your scale. Um, people are using that to seal API keys. Wait, Prime. I didn't notice you were live. I'm not live. I'm not lies.

Yeah, yeah, yeah, yeah, a special deal only for today. For every bit you buy, I'll pay you back two bits. On the plus side, your database is still up. When traffic spikes, Neon's serverless Postgres auto scales to meet demands. Without all that extra ops work, get the free plan at neon.com. Curious, like, why didn't, why do we have, like, as the mainstream JavaScript is kind of like seems like number one, why isn't it more of a functional approach? All right. So I do have some opinions on this. And if you were like, well, so there are many thoughts. So one of the thoughts, so the first thing I'm going to say, like, if you were part of the functional programming community or kind of listening involved over the last, you know, decade or even more, very frequently you would hear that functional programming one,

because, for example, Java would get streams, or Java would get lambdas, or languages would bring more type inference, right? A lot of ideas that I'm not sure, I'm not, I'm not going to use the word pioneered, but very popular, very widespread in functional programming cycles for a long time ago, right? And so a lot of the ideas,

in functional programming, they became mainstream, right? So in that way, I would say that if we look at functional programming as a collection of ideas, as we look at object orientation, as a collection of ideas, with time, we look at those things, and then usually we say object orientation, each person that you ask, you get a completely different definition, Alan Kay, I believe he's the one who came with the word object orientation. And it's like, well, when I was not thinking, when I said object orientation, I was not thinking about what C++ has. Right. So I think what we did is that we looked at those things.

We absorbed a lot of concepts and a lot of ideas from them. Many of those concepts and those ideas, they became mainstream. And then some parts of it did not become as mainstream as everything else. Right. So that's one of the things that I think about. Like, well, we got a lot from functional programming. But the other thing that I think about, so I was even mentioning to Ginger Bill, like just before we were chatting a little bit, getting to each other, that I'm actually, I'm not sure, like, the term function

programming, like saying elixir is a functional programming language is that quite useful today. It's like, and there is like a technical discussion, a marketing discussion that we can jump into it. But yeah, I think I think we learned a lot of the lessons that we had to learn. And then if you look at Go or Rust, those are not object-oriented languages. But they are not, they don't say they are functional programming languages either. So, like, we're having those more recent languages that are fine with, like, oh, we can say it's systems programming, but C++ is systems programming, but they say object.

Like, so there are new languages that are fine, like, not necessarily putting a label on them, on the side of functional and object that oriented. And so, and that comes back to me like, well, maybe in 2025, Elixir maybe doesn't have to put the label. it is functional as well. And then if we don't put that label, what it is? So I'll shut up for now. I'm interested to know, because I agree with I think a lot of ideas from functional

programming are just very mainstream ideas now that lots of people think like, oh yeah, of course every language has, whatever that might be. I'd be interested to know from both of you. What? Saying what ideas? Yeah, every language has. No, not every language. That was what I was, that's what I wanted to ask, though.

Because there are some great ones that don't have all the functional tropes inside of them. Yes. That's a setup. Yeah, but I was interested to know, like, from each of you, what are, what are some, like, ideas from functional programming that you're happy got, like, are sort of catching, like, popularity? And some that you are surprised haven't yet. Ginger Bill. Ginger Bill, you first. Right.

I have to first define what I mean by functional programming, right? Great. That's hard problem. So again, as Jose was kind of saying, functional programming is not really a very useful term. You could always use the joke definition where like most people think first functional, they go, oh, it's pure functional programming where you must have stateless and no side effects. And the reason why it has never caught on is because when I push a button, that's a side effect. So therefore, functional programming useless, right?

That's the joke answer. But the thing is, the functional thing is like, does it mean declarative programming that's like also oriented around like functions? Functions is a first class thing. You can pass functions around all you like. And those functions also may have state associated with. So the closures and such. So is it like, oh, is that what is functional programming fundamentally? And if that's the case, all object-oriented programming languages are functional.

Right? Because what is an, what is it? Actually, what is the closure? Closure is an object, right? It's got state and an operation. I'm not trying to say that is the case. I'm just kind of saying, like, this term functional is getting a bit weird. But again, many people just think it's Haskell.

And I don't know if some people would agree, but there's a reason why Haskell never took off. Why? It is effective. It's effectively a research project at the end of the day. It is mostly a pure functional language. And as the joke kind of suggests, it is kind of difficult if you want to do anything mutating date.

and a lot you take in state. And a lot of programs are fundamentally want to do that. And also Haskell is kind of research projects who has everything in it, including the kitchen sink and your mother's dress. Or I don't know everything in it. And it's just, it does too much. So it's really sometimes hard to read it. And the people who enjoy it are usually so high IQ. I'm like, I don't understand anything you've just written.

I'm sorry. It's too complicated. So it's kind of, okay. What features do I think? place. Well, I already think closures are everywhere, right? Every single language has got closures. But, and then there's also obviously the immutability aspect, which I don't necessarily think is good or bad. It is, depends on what you're doing. Right? But to pass it on Jose again, yeah. So you, before, you said that Erling is your favorite functional programming language.

Yeah. So what do you like about Erling? I think that's a good, and I'm asking it because I would love to see if the parts that you like are they what people would classify as a functional part or, you know, yeah. There's another way of phrasing this. Erlang is also my favorite Oop language, which is going to sound bizarre. But the reason why I'm saying that is Erlang has clearly got its concurrency model is better describes like CSP, right? you've got processes CSP for people know it's called

communication sequential processing so you have processes which is just thinking of a generalized thread green threads is another way of calling them this is what go routines are in Go at the same thing right at the end of the day and then you communicate them by sending messages

cross them so in Go they have channels in Erlang you got like the send and receive kind of operations and the same with Elixir as well don't you got the send off the functions and then the irresceive blocks and such. And that kind of aspect there is very, and then everything's immutable by default as well.

So when everything is passing all the messages, there is immutability and also memory safety on a per process basis. So this is kind of a very nice way of dealing with things. A lot of other functional languages who are trying to deal with ideas of concurrency and such, try and do other approaches and I personally don't like them that much, those kind of models. I do like the CSP style and while like Go does. The only problem is it requires a very heavy runtime and it doesn't really scale if you want to start then doing manual memory management like in Odin. So then you have to think, damn it, I can't have that luxury. Yeah. So to me, the beautiful thing about Erling is that, so we are talking about those things about, well, you know, like a functional, well, so if you take a

functional programming language, there are a couple of things. Some people are going to say that a type system is kind of a requirement, like having a hinder, munier or a similar type system is a requirement for being functional. It's a separate discussion. But if you get like the things that make a programming language functional, like immutability pattern matching, when they were designing air laying, they didn't start with that. They didn't say, look, we want pattern matching. We want immutability. What they started was, well, we have to build a concurrent, distributed, reliable system. And then they realized that, well, if we have, if we have, so far concurrency, we need to have many things running at the same time, processes, right? So you have all those

process, which for those who are not familiar, when we say process in Erlang is lightweight threads of executions like go routines, right? So we have millions of those all running at the same time. And then they realize that, well, if those things, they have shared state, if one of them break down, maybe it broke down, maybe something went wrong while it was mutating this shared state, which means that now you have polluted state in your system and which may break all the other process. So they were like, well, shared state in this case is going to get in the way of building a fault tolerance system because if you have a failure, you can no longer trust that shared state. So it's one of the things that keep going back like to discussions with the

Leng team, like people are like, oh, were you trying to do like function or like no, they're like, no, we want to build a resilient, robust system. And it just turned out. that for the kind of system we wanted to build, immutability was really essential. And that's why it's immutable. And people, and for me, like, I had the opposite kind of introduction where I wanted to build concurrent software. And I was doing Ruby running into a lot of mutability issues. And then I learned functional programming.

And then I was like, oh, immutability. So for me, like, for me, the thing that defines functional programming, is immutability. That's my interpretation, right? Because that's what attracted me. And then I ended up with Erlang, but they did not add immutability to be functional. So I think those discussions are very interesting.

So could an object-oriented style language like old Java, if it just was immutable, like everything you passed around was copied wholesale, would that be considered functional then? Well, so, okay, a couple of things. Did you know, I'm going to regret saying this. The first version of Elixir, which is on GitHub, was actually object-oriented. I was trying to build, like, I was, like, coming from this object-oriented world.

Like, well, what if I can have all those things? It was not good for many reasons, right? But to your question, to me, it's like, would it be a functional programming language? Well, according to my criteria, it would, it would, it would, it would be if that's my only criteria, right? But here is what I think about this. So why do I like immutability? For two reasons. It makes the code easier to understand.

For me, it's like, well, if I'm calling something and I know that that thing is not going to change somewhere in memory far away, right? I know that anything it needs, if I have a piece of code and everything, that it needs to function, I give it as an input and it returns as output. That code is clear to understand. I know, you know, like Joe Armstrong, one of the creators of Erlang, he was just to say, like, object orientation is like, you think you are holding a banana, but then you are holding the gorilla that is, you're also holding the gorilla that is holding the banana, and then the whole forest that the gorilla is in, because, you know, you can call something, but that thing can connect to the whole world, and you just don't know. So, so to me, that's one of the big benefits.

And the other one was concurrency, right? If you have concurrency, if you're building a concurrent system and you're not changing the same place in memory, all the data races disappear. And then there are languages like Russ that already gives those benefits, right, through the type system where you can kind of like track the mutations. And so, you know, according to my criteria,

I wouldn't say that Rust is functional, but according to the criteria that I set for myself of I like immutability and what are the properties I get from it, I should be happy with Rust and what Rust is offering because it's offering those similar properties but through different mechanism. I wanted to ask actually about Rust

because I know a lot of like Jose, you came from the Ruby community and there was kind of, I feel like kind of a big you know, like parting of ways for some people stayed in Ruby, some people went Elixir, and some people went Rust. Like I'm interested to hear a little bit about

like your perspective from as that was happening and like your thoughts on Rust as a community where it's going. If you want to share it and then Ginger Bill, I want to hear you rant about Rust too. I would love both. I love both of these things. Yeah, honestly, I don't have a lot of opinions, to be very honest. Nobody's listening.

Nobody's listening. You can tell us the truth. You can tell us the truth here. No, I'm not, I'm not trying to, to, I just, I have very limited experience. Don't follow it. So I think we can jump straight to the. Brent. Wait, hold on.

Before we do that, why, why was the Ruby to Rust pipeline even a thing? Because I've heard about this, too, that a bunch of Rubyists went from Ruby to Rust. Like, why? Because they don't strike me as super similar languages. Ruby seems fairly productive and. Russ. And so it's like, I don't quite understand like that. Like, it just seems like a very bizarre pipeline, right?

Like, I totally get C++ to Rust because you're like, I hate that language, right? And then you go and you do something different. And you're like, this fixes everything. I hate about it or you claim to fix everything you hate about it. I get that. But I just, I've never understood the Ruby thing. I would have just said the Ruby people just hated Python that much that they went, I'll try anything but Python.

Oh, okay. That's reasonable. Yeah, that's my guess, actually, right? Because, yeah, that's usually what I find out when people like, oh, big Ruby fans are going, no, no, I hate Python so much and vice versa, right? Oh, so it's not that they're Ruby fans. They're just anti-Python fans. Yes, I think that's the case, yeah.

So, okay, so let me ask kind of, I don't know if this is true. And then you hear it, right? So I heard that a lot of people went from Python to Go, for example. Yeah, I saw that. So why would you think that happened? And I'm just wondering if you have any thoughts, because I don't think it's as drastic as going. I think Python and Go are definitely closer than Ruby and Rust. And I think most would agree with that.

But why would think somebody who is programming in Python are like, okay, I'm going to do goal now? I actually have a pretty good answer for that one. But, Ginger, I do want to hear yours first just because you're much interesting. My answer is probably similar to yours. Mine was like Rob Pike was, Rob Pike and Ken Thompson and Robert Grismer, who all created a go, mostly Robert Greas's main person, not Rob Pike. But they all made it because they were making sports autonomy. And they thought that they were going to attract those people.

And then they were really surprised when the Python people and stuff were coming to go. I think it's mainly because people wanted backends and their servers, and they wanted something that was simple language and compiled and type, statically typed as well, pretty much. And if when you actually narrow that down, you actually just get Go or Java. Java is not compiled, you know, but I mean, like, there's two options. And I bet many of them also have been bit in the ass by using Java before. So they went, okay, Go is.

Actually, so my store is pretty similar. or we went from a Python shop to a Go shop in 2012. And a huge amount of it was just because we're doing interning or string interning on the server. And Python just stinks at that whole thing. So we're just like, boom, use Go. And so to me, it was all about the fact that back then, Gay was really, really popular, Google App Engine. So like either you're going from Gay Python to GayGo. And like that was the big move there.

and it was for free, practically. You could have all the same data stores. You could have all the same libraries. You could have everything. You could just transfer straight. I just always wanted to say that. But you could transfer straight across with just go. And you could go from Python to go.

And it was like, it was actually super amazing. I also said interning, which is not the correct term. In my brain, I'm just thinking interns. But that is not the, uh, well, string interning. I think like you just don't make any multiple copies of the string. So you can then just keep bringing the back. No, no, no.

I meant kerning in my head. Oh, curding. String, curning. He was so excited to make the second joke that he literally did a plus track. I fumbled the bag for the gay python. I just always wanted to say that. I have had no reason to say Google App Engine in the last 10 years, okay? I even forgot that even existed until you wrote it.

Yes, and so Google, to me, that's actually where a lot of these Python shops went from. Is they're like, oh, I could have all, like, I could literally have everything for free that I already have, but just use Go instead. So let's do it. And also Go had a brilliant, again, at the time, a brilliant, just like web server built in straight away, done. And he just worked. And it just worked.

And scaled well as well. It was like much better than Python. So everything like, oh, Python pigeros, oh, we just have to learn about a bit static typing. And then off the races, you're there. So I can understand it. Completely understand why. But I find it still funny that the Go creators were surprised that they attracted Python people and not the CNC plus.

programmers. Yeah. I'm surprised that they thought that was surprising I meant. Yeah. So I would say, going back to the original question, I would say, I would imagine that a lot of that was like the Ruby, what Bill said, you know, like, you know, maybe you're doing Ruby and every programming language has its pitfalls, right? And then at some point you're like, well, I want, I don't want to be beaten by those kind

of bugs. I want better performance, right? And then I think community also plays a big factor. You can see like the Ruby community was always like very grassroots. Like one of my favorite events in general, programming language events is like Irruco, where the way it works is that every year they present, the conference happens in a different European city. And then at that event, people, and most often people who have never organized an event in

their entire life, they say, hey, next year it should come, it should happen at my city. So they go, they do a five minutes presentation, people vote, and then you have these people, they have a gong that they always pass between events. So it always felt like, yeah. So it's very nice, like very grassroots, very community involved. So I think all those things, like, so technically may not be different, right, but like in terms of community, there may be a lot of similarities. and people who wanted something different, wanted other types of guarantees, they would,

they would, you know, just try something else. And I don't know, like, because I've been, like, mostly part of, like, two communities, like really part of two communities in my life. One was the Ruby one, and then the other one was the Erleng and Alexer one. And it's kind of hard for me to assess what is the, what is the Alexer community?

because I play an important role in there, so I don't know if I can do that job, right? But for Ruby, at the time when I was involved, and it was 15 years ago, it was a very open community to ideas. Like any kind of idea people would try it out, and sometimes that can be a negative, right? Like sometimes you need to have a filter, right,

and not just try everything. But very open to ideas. especially when it came up, like everything that was happening, agile at the time, right? Like people moving away from Java. So all that led to a community of people who just want to experiment and try out. And I think all those things led to,

well, like a lot of people go into elixir, going to Russ, because I feel like a lot of them, they are movers, you know, they are early adopters. They are going to move anyway. It was never necessarily meant to be a long stay. we're still missing that ginger bill rant about rust you have anything you want to say was just going to say that i'm like you're not getting out of this yeah what am i what am i ranting about again exactly about rust here anything anything you want

to say it's the standout i mean i don't have to run you know what i'm going to be polite to russ programmers so i'll try my best not to be too insulting but i was if we go talk about the topic try and keep it on topic right um i would actually say rust is an mL in disguise pretending to be a C plus plus, right? True. Because if you look at it how its semantics works, you've got all, again, ignoring like the ownership of semantics and lifetime semantics,

getting ownership of semantics being, and I find some sort of cruel type system, right? There's the nerdy shit, just to get out there, so apologize to my language. And, well, it's got all there. Many semantics are there, you got all the pattern matching, all that. It's very ML-like, and then they've just gave it curly braces

to make it feel more at home for the people who are used to the C-Bus+, and in many ways, as you know, the creation of Rust is because of the people who are using like modern C++1 is something better because unfortunately with modern C++ you've got all the backwards compatibility of C and the other C++ stuff. So Rust is fundamentally in my view the an incarnation of what modern C++ tries to be plus all of the functional aspects of it as well. My issue, that's the reason why I don't like Rust either. I absolutely hate modern C++. I went through my phase of

modern C++ plus 11 was coming at and just before that as well. And I went through that entire phase. Can we, can I just interrupt you? Is it even fair to call C++11 modern C++? No, that was modern C++ plus compared to before, right? Okay, okay. Right, because you got to remember C++ plus before that they had the next time with like C++ plus 03 and stuff like that.

And C++ 11 was like the big change at the time, right? showing all the brand new features. They had all the ownership semantics. They're better into template improvements. The S-Fenay improvements. The new like smart pointers, the, all these new features which made it modern, if you know what I mean, right? Quote, quote, unquote, modern. So in that sense, that's what I would, again, saying C-Bus plus is modern. Very hard to say. But you know what I mean? That's what they were trying to say. But this thing is, that's the reason why I don't like Ross. It's fundamentally, it feels like that and that's made, I don't want to ever go back to that style of programming because I was

actually typing more than I needed. It was less productive. It just wasn't, I wasn't getting stuff done. It's the best way of putting it. So you're saying there's a lot of ceremony in the rust in the rust in the rust world. Yeah, yeah, exactly. Yeah, a lot of ceremony. There's a lot of, pardon for my language, but I like using the phrase because it's the best way of explaining it, but type masturbation. Yep, I love that. Um, um, um, we can, we, we can, we, we can, we, we, we can, Because it's literally you're doing something and you're not actually getting anything out of it. Now, it's not as bad as sometimes the typescript stuff I've seen with the LLM generated stuff. Oh my God, that's horrific.

But the rust stuff is kind of like that's where people are going down the line. And then you've got also the macros on top in Rust. And it makes me laugh because the very first thing you ever write in Rust is like, Hello World, right? And the first thing you have to do when you do a print is a macro. You don't know it at the time, but there's weird exclamation mark. And then is anyone ever actually looked at how the print, macro works in rust, just go look at it and then tell me you are sane after reading it. It's one of those where it's like, I think they've got a problem here.

And if they think this is sane, just to make a print, but then people say, no, no, we need it to be this case. And I'm like, look, I'm pragmatic. I would just add all that into the compiler directly. I would have just said, not make a generic macro. Just do the thing. That's like, that's very common. If your type system isn't clever enough, don't make a macro.

for it, please. But I think that's just my main criticism. Like, I'm not criticizing people who use it. If it's great for you, great. I just do not like using it at all. Okay, so I have so many questions. It's hard to just put them all together because I want to get Jose in here

because you also, in Elixir, there's also some macro magic that you can kind of get on. And so why macros? Why macros? But I'm coming back for you, Bill, with some Russ questions. I want to go to Bill and ask about macros first and then we can go back to Elixir.

So tell me more like, I think I already got part of your criticism about about macros and if I understand correctly part of it is well, the reason why it has to be a macro is because of the type system and you have to make the type system satisfied.

One of the ways you basically have two options you make that print thing a special property of the language that the type system is going to be aware you special case it that's one way they went the macro route but is there anything else like when you're thinking about

macros there are you like do you think there can be good macros you are there's the same right necessarily against macros per se is there implementation of macros

like yeah i'm just saying if you have a macro system you shouldn't do rust is not the way of the rust should do it. I know Elix has got it, especially you've got the ST modification stuff, which again, which is in an O-Lang, obviously. But I'm trying to weigh a phrase in this. Macros are usually, if you're having to use macros,

it's usually, not always, usually a sign of a deficiency in the language itself. Like there's something missing in the language. Like if you keep going to using this macro all the time, it's like, hmm, there's something missing in this language that I'm actually compensating with. The same with C, right? The reason why C has lasted over 50 years

is because of the macrosus, the preprocessor. If you didn't have that, C, I don't think C would be used anymore. Like, it's there because it gets around the deficiencies of language. It gets me to do bodges and makes you fix things that are missing and all this lot.

And I'm not saying that's a good thing or a bad thing. It's just more of a sign of there's something missing. I know. I love that. And the reason why I love that. So, for one, there is that saying, which is every programming language has at least one flaw. Either they have macros or they don't have macros, right?

It's at least, right? So the reason I really like what you said is because in Elixir is the reason why we have macros is because I was like, look, I have to build this programming language. And yes, a programming language is a bunch of spreadsheets. special definitions, like, you know, a bunch of keywords. So I was like, well, instead of hard coding all those things as part of my compiler, I want to come up with these smaller subset of syntax and compiler code and have that as my foundation.

So macros are there. So in Elixir, we have very few keywords, like death module, death. None of those things are keywords. Those are regular macros. And that was the design principle. So like and and I'm not saying like you're wrong, but I'm just like, you know, like it's very interesting. Say it. Tell me.

Come on. I want it. Yeah. No, I'm just like like this ying yang like you know like and I think like both can be true. Right. It's like it depends a lot of like. So so for me it's like it's very fascinating because yeah for us it's meant to be a feature. Right.

There is also the other aspect, right? And this is the issue with, like, a lot of metaprogramming in general, is how do I debug those macros? Macro compile time print statements. Next question. Yes, tracing. I can't put them into a debugger. This is actually something that's changed my mind because when I was creating Odin, I was going to have some form of, like, compile time execution so I could then inspect, like, the S.T. And all this, do all the magical stuff, similar to what, like, what Jonathan Blow was doing with his language.

And then as I came on, I never implemented it because I kept finding, like, I never kind of really needed it. But then as I was realizing when I didn't need it, it was very much like when I was set down, okay, I'm going to do this. And then it was literally the first thing before I even type to went, wait a minute, how am I going to put this to a debugger? Because I'm like, live my life in a debugger, really. And the answer is, oh, yeah, that's going to be difficult. Because this is actually the hot. This is really the biggest issue. A lot of people love all this fancy compound execution.

And they forget, you know, you can just write a program that writes a program, right? And you can just debug that meta program like any other program. Yes, it's not as all one unified thing makes it all feel magical. But also, you know, that metaprogram usually has to be ran once in a blue moon and then you can carry on. It doesn't have to be run every single time like other metaprogramming tools usually are. And then they usually have to rely on caching, if they've got caching and all this. And it's just, I find it funny because a lot of people saying you just brought the printfd debugging thing as a joke. But I think a lot of people just only do printfd debugging.

Like that's all they do. They don't even know that you can open up at like a debugger. Like, again, RadD debugger is a brand new one. You can add that or MDBG or Visual Studio or any of these visual ones. I hate just GDP so much. But I look like I am a printf debugger and I'm happy. I'm proud. Yeah.

Yeah, this is the thing. But I'm like, I don't even know how my program, other people's programs work. And like how are you not just stepping through the like the statements or the instructions and going like, that's how it works? I know how it works now because I've just seen how the state is a evolving. I understand the print-teph. Like, I do tracing as well, right? Tracing is useful when you work in a compiler because you've got all these flows and you want to know how it goes through the flows. And that tracing is a brilliant thing. But if you're not kind of doing compiler work really like that, maybe it works. I'm in a debugger all the time. Yeah. And that's, there you go.

There's my little rant. Yeah. So the thing about like macro execution and how you're going to debug macros. And that's going to be different per programming language. Maybe we can talk later about Zieg comp time. I don't know if you have thoughts. My criticism applied the same as that. It's the same problem. Okay. Yeah. So, but in Elixir, like, there is really no difference between compile time and runtime. So literally everything that you can use to debug a program at runtime, you can also do it at compile time. Yes. And so there is no distinction. So, you know.

That's the benefit. What my complaint is made with compiled static languages rather than a dynamic language rang on like a VM like beam, obviously. But there's, because in those languages, when you're in a more dynamic language, again, in a VM language, you have these abilities to introspect at runtime and insert code. And if it's, again, the beam is effectively ingitted it's set effectively. So everything is, you've got that beauty that you can use the same. tools because there is no real distinction between this compile time state and the

runtime state anymore it's all runtime as you say and the compile time state is mainly the very very basics if you know what I mean the basic type checking before it goes run yep and that's so my rant still kind of applies but it is the question of okay how if you were doing all this fancy meta programming how do you debug it and it is the question of tooling which a lot of people just, especially when the designing languages, forget. And it's like, do you not actually work on projects where you have to be in a debugger or do work on really complicated things?

And again, this is kind of one of the beauty things is those sort of dynamic languages do work. It's just the compiled ones they kind of forget. And that's why I, again, rust, rust macros, macro expressions, pro macros, whatever, whichever ones you want to use. It's hell. It's hell. And just reading them, let alone debugging them is, it's not pearl levels of, headache inducing, but it's close.

Hold on, Jose, I have to ask this question because I don't know how much all the macros throughout Elixir slowdown compile time, but if you were to go back today, would you put, say, the if statement in deaf modules, if you just had unlimited time, would you put those as actual language constructs as opposed to macros,

or are you happy and you actually would want them to stick as macros? So, unlimited time. You could, unlimited time, No, I wouldn't, that part I wouldn't change. So there are a lot of things that, so there are a lot of criticism to macros. And I think, and I think there are like some misconceptions. I don't know if we started doing Phoenix. So some people say like, Phoenix is mostly macros.

And I'm like, no, that's like. It kind of feels that way. Right. Yeah. But like, I was like, that's, I'm like, that's objectively a lie. Like I can. Yeah, Prime. Yeah.

Yeah, Prime. Dump. Liar. Lyer. Give me any, like, give me any metric that you want to measure, like invocations, definitions, API size, macros are going to be like 5%. The thingful is that the entry point of Phoenix, the router, it's basically macros. And then we can talk about why it's macros there, right? And but, and I think that gives the impression.

But then when you are in your controllers, when you are in your templates, when you are in your live views, it's just regular. code. So the entry point. But wait, what was the question again? If you had the unlimited amount of time and you could change anything, would you bring in any of the macro stuff you've built throughout the language? Like if statements. Any of those things, would you bring them in?

So they are yes. So I would not. I wouldn't change that part of the language. I think it's so essential for what elixir is. Like, well, the goal of the language was to be a small, extensible language. So you can

go and do whatever the heck you want with it, right? And building the language in itself with its constructs. Like, I have to say, like, me as a, my perspective is that me as the language alter, I cannot cheat. I cannot add a construct that is just for me because I decided so. So it's like no cheating rule. Like the rules that I have to create the language are the rules that you have to extend the language.

That's it. right? And I do my best to not cheat, right? I should not be doing that. And it's such an essential part of the lineage that I think, like, if you remove that, it's no longer lexer. It's going to be something else. But on the point of macros, I don't think they slow compile time. I think the issue and, and so, okay, so, so when I decide I'm going to have macros, the other thing that I had is how do I make macros sane, right? Like, because depending on how you design the macro system, it can be something that is impossibly hard to debug.

So when designing elixir, I was like, okay, because I'm having macros, it means that I'm not going to have a bunch of other features, like a global injection of code. That's not a thing that you can have in Elixir. Compile time discovery of modules. So there are other kinds of metaprogramming that other programming language have because I said, look, I'm having macros.

I'm saying no to all this stuff in order to keep the language simple, right? And again, like, the no cheating rule also means that, because I could say no cheating and then I could bloat the language and add a thousand different things because I'm like, okay, right? So all those things, they act as balance.

And, yeah, and I wouldn't change it. But one thing that is very interesting There are two topics that I want, it's going through my head as we are discussing those things. And one of them, like going back to types is, so I had like this no cheating rule kind of thing. And it has worked out well so far, but now we're working on type system for Elixir.

And it happens that the type system throws a huge range at the no cheating rule. Exactly because what Bill said, So if you think about a type system, the thing that you can express in a type signature, like what you can put in a type signature is actually just a subset of what the type system can actually do. The type system can actually do more, but the type theory just does not know how to express those things in the type system, which means that now I have a dilemma in that I'm typing elixir,

and then we have all these features that we have used for a decade, right? And I cannot put a type signature in them, but I can special case them in the type system. And then it will work in the type system. So that's kind of like the, and I think it goes back to what we were saying. Well, if you're designing a programming language and you want to do print LN,

the type system doesn't know how to deal with that, right? So which side, which trade-off are going to make? And that's ultimately like the thing, like you have to make all those decisions, all of those trade-offs, right? And make sure that at the, the end of the day, you don't have like the Frankenstein monster coming out of it, right? Yeah, but to explain like the print F one, I probably skipped over that too much.

But like when I made Odin, one of the first things I kind of wanted to add into language was runtime type introspection. Now, many people make something this. What this means is at runtime, you can actually say, hey, this is the type of the thing. Like, can you give the information about the type? And in Odin, it's really dumb. It's just a basic lookup table. Like, oh, this is a struct. This has got the fields.

Here's the names. Here's the types, here's the tags, here's, whatever, or other properties of the field doesn't instruct. It's that simple, because it's the dumbest one you want to do, and it's ones that pretty much people want. The thing is, is that that's one approach to do in a print statement. The other one is obviously the compile time one, if you do it a compile time language, right? Where it will generate a new print procedure, print function every time with the arguments you put into it. And that's kind of what the Rust approach is doing. Now, there are arguments for both, and how do I explain this?

The rust one sounds great because it's like, oh, you only meet the code for the own generate the code for the code you actually need to print for those types. Great. Yeah, that's combatorial explosion. That's like n factorial that can be as bad as because you've got all these different things. And then your executable size gets worse. You know, compile times get worse. And it's like you've gone screwed up. While the runtime type information approach, like which Odin does, it's a giant fixed cost.

But it's a fixed cost. I say it's giant, it's tiny. but it's like it's a fixed cost and you have one procedure that handles everything, but then you have this giant lookup table. So then you have these different things. So the compile times is faster, the co-generation is faster, and then actually you've only got one thing as well, so it's actually easier to deal with.

So it's kind of like, this is why having like, I know this problem from C++ Plus, other languages that do this kind of like compile time-based printing stings have the, will hit, and they will hit this problem of comatoll and explosion very, very quickly. And it's going to be, this is why you got tradeoffs when you have to think about it, because you have to understand which tradeoffs you take when you're doing design. So that's kind of a thing like when you do a print thing,

because there's multiple options. You can do it the generic ways, which is like runtime or compile time generation. Or you could just have, hey, we have built-in language. Like, if anyone's used Go, they have a bootstrapping built-in procedure called Printline, like Lockees or Printline. That's their bootstrapping thing. So when they were making the compiler, they kept that in to do stuff. They recommend never using it for anything.

But it's like, okay, that's kind of useful. but then eventually they want you to use the fumped package for everything and and the annoying thing about those things is that they are just going to bite you later on when people are actually using the language and they have large projects and it's like well now the the explosions in your face like all the combinatorials yeah it's a problem with language design that that rust creates a separate function kind of like some sort of templating style function for every single print statement you do. From what I understand, if I can remember correctly, yeah, I think that's the case. Now, please, if the chat must correct me, please tell me I'm wrong. I don't mind being wrong. But I think that's kind of how it works for the general prints. It might be a bit clever in how it can reduce everything, but I thought that's how it kind of worked.

Okay. Wow. And also, Jose, just to, when you say cheating, is this cheating in the same way, like Make is cheating and go? where it actually is generic when we don't have access to that level of generics and go for a long time, where, like, they get the special one, but you don't get the special one. Yes. Every time there is a language feature where, like, oh, can I implement this myself? Which is all languages they are going to have, right?

Like, there is always cheating, right? Like, there is always, well, but exactly things like that. That's what I want to minimize. And Elixir allows us to minimize this considerably, because, because we are bootstrapping ourselves on top of the Arlington virtual machine and a runtime, right? So we can really keep the amount of cheating low. But like, for example, places where elixir cheats is, well, data types, right? Like we have our data types, our lists, the posts, that come from our land.

You can't create a data type like that one that is going to work on pattern matching and all of that, right? But when it comes to language constructs, right, like control flow, all this sort of things, in Elixir, they are very few. They are very few. And everything is built on top of that. It kind of reminds me of like in Lua, they have this idea of mechanisms over policies, right? So Brazil mentioned. Shout out Brazil. You got to talk all the Brazil languages.

Right. But it's this idea that like instead of adding this huge set. of language features and then figuring out how all of them interplay, like, Lou is like, no, we're just going to have, like, oh, error handling, that's just a function call. You do P-call, and you get a result, whether there was an error or not, right? It's like, oh, it's all just, it's just functions. Oh, what are files?

They're just, they're just thunks, right? Like, everything is still just functions all the way down for Lua, right? And, like, how do we store data? Oh, it's tables all the way down. Which I think is a really nice, like, idea. In Lua, there's, like, not a lot of cheating from the language either, right? Like, it kind of does the same thing there. Yeah, I feel like Odin is cheating a lot then if you're using this definition.

Tell us more. I don't class it as cheating. This is the thing. Oh. It's fine when you do it. I see how it is okay. I know. I think it's great because I don't feel I'm cheating in this because I make up the rules of the game in my language.

So, therefore, it's not cheating. Oh, house rules. Oh, Gingerbills play. All right. Okay, so why is it not cheating? Or, oh, let me rephrase the question. Why is it good for a language author to have constructs only they control and allowing users to use it but not control it or create them themselves? So I'm going to phrase it slightly differently and then answer your question if it makes any sense.

So the first thing is when I approach language design in general, I'm coming very pragmatic. I'm literally asking what do the general things that people want and then I implement that. Right? Like in Odin we have a built in string type. We have a built in slice array type. to slices array programming as well. You can just add two arrays together and they'll do element-wise operations.

We've got matrices built into language. We've got dynamic arrays built in. We've got a hash map built in, as in its syntax level. It's not just thing. Now, the thing is, I added all these features because this is what people want when they're trying to use more high-level things.

Like when they try and use that in C-Pus+, operate overloading. Well, most of the cases of operator-overloading that they use are to create all of those things I've just listed. Or if they're trying to do... And this is the kind of the thing. It's not that I don't want to give people loads of power.

Is that if you... Or it is actually, if you give people loads of power, they will abuse it, right? But it's also... You don't need to give them the power. You can just give them the tools. Like the direct things, and they'll be polished. They'll have better semantics,

better error messages, better everything. This is kind of thing why I'm saying, I don't think it is cheating. But here's the thing. Odin doesn't have macro, so you can't even produce even further. You can't, don't have operator loading. And when you do need all these fancy things, you're just using basic data types and procedures. And that's it. So you now know where the, the base language is and then the custom stuff.

It's not merged into one. It's not trying to be hidden. And it's like some people are like, oh, I'd really like to have this fancy syntax. And I'm like, no. And that's a very common answer I give most people is, no. Yeah. I agree with that. I think that's exactly the trade-off. And I think going back, I think like everything chips and they don't cheat to certain extent.

It's like what the language chooses as an extensibility mechanism, like operator overloading. Are you going to have those things? Or are you not going to have those things? And I think the problem is when a language has too many constructs. I feel like there is a line in there. where the language has too many constructs that only the language can do. And when a developer has to build a library, they cannot build something that feels like that language that's, that's, you know, like sticks out like a sore thumb. That's when you know you, that's where the friction appears and that's when people feel frustrated.

But if the thing, so you can do a lot of cheating, right, like where to my definition. Yeah. But if at the end of the day, you have the mechanism where people can go. well, maybe somebody wants to do a red-black tree and it feels just as good as the hash maps in the language. It doesn't feel like very dissonant from the rest of the language.

Or you apply that to other things and they're going to be happy, right? Even though they are not going to get all the way, but if they get like 80%, 9% of the way, then they'll be happy. They'll feel like, okay, I feel like I'm expanding, I am contributing, I am

extending the thing that use every day. Yeah, it's just, just for me, I've been seen so much abuse of like operative legend, for example. I've seen so much to the point where I'm like, yeah, you're not having it. I can't even trust myself with it, lelow and others. Like, seriously, um, I've seen people who have overloaded insane stuff and then other languages now allow custom operators. I guess I'm looking at you, Swift. Um, and oh my God, it's actual hell. It's hell and you're in making it worse for everybody, man. It's like, I'm now looking at, what am I looking at? This, this soup of punctuation everywhere. And I don't know what it does. I'm like, can you just have a nice procedure or

function call that just has a very long name that tells you what it is? Just say, this is the thing that bakes the chicken. Just have that. It would be wonderful. Rather than having the percent sign that tells you, actually, this is doing the fancy baking the shing for you. I'm like, of course, it was so obvious. No, no, it wasn't. I have actually seen some really horrific operator overloading and yeah that's why i just no no so that's why i implemented the things that people 99% of use cases even probably higher than 9% and just added them and then most people are now happy yeah those are two things set but yeah operator overloading custom operator those are two things that we like we're strongly agree with i'm like yeah like if you feel need those there's probably

something wrong somewhere right it's like but how can i have job security without those Like I'm gonna write them in and then I'm the only one that can maintain this library. Good question. Ginger Bill, you're stealing my job, dude. If you say that job security, until someone tells you manage it, they've done that, and they're going, oh shit, we need to get rid of this guy now, quick. It's too late by then. It's too late.

I know, it's like, damn. We're gonna have to slowly, it's like, gone, the time just, what is it, the garden time is going to be a very long time. All right, so speaking of too many features in a language, I actually wanted to go back. to Ginger Bill on Rust here. Do you think Rust ultimately will go in the same direction

of C++ where it just feels like every feature in the universe is weighing it down. Do you think it that is crossed this line? I think it did it pretty much years ago. Ooh, really? Yeah. Yeah.

Do you think that's a downfall in the language or do you think that it's a good sign? No, it's a downfall from the start. But again, as I said, I hated modern C++ plus and Rust is kind of the next step in that thing. And it already does all that. There's also these other aspects where I'd be very careful what I mean by this statement. You don't have to be careful.

It's just the four of us. No, no, no, no. It's just the four of us. No, I have to be careful because I know the internet and they'll misinterpret me no matter what I say and how clear it is. Like, I still get people saying, oh, don't you hate LSP's? And I'm like, I made a, I was like, I even caveated for that. And like, no, I just don't use them. If you're using me, whatever.

Right, this is the internet for you, right? What I mean is I think Rust as an idea should have been tested at a smaller scale. Like they should have had all of the ownership semantics, lifetime semantics, which are mathematically prudent, obviously. And then just had them in a very small C-light language with none of the actual other features. And then they should have gone, okay, how do we make this effectively more ergonomic? And then start thinking, okay, we need to add this, then add this, and then add this. But they didn't. They started effectively in the middle and went, right, we're going to do all this.

We need all of the trait system. We need all of the macrosystem. They just started there and then that's what we want. And they didn't start from like, okay, where can we get? Because to me, Rust isn't that ergonomic. I know it's for many people, but like, the thing is a lot of language design. A lot of languages aren't that ergonomic.

Alex is quite ergonomic, actually. That's a fun thing I'll praise about it. But it's like Rust isn't. Rust is also fighting things. And I'm not saying the Borough Checker I'm fighting. I'm usually fighting the lifetime system. Correct. And I think.

think that's a lot of the times people think. Like, I actually want to, I don't want to define my lifetimes based on a value most time, which is how the whole rust thing wants. I usually want to do it with control flow. Like, hey, this value, this value is actually bound to a loop effectively. So when the loop resets, the lifetime is dead. Now, I know he can do that with ghost cells and such kind of, so you can get around those tricks now, the magical invention of a go cell. But even then, it's still a bit of not really what I want, if that makes any sense. I get it. Sometimes you just want, like, I want this thing to live for a function.

It's going to live for a function. It's going to, I'm going to hit some A-Sinks in here. It's just, it's here for this function. That's all I want, stopping annoying. I'm going to pass it around. It's alive for this much. That's it. That's it, people.

I want to specify that. And then doing that is hard. Yes. Yeah. You're saying, though, you don't want the value to define a lifetime. You want to define the lifetime of value. of Ginger Bill. Correct.

Indeed. Put that one on a t-shirt. I'm not going, okay? I'm not God. Okay, I've got a quick question. Gingerbill, since you're well-known for hating LSP's, and Jose,

you're well-known for loving them, and that's why Elixir has three. I'd love to hear what all of your opinions are on LSP in the modern landscape. TJ, how long have you been sitting on that one? I wrote that one. before we got here, boys, and when Ginger Bill mentioned LSPO was like, it's my top shot, boys. I love it.

I love it. I could not wait for that you love him so much. There's three. That better be a short. One unofficial one at the moment. I should think technically is going to get, there's two unofficial ones in Odin as well. Like, this is an IntelliJ one as well, I think. But not official in Odin, that's all, because official would mean I'd have to work on it.

That's about, yeah. And that's the, is that the main thing for you? You're just like, I don't want to spend any time on it. I don't want to ship it with the language. I actually have a main job to deal with at Djangra effects. So, yeah. Let's say I was a super big Odin fan. And I had a company, you know, Rangra effects.

And I was like, hey, we want an LSP super bad. I can donate either an engineer's time, full time, ad infinitum for the next, for however long, or the amount of money that you would require to implement it. Would you say yes to that as an Odin first class LSP? Or would you still say, nah, deal with the community. This isn't where I'm going to be. We don't do that here. Depends on the price, and I'm not even joking.

I'm not saying I'm being bought. I'm just saying it's more of like, okay, if you're going to do this, what I would have to do for Odin's, I'm going to rewrite the actual compiler completely. So then it's going to be built up from the scrowned up to the compiler and the LSP are the same thing. There is no separation. So you've got that there. Now, when I wrote the compiler, I wasn't even thinking about it. It's one of those regrets where I should have made the compiler be a library as well.

Like it should have been designed to be acted as a library. I just wrote it to be a single thing that runs chutes off and be as fast as possible. It is quite bodgy. It's all interconnected. It's not a library-based thing. But it's fast-ish. There's still slow bits in it and LLVM really slows it down. But that's the thing.

So if I was going to do the LSP route, I would just rewrite the compiler so I could use it as a library so then you can get the LSP aspects and you've got. all of that, especially a lot of it. That's what I'd do. And I, but that's the thing is next time I write the compiler, we'll probably try and design it so we've got the LSP. I know a friend of mine who wants to write new Odin compiler, calling it Thor, obviously, because it's the son of Odin.

And then, um, very cute. And he wants to work on that. And I'm like, sure, but he doesn't have any time. Because of course, he works at Djangrafx as well. So we have, it's called lack of time. So that's half the problem. Yeah, people bring up like LSPs, right? It's like, oh, why can't you have a good LSP, right?

And then they usually, yeah, they would usually mention like TypeScript or something from Microsoft. And they're like, oh, like, why can't you have it? And I'm like, oh, are you telling me that I should out of nowhere just do this project that Microsoft spent millions on because they had to restructure the whole compiler and redo a bunch of things to support it, right? Like, that's the thing that people means. Like, it's actually a complex problem, right?

And, um, I love that they picked TypeScript, the one that, like, everyone has to restart constantly, doesn't scale the big projects. It's terrible. Categorically, the worst known LSP, also the inventor of the LSP. Yeah, this is also the other thing about LSP. Like, this is actually like implementation detail. I actually dislike about them. They were designed by Microsoft, obviously, and it's a protocol over JSON. It was JSON op.

PC or whatever it is. I can't remember what the exact thing is, but they're sending a JSON packets to send all this information. And they've got a borderline like saying, hey, this is a this is kind of the general idea we think all most languages work on. And it's kind of like, great. So if your language doesn't fit in that category very well, you're a bit screwed. Or you want to do something else. It doesn't work. But this is Microsoft. So they kind of standardize it. It said it worked for all these different languages we kind of test it on. It's like, great, great. Or if you don't use Unicode 16, which is definitely the most popular recording it is it is the best utf 16 is the best because of course Microsoft have been using it

for the past 30 years hold on a little bit longer hey javascript was originally all utf 16 okay buddy so is python that's why yeah yeah someone's like that i don't think that's the reason why for javascript what is javascript i i think the reason why utf 16 is used is because um for most languages, you can then index it and get the right code point. However, that's dangerous as hell, because that means that's for code points. Okay, I'll explain this. I'm going to explain you in code. Okay, but here, Gingerbill, though. I got a question. So, like, 16's bigger than eight. Yeah, explain that one. Gingerbill. Checkmate, Gingerbill. I know that's mean, man. It's bigger. Unicode version 8 through, Unicode version 16.

32. What about 32, man? Yeah, we should be using that. You know what? Registered, aligned Unicode. We should get Unicode 64 and just start reading them like that. That would be the true superiority. UDF 64. Microsoft, we're ready for it. It's a little bit wasteful, man. Come on, come on.

And also, we now, nowadays we can just have even bigger registers. Like, how big are the biggest things? 512 is the biggest register we have on some machines now, right? So that's a little great. Well, if you think how many emoji we can have. That's what I was just going to say. There's so many emojis left in the world. You don't have to have all of the different things like the Fitzpatrick color modifies and the family modifies and all that.

You could just have one giant emoji. You have them all. I think we solved it. We did. You're welcome, Microsoft. Yeah. I'll set my bill. We're going to be charging you one Microsoft salary for that.

Oh, I'd like that, thank you. By the way, no problem. It would have to be a distinguished engineer because, Only a distinguished engineer could come up with a with a plan this good. Oh, yeah. All right, Bill, I'm glad that I'm glad to hear that you also have feelings about Unicode. I'm glad to just see that spark, spark happiness within you. Speaking of feelings that you have, Ginger, Bill, let's talk package managers.

Oh, yeah. Okay. Okay, okay. This is my last question that I had prepared. So we can, we can end. That's fine. That's fine. That's fine.

I don't know if Jose is going to hate me or not for this Well I figured if it goes bad Well I just cut this from the end of the episode And then we No no no we turn it to a clip and we put it on the clips channel There we go And I'd be really serious voice Looking into the camera going

Yeah Yeah Yeah whatever yeah You won't believe what Ginger Bill said about package manager Even worse than the LSP's No I actually think LSP's a fine I actually hate, I think, how do I put this? I'm going to use real words of languages.

Straight to the camera. Package managers are evil. Oh, that's so crazy. Let's hear more. That's why it's called Hex. I didn't put two tunes together, but yeah. I think we discovered something big, Chad. All right, Ginger Bill.

Tell us a little more. I want to hear you and Jose talk about it. To explain what I mean, I need to make some distinctions again. because, of course, I like making distinctions. I like Aristotle. So the distinctions here, I was like, you need to make a distinction what are packages, the package manager, package repository,

and the build system. These are all separate, and in fact, you can have them all be separate and have no relation to each other, pretty much, right? So I have nothing wrong with packages whatsoever. In fact, Odin has packages built into the language. I have nothing wrong with repositories

because that's how a lot of people find discover new packages. It's effective just a search engine, right? there's nothing yet search engine. I use Ducklergo every day and Google and many of the search engines because they're all pretty bad now, so I have to keep swapping between them all. The other aspect is I don't build systems. That's usually like again, that's language dependent. If we're talking about languages here, obviously.

So in Odin, I try and make it minimize the need for a build system entirely. Like Odin build dot will compile even those complicated stuff for Djangrafx because we define all the linking stuff in the source code itself. So in the language itself, like it's not. separate and if we don't use it doesn't get linked against and so and so forth. So that leads package managers. What do they do separately? Well package manager effectively downloads the stuff from a repository and then handles the dependencies and tries to fix them around and everything like that and downloads its dependencies and it's dependencies and you can probably see where my criticism's going. This is

automation of dependency hell and the problem is is I've said this before, I even said this before on a stream here before, like not everything needs to be automated, especially hell. And dependency hell is a real thing that I think many, if any people said I'd been on a large project before, they'll be, been in before, right? You've got literal thousands of tens of thousands of dependencies. And you don't know if any of them work properly.

You don't even know what the bugs are. You don't know how it's all going to be handling. And it's awful. And it's just like, this is the wrong thing to automate. if you actually had to do it manually, it doesn't stop me getting into hell. You can put yourself into hell. That's really easy.

Actually, everyone puts themselves into hell. You do that voluntarily. But the thing is, it's more to do with how quickly you can get there and also makes you have to think. If you download it manually, you start thinking, maybe I don't want this or maybe I actually can do this and merge this. And then when you update, you just have to be very careful and do it independently and that stuff.

That's why general criticism is like is automation up for that problem. And this is why if you look, MPM, it's awful. The other problem is also packet managers, is a lot of package managers actually have to find what a package is because the language they're dealing with doesn't have a well-defined concept for a package either. NPM is the best cost, a good example of this, because also there's multiple of the package managers for Node that I can never remember. Because that now means you have to have a package manager manager. That's apt. That's apt.

That's apt. Paru are the package manager managers. This is where things get like, because you haven't got a well-defined concept of what packages in the language, that happens. Now, luckily, Elixir has a well-defined concept of what a package is. So Elixir doesn't suffer from that problem. But loads of languages don't have a well-defined one, and it really, really shows. Yeah. And this is why I'm saying it's evil in the sense that it will send you to hell quicker.

Hold on. Before you jump in there, Jose, I have a quick question for this one with Go. go just seems to have this weird thing where I don't seem to need a lot of packages does go having a package manager but not seeming to like the entrance to hell seems far and hard to get to is there something special about go that never quite arrived there because like I don't have 400 dependencies when I do a go project yeah so go has a really good core library it's not a library right that's it has the batteries included like that's what I tried to do with odin like when you download in you can start doing pretty much anything in it right I just

want to be able to download and here's the difficult go is like that. That's why if you want to make a web server, you pretty much don't need any third-party libraries if you just want to make a HTTP server and you're done. You can even write a whole LSP. Like I wrote an LSP. Yeah. Do you just write it from scratch? No compilers. Yeah. So the Go standard library has a Go compiler in it. In fact, it has two go compilers. Mm, backup. Well, it has the actual Go compiler and then it has like the high level one that

you can use. Yeah, it's kind of, in the sense, it is kind of a backup. It's just like one's The Klingon of the French. Oh, God, that's a, that's a so nerdy joke, man. And it's so bad that I know that joke. All right. Sorry, Jose. You're bit. I want to hear the response.

Klingon-on-a-physiology. I can't remember the one. Is that one? No, no, I, that's pretty good. I agree with a lot of that. I like to say that the word dependency, like, lost all of its meaning to developers, Like in life, if you say, like, you have a dependency. It usually means like something you are response, which is exactly what it means in programming, right?

But in life, like you have a dependency. Yes. Like something that, you are responsible, right? If that thing do something wrong, like you may potentially end up in jail. Like, it's a thing. It's a thing where you should worry about. You have to take care about it every day. And package dependencies, they are kind of pretty much the same thing.

right so and and we don't we're just like oh I'm just going to add a dependency I don't know what it I don't know what it does it's just like this thing based on trust with no verification yeah and yeah and the package managers they they do automate that right so if you yeah I I agree like you have to if you're going to have like a package manager you have to have counterbalances for this thing. You need to have or a culture. I don't know, but you have or like discussions where you balance those things.

So when I'm starting a project, I'm not automatically bringing 1,000 potential like attacks into my, into my app or, you know, 10,000, 100,000 lines of code that I am kind of now on the hook to maintain it, right? If something goes wrong, you know. It's not even security things. So people say it always bring up security, like, of security risks. I'm like, they're not even the biggest worries.

Like at work, we use SDL2 for window handling and input stuff. And the amount of bugs that we have found, and we absolutely hate it to the point where we're actually, I'm actually going to probably write it in the next couple of months, just writing our own window handling map from scratch. Because then at least it's our code. We can depend on it and we can trivly fix it. And we're not relying on an extra dependency, right? I know many people are, but SDL is great.

It's used by millions of different things. I'm like, yeah, but we keep hitting all. the books. But it's great, but it's great, though. It's great, though. And it's like SDL3 might fix it all, but it's like great. But the time to integrate SDL3,

in the same time, I could just write it from scratch. And that's fine. And this, in some sense, I'm not saying I should I advocate everything that were written from scratch. I wish there were just libraries that just worked. But still, I have to depend on them. And they're a liability.

And not necessarily security liabilities. but it's just bulk liability. Yeah, liability. Agree. So liability. OTP helps a lot in elixir. Just like there's a lot of things that come with the air laying, like runtime and everything that creates more of a culture.

Like, I mean, when I'm doing elixir stuff, I'm using Phoenix a lot. So like, and Phoenix is a wide-ranging, large scope thing. You know, you do a lot of stuff with it. But it doesn't feel like it's, you know, infinite to pay. dependencies, right? It does feel like, well, after I get my first round of Phoenix ones, I'm not adding tons of dependencies every week to like mix those around. So it seems like there is kind of a culture in Elixir not to install a trillion things. I don't know. Yeah. I think I mean, I think part of it is exactly like I know I have this opinion. The Alexer Corps team has this opinion. Chris has this opinion. So we are very careful. We are not creating. a bunch of dependencies, right? And that ends up reflecting on the initial experience of a lot of people and they end up like propagating it.

But regarding dependencies, one of the things that I tell people is like, look, whenever you are going to add a dependency to your project, go and read the source code. Like just read the source code. Go through the thing. Like the amount of times I think, oh, I needed this dependency. And then I'm like, oh, actually, I just, if I get one third of three modules, I have the whole thing in my app, in my tests,

in a way that I can control without bringing all that other bloat. And then if the thing is good, you read it. And they're like, okay, I actually, I can actually trust this. This is good code. Or you're going to learn something. So a lot of my initial open source career came from that, came from looking at dependencies, seeing how it's done and say, actually, actually. I can just do something smaller and I'm going to publish that instead or oh I I don't like

the way this is implemented I can do something completely different which I think is going to work on these better ways and yeah just from reading dependency code I always read whenever I add something as a dependency I'm like that's my like that's my self-imposed tax you know it's like I have to read it if I'm going to add it I have to read it yeah if that's assuming you've got source otherwise you have to reverse engineer it. And I've done that a few times. But yeah, that is the problem. But if you, this is the point, people don't vet their code in general as well.

They don't check to see if it's good or bad. They just assume it works. There's this problem and it's a societal issue. Program is a very high trusting. In a place which is you should have the least amount of trust possible. But is this because, to put it bluntly, a lot of programmers are coming from very developed countries, which are very high trust for the most part, and their cultures are like that. So they're going to replying that to the rest of their world and stuff like that, and it hopefully works.

And I'm like, it's right, great. So you only need one person to do something malicious and everything, these millions of people who depend on one thing, you're screwed. And that's not necessarily a security thing. When I say malicious, they could just make a funny book, where if you click one pixel on the screen, it just now has Rick rolling you. But it could be... Next to a release. Next elixir.

Think about it. I know. I like that. Think about it. But no, I would actually argue, so I'm going to put a separate argument for why I think that it, why I think that exists. I think we've had a couple things. One, we've had a explosion of engineers over the last 10 years that are all coming into this, just at the advent of really package managers coming out in all these languages, right,

all at the same time. And so programming felt very daunting, right? Like when you don't know how something works, it feels very daunting, especially when you when you first start out. Like you don't know a lot about programming, so things feel very daunting. But the thing that I think is really confusing, at least this high trust argument you make,

is that there's this weird, it's almost like, gentlemen's amnesia, if you've ever read this, you go to a magazine, you read about horses, and you're like, oh, man, I know all these facts about horses. You flip to the next page,

it's about JavaScript, and you're like, man, they got everything wrong about JavaScript. You go to the next page, it's about something else. You're like, man, I know a lot about Beatles. But then you're like, you just forgot that they were super wrong on the thing you understood,

but you think everything else is completely correct. And so engineers, like you will never find an engineer that doesn't go like this. Oh, my coworkers, dude, some of them are so horrible.

Hey, here, let me download this library off the internet. This is going to be awesome, right? It's like, it's crazy. It's like they just, they look and go,

oh, wow, yeah, like one third of our staff can't program anything. Also, I'm going to trust every open source package I've ever downloaded. And so there's like, definitely like a gentleman amnesia

for programming code that I think we just put on that people who do open source or open things are the best of the engineers, which there's no, you know, there's no gate there's no gate there. It's just a thing. It's because they're assuming programming as like any other industry,

like engineering that's been around for thousands of years or science, which in modern compilance has been around, what, for 500 years. Again, like Gellman Murray explained in there, he was a particle physicist, right? He is the guy who came up with and then came up with quarks, these somatomal particles that make up like protons and neutrons and such. And the guy who came up with his name. You can have to make stuff up to make your point, Ginger Bill. Ginger Bill, stop trying to sound smart, okay?

Yeah, okay, come on. Stick the programming. Stay in your lane, buddy. More fancy, because I know where the story comes from. I know. You meant quite a lot? Those crystals? No, no, the crystals.

Oh, so now we're... Okay, now crystals have power, Gingerbill. Okay. Okay. They had power. It must be true, okay? Look, he was a smart dude. He was also a wrestler, so you want to want to mess with him.

So, um, but no. Yeah. But this kind of thing. thing is like this is a it was Michael Crichton did it you know the guy made like West World or Jurassic Park he said he was friends with him and he was like he knows the show business this guy knows physics and when you read the newspaper they talk about it's oh this is bad and they all believe everything else and it's like yeah you do because you trust people you believe because I know this is my expert like this would go

back to my old Monarchie Plus Plus ram I was doing it because I was kind of trusting who I perceived to be the experts because they were all telling me this like on the internet you go on all these articles and conference videos and books, they all kind of tell you this. And I'm like, even at the time, I was like, this seems a bit weird. But hey, they might be right, because it might be as a scale on and as I go, this will benefit me as I go along. Because I was just kind of trusting this, what I perceive to be wisdom. But then as I've now gotten through more programming, I'm realizing there's no wisdom in this industry.

Non, well, the very, very little wisdom I would put. And that were in so many days. And it makes sense because as I've gotten older, I've gotten more knowledgeable about certain things. I'm like, there's no evolutionary selection pressure. This industry is probably 70 years old, 75 years at max. So it's like, this is not old enough to get rid of all the literally bad things. We haven't evolved quick enough. We'll find out in probably a few hundred years.

I mean hundreds. We'll find out where the good stuff is. And at the moment, I don't know if we know any really good ones. Like, I think the only kind of law that we have in programming, like Casey would say, is like Conway's Law, which is like the structure of an organization will effectively maps itself on how they structure their code

and their projects. But that's about it. Does that make sense? I got one last question to end. I can't believe you didn't say this. Ginger Bill. Books, you shouldn't read books. That's what he just said.

Books are for stupid people. Well known, LSP, and book, hater. Ginger Bill. Books. What are those things? I don't know. Just don't kill a tree.

Don't read books. You're killing trees, man. You hate the environments, Marr. I always quote the Simpsons meme. I'm here to lead, not to read. That's a great one. That's a classic.

Okay, my last question. Short, short answer. Think you got to boil it down to one sentence for each. If you're giving advice to someone making their own programming language today. What's the one piece of advice you'd give them? Don't do it. You can't say don't, Ginger Bill, because I know that's the first thought. I don't know. I wasn't saying that.

I was never going to it. Jose actually beat you to it. He was already like, don't, don't do it. All right, one sentence. Ginger Bill and then Jose. Learn the basics of how to do tokenization, passing, and when you do in passing, you only want recursive descent and Pratt passing pretty much, and then you start learning types of stuff. Start with a very, and the very, and, and, start with a very basic language. that, and I mean, when I say basic, I mean, can it do arithmetic? Nothing else. Don't try and recreate Python.

Start even smaller than that. Okay, so you said tokenization. So start with a crypto coin. Got it. Jose, you're up. Listen to Bill. Great answer. Damn, that is a good answer.

Good answer. Good answer. Good answer. Also, Ginger Bill, I did catch that CS Lewis quote in there. You know, all people choose hell one. You're welcome. in there. I thought, I was like, look at that guy. Hey, yeah. I love. Oh, God. I love that book, the books in general. But, uh, all right. I, I know, I, I technically don't have any more questions. I think, I do actually

have, I have so many questions in some sense, but I don't know if we should, uh, keep going or call today because we're actually, I have to go. Yeah, you have to go. I have to go. We'll come back. We'll let you guys back on again, and you can argue some more. Yeah. I mean, uh, talk. Yeah. It was very fun. Yeah, that was good. All right. Are you going to close the episode?

I'm going to close. I never closed the episode. I always forget. Hey, thanks for watching the stand-up with me today. Was T.J. was a Jose Valim, creator of Elixir and Ginger Bill creator of Odin. Soon to be Thor. You're about that. You're about to be a granddad.

Is that a thing? Can you be a granddad in languages? Maybe. Joe Armstrong, the creator of Erling, he considered, you know, he would say elixir, it's like his grandchild. He's a grandfather now. I mean, at this point, if that's also, I mean, Nicolas Xavier, the creator of Pascal and also worked on Al Gore and all a lot. So Algoal, pretty much the stemming of every single, like, that imperative language from now on. Yeah, at that point, he's not a grandfather.

He's like, great, great, great, great, great, great, great, great. He's Adam, right? Adam and Eve, yeah. He's the Patriot. Yeah, he's Adam. Now the question, who is Eve? Obviously, Fortran. She's a little older. I know on the next episode of the stand-down.

Yeah, there we go, Fortran. Now, that is, yeah, there we go, Fortran. All right. Thank you very much for watching this. This was another episode of the stand-up. I've never actually closed it. The stand-in-law. I don't know if you were going to say anything.

Oh, okay. Bye. Bye. on my screen Terminal coffee And hair