2 Language Creators vs 2 Idiots

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

• 0:01Speaker 00

  Oh, nice.

• 0:02Speaker 01

  Oh, hey.

• 0:03Speaker 00

  Oh, hey, I'm here.

• 0:04Speaker 02

  Hello.

• 0:05Speaker 01

  Wow, on time.

• 0:07Speaker 00

  I am on time today.

• 0:09Speaker 01

  That's incredible.

• 0:10Speaker 00

  It's, you know, there's a first time for everything.

• 0:13Speaker 01

  Welcome to the stand-up.

• 0:15Speaker 00

  So I haven't eaten anything all day yet.

• 0:19Speaker 01

  That's good. We got all time. We got, it's the stand-up. We can eat.

• 0:22Speaker 00

  No, you cannot.

• 0:23Speaker 02

  Hey, the last time I did stand-up, I used to eat like toast and stuff in the mornings. It was great.

• 0:28Speaker 00

  That sounds very British.

• 0:29Speaker 02

  Seven years ago.

• 0:30Speaker 01

  Yeah. We eat toast in America, too.

• 0:33Speaker 02

  No, no, no. Only we eat toast. Don't you know this? We invented the concept of toast.

• 0:38Speaker 00

  No, you didn't, TJ.

• 0:39Speaker 01

  And basted eggs.

• 0:40Speaker 02

  No, it's lies.

• 0:42Speaker 00

  TJ, TJ's just trying to fit in. Don't listen to him.

• 0:44Speaker 01

  True. Sorry. I've never had toast before. I just wanted to be part of something.

• 0:48Speaker 00

  Yep.

• 0:49Speaker 02

  Okay, it's okay. Don't worry.

• 0:56Speaker 00

  Uh, anyway, I'm sorry. All right. Today on the stand-up, we have with us, uh, 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? Uh, we are now, let's see, what is the topic again? Oh, yeah. Why didn't functional programming take off? And I, 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

• 1:40Speaker 00

  makes it feel like functional programming is quite successful.

• 1:45Speaker 00

  If that is true. But I guess.

• 1:47Speaker 01

  Is that implying it's not? I mean,

• 1:48Speaker 00

  Well, I mean, in the sense like the-

• 1:49Speaker 01

  He just won. Hey, he's in top three most loved languages, Ron.

• 1:52Speaker 00

  Yeah, that's true. Neil Vem's number one most, uh, loved editor. It doesn't mean it's popular.

• 1:58Speaker 01

  Well, it was popular though anyways, but that's fine.

• 2:00Speaker 00

  Sorry, I couldn't hear you over Ginger Bill typing. What is this, a stand-up Ginger Bill?

• 2:04Speaker 02

  Yes, it is. It's stand-up. I was just typing. Sorry, just a friend on Discord. That was all. Just tell him to go away.

• 2:11Speaker 02

  Hands, hands there.

• 2:13Speaker 03

  Teach, teach, teach, teach! I got a billion-dollar idea! I got a billion-dollar idea!

• 2:17Speaker 00

  I'm listening. What if we use state-of-the-art GPT wrappers to monitor live streams for API keys being leaked?

• 2:25Speaker 01

  Isn't that a little too niche?

• 2:26Speaker 00

  It's pronounced niche. And of course not according to my lived experience, it's very common to leak API keys. I just need you to set up a database that can handle my scale.

• 2:35Speaker 01

  Alright, alright. I'll use Neon so it 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.

• 2:44Speaker 00

  Oh, we'll need scale. Hey Teach, uh, you know that site we made about protecting API keys?

• 2:50Speaker 01

  Yeah, dude, you were totally right. We did need to have a database that could handle your scale.

• 2:55Speaker 00

  Um, people are using that to steal API keys.

• 2:58Speaker 01

  Wait, Prime, I didn't notice you were live.

• 3:02Speaker 00

  I'm not live. Yeah, yeah, yeah, yeah, yeah. A special deal only for today. For every bit you buy, I'll pay you back two bits.

• 3:11Speaker 01

  On the plus side, your database is still up.

• 3:14Speaker 00

  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?

• 3:32Speaker 04

  Alright, so I do have, uh, some opinions on this and, um, if you were like, well, so I, there are many thoughts. So one of the thoughts, so the first thing I'm going to say, like, if, if you were part of the functional programming community or kind of listening involved over the last, you know, um...

• 3:59Speaker 04

  decade or even more, very frequently you would hear that functional programming won. 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

• 4:40Speaker 04

  if we, 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 objected, 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, the, the word object orientation. And it's like, well, I, 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.

• 5:25Speaker 04

  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, so that's one of the, one of the things that I, I, I think about. Like, well, we, we, we got a lot from functional programming. But the other thing that I think about, so I was even mentioning to, to Ginger Bill, like just before we were chatting a little bit, getting to know each other, that I'm actually, I'm not sure, like the term functional programming, like saying Lixer is a functional programming language is that quite useful today? It's like, and, and there is like a technical discussion, a marketing discussion

• 6:08Speaker 04

  that we, that we can, can jump. Into it. But yeah, I think I think we 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 oriented.

• 6:50Speaker 04

  And so and that comeback should be like, well, maybe 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.

• 7:07Speaker 01

  I am, I'm interested to know, because I I agree with, I think a lot of, 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?

• 7:26Speaker 02

  Saying what ideas? What? Yeah, every every language has.

• 7:29Speaker 01

  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. That's a setup.

• 7:42Speaker 01

  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?

• 7:59Speaker 01

  Ginger Bill, Ginger Bill, you first.

• 8:02Speaker 02

  I have to first find define what I mean by functional programming, right? Great. That's a hard problem. So again, as I 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, 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 that that's the joke answer. But.

• 8:31Speaker 02

  The thing is, the functional thing is like, is it, does it mean declarative programming? That's like also oriented around like functions, as functions is a first-class thing. You can pass functions around all you like. And those functions also may have state associated, 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.

• 8:56Speaker 02

  Right? Because what is, what is, actually, what is a 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 effectively just, it's just, it's effectively a research project at the end of the day.

• 9:21Speaker 02

  It is mostly a pure, 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 taking state. And a lot of programs are fundamentally want to do that. And also Haskell is kind of a research project, so it 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.

• 9:53Speaker 02

  It's too complicated. So it's kind of, okay, what features do I think come 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.

• 10:13Speaker 02

  Right? But to pass it on to Jose again.

• 10:17Speaker 04

  Yeah, so you, before you said that Erlang is your favorite functional programming language.

• 10:24Speaker 02

  Yeah.

• 10:25Speaker 04

  So what do you like about Erlang? I think that's a good, and I'm asking it because I would love to see like, if the parts that you like, are they what people would classify as a functional part? Or, you know, yeah.

• 10:40Speaker 02

  There's another way of phrasing this. Erlang is also my favorite Oop language.

• 10:45Speaker 02

  Which is going to sound bizarre, but the reason why I'm saying that is Erlang has clearly got its its concurrency model is better described like CSP, right? You've got processes, CSP for people know is called Communication Sequential Processing. So you have processes, which is just think of as a generalized thread, green threads is another way of calling them. This is what Go routines are in Go, they're the same thing, right? At the end of the day, and then you communicate them by sending messages across them. So in Go, they have channels. In Erlang, you've got like the send and receive kind of operations. And the same with Elixir as well, don't you? You've got the send up the functions and then the receive blocks and such. And that kind of aspect there is very, and then everything's immutable by default as well.

• 11:30Speaker 02

  So when everything is passage, when you're 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, again, what Go does. The only problem is this, 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, ah, damn it, I can't have that luxury.

• 12:12Speaker 04

  Yeah, so to me, the beautiful thing about Erlang 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 handler meaner or 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 Erlang, they didn't start with that. They didn't say, look, we want, we want pattern matching, we want immutability.

• 12:55Speaker 04

  What they started was, well, we have to build a concurrent.

• 13:01Speaker 04

  Distributed reliable system. And then they realized that, well, if we have, if we have, so for concurrency, we need to have many things running at the same time. Processes, right? So you have all those processes, 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 realized 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 processes. So they were like, well,

• 13:46Speaker 04

  shared state in this case is going to get in the way of building a fault tolerant system because if you have a failure, you can no longer trust that shared state, right? So it's one of the things that keep going back like to discussions with the Erlang team. Like people are like, oh, we're trying to do like function. They're like, no, we wanted 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, 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

• 14:32Speaker 04

  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? That's because that's what attracted me, right? But, and then I ended up with Erlang, but you know, they did not add immutability to be functional. So I think those discussions are very interesting.

• 14:55Speaker 00

  So, 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?

• 15:07Speaker 04

  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, wow, 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.

• 15:51Speaker 04

  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 used to say, like, object orientation is like, you think you're holding a banana, but then you're 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.

• 16:36Speaker 04

  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 Rust 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, I should be happy with Rust and what Rust is offering, because it's offering those similar properties, but through a different mechanism.

• 17:14Speaker 01

  I wanted to ask actually about Rust because uh I know like a lot of like, Jose, you came from the Ruby community. And there was kinda, I feel like kind of a big, you know, uh, like parting of ways for some, 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. Uh, 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.

• 17:43Speaker 00

  I would love both. I love both of these things.

• 17:46Speaker 04

  Yeah, honestly, I don't have a lot of opinions, to be very honest.

• 17:51Speaker 01

  Nobody's listening. Nobody's listening. You can tell us the truth. You can tell us the truth here.

• 17:56Speaker 04

  No, I'm not, I'm not trying to, to, to, I just, I have very limited experience, don't follow it. So I think we can jump straight to the rant.

• 18:06Speaker 00

  Wait, hold on, before we do that, wh- why, why was the Ruby to Rust pipeline even a thing? Cause I've heard about this too, that a bunch of Rubyists went from Ruby to Rust. Like, why? Cause they don't strike me as super similar languages. Ruby seems fairly productive and

• 18:23Speaker 00

  Rust, 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, "Oh, 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.

• 18:42Speaker 02

  I would have just said the Ruby people just hated Python that much, that they went, "I'll try anything but Python."

• 18:47Speaker 00

  Oh, okay, that's reasonable.

• 18:50Speaker 02

  Yeah, that's my guess actually, right? Cause um, yeah, that's usually what I find out when people are big Ruby fans are going, "No, no, I hate Python so much," and vice versa, right?

• 18:59Speaker 00

  Oh, so it's not that they're Ruby fans, they're just anti-Python fans.

• 19:03Speaker 02

  Yes, I think that's the case, yeah.

• 19:05Speaker 04

  So, so, okay, so let me ask kind of, um... I don't know if this is true, and then you hear it, right? So I heard I heard that a lot of people went from Python to Go, for example.

• 19:19Speaker 00

  Yeah, I saw that.

• 19:19Speaker 04

  So why 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 than Ruby and Rust, and I think

• 19:33Speaker 00

  Yeah.

• 19:33Speaker 04

  most would agree with that. But but why would you think somebody who is programming in Python are like, OK, I'm going to do Go now?

• 19:40Speaker 00

  I I actually have a pretty good answer for that one. But Ginger, I I do want to hear yours first, just because you're much

• 19:45Speaker 02

  My answer is probably similar to yours. Mine was like Rob Pike was who and Rob Pike and Ken Thompson and Robert Griesmer, who all created Go, mostly Robert Griesmer's main person, not Rob Pike. But they all made it because they were making simple 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 on their servers, and they wanted something that was simple language and fast and compiled and type, statically typed as well, pretty much. And the 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 bitten the ass by using Java before. So they went, OK, Go is.

• 20:30Speaker 00

  Oh, actually, that's so my store is pretty similar. We went from a Python shop to a Go shop in 2012. And a huge and a huge amount of it was just because we're doing interning or string interning on on the server and Python just just stinks at, you know, 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 like you were you're going from gay Python to gay Go. And like, that was the 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 you could transfer all straight across with just Go.

• 21:15Speaker 00

  And you could go from Python to Go. And it was like, it was actually super amazing.

• 21:21Speaker 00

  I also said interning, which is not the correct term. In my brain, I'm just thinking interns. But that is not the uh.

• 21:27Speaker 02

  What string interning? I think like you just don't make any multiple copies of the string. So you can then just keep bringing them back.

• 21:32Speaker 00

  No, no, no. I I meant kerning in my head. I said interning and string kerning.

• 21:37Speaker 01

  He was so excited to make the second joke that he literally lost track.

• 21:43Speaker 00

  I fumbled the bag for the gay Python. I just always want to say that. I have had no reason to say Google App Engine in the last 10 years. Okay.

• 21:51Speaker 02

  I even forgot that even existed until you wrote it.

• 21:53Speaker 00

  Yes. And so Google, that's to me, that's actually where a lot of these 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.

• 22:07Speaker 02

  And also Go had a brilliant, again, at the time, a brilliant, just like web server built in straight away. Done. And it just worked and it just worked. And scaled well as well. It was like much best, better than Python. So everything like, oh, Python pickers. Oh, we just have to learn about bit static typing and then off you 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 C and C plus programmers. I'm surprised that they thought that was surprising, I mean.

• 22:38Speaker 04

  Yeah. So I I would say, going back to the original question, I would say, I would, I would imagine that a lot of that was like the the Ruby, what 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 I think community also plays like a big factor. You can see like the the Ruby community was always like very grassroots, like one of my favorite events. In general, programming language events is like Urco, where the way it works is that every year

• 23:21Speaker 04

  they present, the conference happens in a different European city.

• 23:26Speaker 04

  And then at that event, people, and most often people who have not, 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-minute 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, they, they would, they would, you know, just try something else.

• 24:11Speaker 04

  And, and, 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 Erlang and Elixir one. And, and it's kind of hard for me to assess what is the, the, what is the Elixir community? Because I play an important role in there, so I don't know if I can do that job, right? But for Ruby, it, 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 to, that can be a negative, right?

• 24:56Speaker 04

  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 going to Elixir, going to Rust, 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.

• 25:33Speaker 00

  We're still missing that ginger bill rant about Rust. Do you have anything you want to say?

• 25:37Speaker 02

  Was just gonna say that. I'm like, you're not getting out of this. What am I ranting about again? Exactly about Rust? Anything.

• 25:43Speaker 00

  Anything you want to say.

• 25:45Speaker 02

  It's the stand up, bro. I don't have to, you know what? I'm gonna be polite to Rust programmers. I'm trying my best not to be too insulting.

• 25:54Speaker 02

  But if we go talk about the topic, try and keep it on topic, right? I would actually say Rust is an ML in disguise pretending to be a C++, right? True. Because if you look at it, how its semantics works, you've got all, again, not ignoring like the ownership semantics and lifetime semantics, getting the ownership semantics bean. And I find some sort of cruel type system, right? There's the nerdy shit, just to get out there, apologize for my language. And, um, but it's got all that. And many semantics are like, oh, 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++. And in many ways, Rust, as you know, the creation of Rust is because of the people

• 26:32Speaker 02

  who are using like modern C++ one 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.

• 26:53Speaker 02

  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++ what like when C++ 11 was coming out and just before that as well. And I went through that entire phase. Oh.

• 27:06Speaker 00

  Can we, can I just interrupt you? Is, is it even fair to call C++ 11 modern C++?

• 27:12Speaker 02

  No, that was modern C++ compared to before, right?

• 27:16Speaker 00

  Okay, okay.

• 27:18Speaker 02

  Right. Because you've got to remember, C++ before that, they had the next time was like C++ 03 and stuff like that. And.

• 27:26Speaker 02

  C++ 11 was like the big change at the time, right? It was showing all the brand new features. They had all the ownership semantics, the better template improvements, the S4 improvements, the new like smart pointers, the all these new features which made it modern, if you know what I mean, right? Quote, quote, modern. So in that sense, that's what I would, again, saying C++ 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 Rust is 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.

• 28:07Speaker 02

  It just wasn't, I wasn't getting stuff done, is the best way of putting it.

• 28:12Speaker 00

  So you're saying there's a lot of ceremony in the Rust, in the Rust world?

• 28:15Speaker 02

  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.

• 28:24Speaker 00

  Yep, I love that.

• 28:27Speaker 02

  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 generator 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, has anyone's 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.

• 29:11Speaker 02

  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, 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.

• 29:40Speaker 00

  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 Rust questions.

• 29:58Speaker 04

  No, 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 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?

• 30:37Speaker 04

  Like, when you're thinking about macros, are you like, do you think there can be good macros? You are, there's that same, right?

• 30:49Speaker 02

  Not necessarily against macros per se.

• 30:51Speaker 04

  Is there implementation of macros? Like, yeah.

• 30:55Speaker 02

  I'm just saying, if you have a macro system, you shouldn't do Rust. It's not the way Rust should do it. I know Elixir's got it, especially if you've got the ST modification stuff, which again, which is in Erlang, 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 macro system, the preprocessor. If you didn't have that, C, I don't think C would be used anymore.

• 31:40Speaker 02

  Like, it's there because it gets around the deficiencies of language. It gets me to bodges, makes you fix things that are missing and all this lot.

• 31:49Speaker 02

  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. If it makes any sense.

• 31:56Speaker 04

  I love that. And the reason why I love that. So, one, there's 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, 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 special definitions, like, you know, a bunch of keywords. So I was like, well, instead of hard cloning all those things as part of my compiler, I want to come up with these smaller subset of syntax and compiler code

• 32:42Speaker 04

  and have that as my foundation. So macros are there. So in Elixir, we have very few keywords, like def module, def. 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.

• 33:03Speaker 02

  Say it, tell it to his face. Come on, I want it.

• 33:07Speaker 04

  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?

• 33:23Speaker 02

  There is also the other aspect, right? And this is the issue with like a lot of meta programming in general, is how do I debug those macros?

• 33:33Speaker 00

  Macro compile time print statements. Next question.

• 33:37Speaker 02

  Yes, so tracing, I don't, 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 OST and do all this, do all the magical stuff, similar to what like Jonathan Blow was doing with his language. And then as I came, well, 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 typed, I 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.

• 34:09Speaker 02

  And the answer is, oh yeah, that's gonna be difficult.

• 34:15Speaker 02

  Because this is actually the hot, this is really the biggest issue. A lot of people love all this fancy compile time 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 meta program 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 meta programming tools usually are. And then they usually have to rely on caching, if they've got caching and all this. And it's just, it's, I find it funny because a lot of people saying, you just brought the printf debugging thing as a joke. But I think a lot of people just only do printf debugging. Like, that's all they do. They don't even know that you can open up like a debugger, like, again, Rad debugger is a brand new one.

• 35:00Speaker 02

  You can add that or Remedy, BG or Visual Studio or any of these visual ones. I hate just GDB so much, but.

• 35:09Speaker 04

  I am a printf debugger and I'm happy, I'm proud.

• 35:12Speaker 02

  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 evolving. I understand the printf, like I do tracing as well, right? Tracing is useful when you're when you're working on 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.

• 35:42Speaker 04

  Yeah.

• 35:43Speaker 02

  And that's, there you go, there's my little rant.

• 35:46Speaker 04

  Yes. Yeah, so the thing about like macro execution and how you're going to debug macros. And and that's going to be different per programming language.

• 35:59Speaker 04

  Maybe we can talk later about zig comp time. I don't know if you have thoughts.

• 36:03Speaker 02

  My criticism applied the same as that, it's the same problem.

• 36:06Speaker 04

  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.

• 36:21Speaker 02

  Yes.

• 36:21Speaker 04

  And so there is no distinction, so.

• 36:26Speaker 02

  Yeah, and that's the benefit, what my complaint is made with compiled static languages rather than

• 36:32Speaker 04

  Yes.

• 36:33Speaker 02

  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 you see, again, the beam is effectively being jitted 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

• 37:04Speaker 02

  the very, very basics, if you know what I mean, the basic type checking before it goes run.

• 37:08Speaker 04

  Yep.

• 37:10Speaker 02

  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 they're designing languages, forget. And it's like, do you not actually work on projects where you have to be in a debugger or do you 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, 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.

• 37:54Speaker 00

  All right, hold on, Jose, I have to ask this question because I don't know how much all the macros throughout Elixir slow down compile time. But if you were to go back today, would you, would you put, say, the if statement in def 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?

• 38:16Speaker 04

  So...

• 38:17Speaker 00

  Unlimited time, you could, unlimited time?

• 38:20Speaker 04

  No, I wouldn't, that part I wouldn't change. So there are a lot of things that, so there are a lot of criticisms 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...

• 38:37Speaker 00

  It kind of feels that way.

• 38:38Speaker 04

  Right, yeah, but like, I was like, that's, I'm like, that's objectively a lie. Like, I, I can't... Yeah, prime.

• 38:46Speaker 00

  Yeah.

• 38:47Speaker 04

  Yeah, prime, dumb liar, liar! Like, give, 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 thing though 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, 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, right, but, wait, what was the question again?

• 39:25Speaker 00

  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?

• 39:34Speaker 04

  So, so they are, yes, so I would, I would not. I would, 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, 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.

• 40:19Speaker 04

  That that's it, right? And I do my best to not cheat, right? I should not be doing that. And and it's such an essential part of the language that I think like if you remove that, it's no longer Elixir, it's going to be something, something else. But on the point of macros, I don't think there is low compile time.

• 40:41Speaker 04

  I think the issue and and so, okay, so so when I decided 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 meta programmings that other programming languages have because I said, look, I'm having macros.

• 41:22Speaker 04

  I'm saying no to all this stuff in order to keep the the language simple, right? And again, like the no cheating rule also means that because I could say no cheating and then I could blow up the language and add a thousand different things because I'm like, okay, right? So all those things, they act as balance and um, yeah, and I wouldn't change it. But one thing that is very interesting, there there are two topics that I want, I I 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 a type system for Elixir.

• 42:07Speaker 04

  And it happens that the type system throws a huge wrench at the the no.

• 42:15Speaker 04

  Cheating rule, exactly because what Bill said like, so if you think like 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

• 42:58Speaker 04

  I think it goes back to what Bill was saying. Well, if you're designing a programming language and you want to do printf, the type system doesn't know how to deal with that, right? So which side, which trade off are you going to make? And that's ultimately like the thing, like you have to make all those decisions, all those trade offs, right? And make sure that at the end of the day, you don't have like the Frankenstein monster coming out of it, right?

• 43:22Speaker 02

  Yeah, but to explain like the printf one, I probably skipped over that too much. But like when I made Odin, the, one of the first things I kind of wanted to add into language was runtime type introspection. Um, now many people may say this, what this means is at runtime, you can actually say, hey, this is, 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 the properties of the field as a struct. 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're doing a compile time language, right? Where it will generate a new print procedure, print function every

• 44:05Speaker 02

  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, um, and how do I explain this? The Rust one sounds great because it's like, oh, you only make the code for the, you only generate the code for the code you actually need to print for, for those types. Great. Yeah, that's combinatorial explosion. That's like N factorial it can be as bad as because you've got all these different things and then your executable size gets worse, your compile times get worse and it's like you've gone screwed up. Well, the runtime type information approach, like what Jordan does is 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

• 44:46Speaker 02

  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 code 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 or the languages that do this kind of like compile time based printing things have that will hit and they will hit this problem of combinatorial explosion very, very quickly. And it's going to be, this is why you got trade offs when you have to think about it because you have to understand which trade offs you take when you're doing design. So that's kind of something like when you do a print thing because there's multiple options you could do the generic ways, which is like runtime or compile time generation, or you could just have, hey, we have built into the

• 45:29Speaker 02

  language. Like for instance, anyone who's used Go, they have a bootstrapping built in procedure called print line, like lowercase or print line. 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 thumped package for everything.

• 45:50Speaker 04

  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 explosions in your face, like all the combinatorials.

• 46:07Speaker 02

  Yeah.

• 46:10Speaker 00

  So I didn't realize that Rust creates a separate function, kind of like some sort of templating style function for every single print statement you do.

• 46:18Speaker 02

  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.

• 46:37Speaker 00

  And also, Jose, just to, when you say cheating, is this cheating in the same way like make is cheating in Go? Where it actually is generic when we don't have access to that level of generics in Go for a long time? Where like they have, they get the special one, but you don't get the special one?

• 46:53Speaker 04

  Yes, every time there is a language feature where we're 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, I want to minimize. And Elixir allows us to minimize this considerably because we are bootstrapping ourselves on top of the Erlang virtual machine and the 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, tuples, that come from Erlang.

• 47:34Speaker 04

  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, there are very few. There are very few, and everything is built on top of that.

• 47:53Speaker 01

  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 gotta 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 Lua's like, "No, we're just gonna 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. But 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.

• 48:37Speaker 01

  In Lua, there's like, not a lot of cheating from the language either, right? Like, it kind of does the same thing there.

• 48:44Speaker 02

  Yeah, I feel like Odin is cheating a lot then if you're using this definition.

• 48:49Speaker 01

  Tell us more.

• 48:50Speaker 02

  I don't class it as cheating. This is the thing.

• 48:53Speaker 01

  Oh, it's fine when you do it. I see how.

• 48:56Speaker 02

  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. It's obviously that therefore it's not cheating.

• 49:03Speaker 01

  Oh, house rules. Oh, gingerbells play.

• 49:06Speaker 00

  All right. So, okay, so why is it not cheating? Or let me rephrase the question. Why is it good for a language author to have constructs only they control? And not allowing users to use it, but not control it or create them themselves?

• 49:25Speaker 02

  So I'm going to phrase it slightly differently and then answer your question if that makes any sense.

• 49:30Speaker 02

  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 types of 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 think. 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++ operator overloading. Well, most of the cases of operator overloading that they use are to create all of those things I've just listed.

• 50:14Speaker 02

  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.

• 50:33Speaker 02

  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's cheating. But here's the thing, Odin doesn't have macros. You can't even produce even further. You can'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 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.

• 51:13Speaker 04

  I agree, I agree with that. I think that's exactly the trade-off. And I think going back, I think like everything cheats and they don't cheat to a certain extent. It's like what the language chooses as an extensibility mechanism, like operator overloading. Are you going to have those things? 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.

• 51:57Speaker 04

  That's when you know, that's, that's where the friction appears and that's when people feel frustrated. But if the things, you can do a lot of cheating, right? Like according to my definition.

• 52:08Speaker 02

  Yeah.

• 52:08Speaker 04

  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, they're going to be happy, right? Even fold like, you know, 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, I'm expanding, I am contributing, I am extending the thing that I use every day.

• 52:44Speaker 02

  Yeah, it's just, just for me, I've been seeing so much abuse of like operator loading, 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. Let alone others. Like, seriously. I've seen people who have overloaded insane stuff and then other languages now have custom operators. Yes, I'm looking at you, Swift. And, oh my god, it's actual, it's hell. And you're 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.

• 53:29Speaker 02

  Rather than having that percent sign that tells you, actually, this is doing the fancy baking the shinkof. I'm like, of course, it's so obvious. No, no, it wasn't.

• 53:39Speaker 02

  I have actually seen some really horrific operator overloading and yeah, that's why I just know. No. So that's why I implemented the things that people 99% of use cases, even probably not higher than 9% and just added them. And then most people are now happy.

• 53:51Speaker 04

  Yeah, those are two things.

• 53:52Speaker 02

  Set, but.

• 53:54Speaker 04

  Yeah. Operator overloading, custom operator, those are two things that we like, we strongly agree with. I'm like, yeah, like if you feel need those, there is probably something wrong somewhere, right?

• 54:07Speaker 01

  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.

• 54:17Speaker 01

  Ginger Bill, you're stealing my job, dude.

• 54:20Speaker 02

  Say that job security until someone tells your manager they've done that and they go, oh shit, we need to get rid of this guy now, quick.

• 54:25Speaker 01

  It's too late by then. It's too late.

• 54:29Speaker 02

  We're gonna have to slowly, it's like gone, the time just, what is it? The garden time is gonna be a very long time.

• 54:36Speaker 00

  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?

• 54:51Speaker 02

  Has.

• 54:52Speaker 00

  Do you think that you do?

• 54:53Speaker 02

  No, no, no. I think it did it pretty much years ago.

• 54:56Speaker 00

  Ooh, really?

• 54:57Speaker 02

  Yeah. Yeah.

• 54:59Speaker 00

  Do you think that's a downfall in the language? Or do you think that it's a good sign?

• 55:04Speaker 02

  No, it's a downfall from the start. But again, as I said, I hated C++ and Rust is kind of the next step in that thing. And it already does all that. Like, there's also these other aspects where I'd be very careful what I mean by this statement.

• 55:21Speaker 00

  You don't have to be careful. It's just the four of us.

• 55:23Speaker 02

  No, no, no, no, no. 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 LSPs? 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 whatever, right? This is the internet for you, right? 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 proven, obviously. And then just had them in a very small C-like 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.

• 56:05Speaker 02

  But they didn't. They started effectively in the middle and went, right, we're gonna do all this. We need all of the trait system. We need all of the macros. Like, they just started there and then went, 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 is for many people, but like, that's the thing is a lot of language design, a lot of languages aren't that ergonomic. Elixir is quite ergonomic, actually. That's one thing I'll praise about it. But it's like Rust isn't. Rust is also fighting things, and I'm not saying the borrow checker I'm fighting. I'm usually fighting the lifetime system.

• 56:37Speaker 00

  Correct.

• 56:39Speaker 02

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

• 57:08Speaker 00

  I get it. Sometimes you just want, like, I want this thing to live for a function. It's gonna live for a function. It's gonna, I'm gonna hit some async's in here. It's just, it's here for this function. That's all I want. Stop being annoying. I'm gonna pass it around. It's alive for this much. That's it. That's it, people.

• 57:22Speaker 02

  I want to specify that, and then doing that is hard.

• 57:25Speaker 00

  Yes.

• 57:26Speaker 01

  Yeah. You're saying, though, you don't want the value to define a lifetime. You want to define the lifetime of value, Gingerbill.

• 57:34Speaker 02

  Correct, indeed.

• 57:37Speaker 00

  Put that one on a t-shirt.

• 57:39Speaker 02

  I'm not God, okay? I'm not God.

• 57:42Speaker 01

  Okay, I have, I've got a quick question. Gingerbill, since you're well-known for hating LSPs. And, 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.

• 58:05Speaker 00

  DJ, how long have you been sitting on that one?

• 58:07Speaker 01

  I wrote that one before we got here, boys. And when Ginger Bill mentioned LSP, I was like, it's my top shot! I love it, love it! I could not wait for that. You love him so much, there's three.

• 58:21Speaker 00

  That better be a short.

• 58:22Speaker 02

  One unofficial one at the moment.

• 58:26Speaker 02

  Actually, I think Tenafeld is gonna get, there's two unofficial ones in Odin as well. Like, there's an Intelij 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.

• 58:38Speaker 01

  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?

• 58:43Speaker 02

  I actually have a main job to deal with at Jangor Effects. So yeah.

• 58:49Speaker 00

  Alright, if, if, 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 gonna be. We don't do that here.

• 59:17Speaker 02

  Depends on the ma, the price, and I'm not even joking. I'm not saying I'm being bought, I'm just saying it's more of a, like, okay, if you're gonna do this, what I would have to do for Odin is I'm gonna, I'm gonna rewrite the, the actual compiler, completely. So then it's going to be built up from the ground up, so 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. I should have, 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, shoots 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.

• 1:00:00Speaker 02

  But that's the thing. So if I was gonna 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

• 1:00:23Speaker 00

  Very cute.

• 1:00:24Speaker 02

  And he wants to work on that. And I'm like, sure, but he doesn't have any time because of course he works with Jangor FX as well. So we have, it's called lack of time.

• 1:00:35Speaker 02

  So that's half the problem.

• 1:00:37Speaker 04

  Yeah, people bring up like LSPs, right? It's like, oh, why can't you have a good LSP, right? And then they, and they would usually, yeah, they would usually mention like TypeScript or something from Microsoft. And they're like, oh, you like, why can't you have it? They're 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 mean is like, it's actually a complex problem. Right? And

• 1:01:12Speaker 01

  I love that they picked TypeScript, the one that like, everyone has to restart constantly, doesn't scale the big projects. It's terrible.

• 1:01:20Speaker 00

  Categorically the worst known LSP, also the inventor of the LSP.

• 1:01:25Speaker 02

  Yeah, this is also the other thing about LSPs. Like, this is actually like implementation detail I just dislike about them. They were designed by Microsoft, obviously, and it's a protocol over JSON. It was JSON or PC or whatever it is. I can't remember the exact thing is, but they're sending a JSON packet to send all this information. And they've got a borderline like saying, hey, this is, 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.

• 1:01:50Speaker 02

  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 tested on. And it's like, great, great.

• 1:01:59Speaker 04

  Or if you don't use Unicode 16, which is definitely the most popular encoding.

• 1:02:04Speaker 02

  Oh, it is, it is the best. UTF-16 is the best because of course, Microsoft have been using it for the past 30 years.

• 1:02:10Speaker 00

  Whoa, hold on.

• 1:02:11Speaker 02

  If not a little bit longer.

• 1:02:12Speaker 00

  Hey, JavaScript was originally all UTF-16, okay, buddy?

• 1:02:17Speaker 02

  So is Python.

• 1:02:18Speaker 01

  That's why.

• 1:02:19Speaker 02

  Still UTF-16.

• 1:02:20Speaker 01

  Yeah.

• 1:02:21Speaker 00

  Yeah, someone's like, we need LSP for JavaScript. What is JavaScript written in? UTF-16, let's go, boys.

• 1:02:26Speaker 02

  The reason why UTF-16 is used is because 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 gonna explain Unicode.

• 1:02:44Speaker 01

  Okay, but here, Ginger Bill, I got a question.

• 1:02:49Speaker 01

  Like, 16 is bigger than 8.

• 1:02:51Speaker 00

  Yeah, explain that one, Ginger Bill.

• 1:02:54Speaker 01

  Checkmate, Ginger Bill.

• 1:02:55Speaker 02

  I know, that's me, man, it's bigger.

• 1:02:57Speaker 01

  Unicode version 8 or Unicode version 16?

• 1:03:00Speaker 02

  32, what about 32, man?

• 1:03:01Speaker 00

  Yeah, we should be using that.

• 1:03:04Speaker 00

  You know what? Registered Align Unicode. We should get Unicode 64. And just start reading them like that. That would be the true superiority.

• 1:03:13Speaker 01

  UTF-64. Microsoft, we're, we're ready for it.

• 1:03:17Speaker 02

  UTF-64 is 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? Like, 522 is the biggest register we have on some machines now, right?

• 1:03:29Speaker 00

  Okay, well, that's a little great.

• 1:03:31Speaker 02

  Think how many emoji we can have.

• 1:03:32Speaker 01

  That's what I was just gonna say, there's so many emojis left in the world.

• 1:03:36Speaker 02

  You don't have to have all of the different things, like the Fitzpatrick Color modifiers and the Family modifiers and all that. You could just have one giant emoji.

• 1:03:43Speaker 01

  You have them all. I think we solved it.

• 1:03:45Speaker 00

  We did.

• 1:03:46Speaker 01

  You're welcome, Microsoft.

• 1:03:47Speaker 02

  Yeah, see?

• 1:03:48Speaker 00

  I'll send my bill.

• 1:03:51Speaker 01

  We're gonna be charging you one Microsoft salary for that.

• 1:03:54Speaker 02

  Oh, I'd like that, thank you.

• 1:03:56Speaker 01

  Yeah, no problem.

• 1:03:56Speaker 00

  It would have to be a distinguished engineer, because only a distinguished engineer could come up with a, with a plan this good.

• 1:04:03Speaker 01

  Oh, yeah.

• 1:04:05Speaker 00

  All right, Bill, I'm glad that I, I'm glad to hear that you also have feelings about Unicode. I'm glad to just see that spark, the spark happiness within you.

• 1:04:15Speaker 01

  Speaking of feelings that you have, Ginger Bill, let's talk package managers.

• 1:04:19Speaker 02

  Yes, okay, okay, okay.

• 1:04:21Speaker 01

  This is my last question that I had prepared, so we can, we can end after this.

• 1:04:25Speaker 02

  That's fine, that's fine, absolutely fine. I don't know if Jose is gonna hate me or not for this.

• 1:04:30Speaker 01

  Well, I figured if it goes bad, well, I just cut this from the end of the episode, and then we...

• 1:04:34Speaker 02

  That's fine.

• 1:04:35Speaker 00

  No, no, no, we turned it into a clip, and we put it on the clips channel.

• 1:04:38Speaker 01

  There we go.

• 1:04:39Speaker 02

  And I'd be really pissed, voice looking into the camera, going...

• 1:04:42Speaker 01

  Yeah.

• 1:04:43Speaker 02

  Yeah, whatever, yeah. You won't believe what Ginger Bill said about package manager.

• 1:04:50Speaker 04

  Even worse than LSPs.

• 1:04:53Speaker 02

  No, I actually think LSPs are fine. I actually hate, I think, how do I put this? I'm gonna use real words and languages, straight to the camera. Package managers are evil.

• 1:05:03Speaker 00

  Oh, that's so crazy. Let's hear more. That's why it's called Hex!

• 1:05:10Speaker 02

  I mean, I didn't put two to and together, but yeah.

• 1:05:15Speaker 01

  I think we discovered something big, chat.

• 1:05:20Speaker 01

  Alright, Ginger Bill, tell us a little more. I want to hear you and Jose talk about it.

• 1:05:25Speaker 02

  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, I need to make a distinction of 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? Okay, there's nothing at search engine. I use DuckDuckGo every day. And Google and many other search engines, because they're all pretty bad now, so I have to keep swapping between them all.

• 1:06:06Speaker 02

  The other aspect is, I don't, build systems, that's usually, again, that's language dependent, if we're talking about languages here, obviously. So, in Odin, I try and minimize the need for a build system entirely, like Odin build dot will compile even the most complicated stuff for Jangrafex. 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, it doesn't get linked against, and so on 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 its dependencies, and you can probably see where my criticism's going.

• 1:06:50Speaker 02

  This is automation of dependency hell.

• 1:06:55Speaker 02

  And the problem is, is I've said this before, I've 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 have been on a large project before, they'll, they'll be, been in before, right? You've got literal thousands, or 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 you getting into hell. You can put yourself into hell. That's really easy. Most people, actually, everyone puts themselves into hell. That's, you do that voluntarily.

• 1:07:38Speaker 02

  But the thing is, it's more to do with how quickly you can get there and also makes you have to think. Like, if you download it manually, you start thinking, maybe I don't want this, or maybe I actually can do this, 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 for that problem. And this is why if you look MPM, it's awful. The other problem is also package 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. MPM is the best, a good example of this, because also there's multiple other package managers for Node that I can never remember, because that now means you have to have a package manager manager.

• 1:08:21Speaker 00

  That's apt. Apes.

• 1:08:24Speaker 02

  Yeah.

• 1:08:25Speaker 00

  Paru are the package managers.

• 1:08:26Speaker 02

  This is where things get like, because you haven't got a well-defined concept of what a package is 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.

• 1:08:45Speaker 02

  Yeah. And this is why, this is why I'm saying it's evil in the sense that it will send you to hell quicker.

• 1:08:50Speaker 00

  Okay, 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.

• 1:09:11Speaker 02

  Yeah, so Go has a really good core library, standard library, right? That's, it has the batteries included, like, that's what I tried to do with Odin. Like, when you download it, 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, like, 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.

• 1:09:36Speaker 02

  Like, I wrote an LSP, yeah, you just write it from scratch. Compiler, yeah. So the Go standard library has a Go compiler in it, in fact, it has two Go compilers.

• 1:09:44Speaker 00

  Hmm, backup.

• 1:09:46Speaker 02

  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 a sense, it is kind of a backup, it's just like once the cling on. Oh, God, that's a, that's a so nerdy joke, man.

• 1:09:58Speaker 00

  Thank you.

• 1:09:59Speaker 02

  And it's so bad that I know that joke.

• 1:10:03Speaker 00

  All right, sorry, Jose, your bit.

• 1:10:06Speaker 02

  I want to hear, I want to hear the response. I'm talking about physiognomy here, physiology? I can't remember that one, is that one?

• 1:10:11Speaker 04

  No, I, no, I, that's pretty good. I, I, I, 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 know, you are responsible, right? If that thing... Do something wrong, like you may potentially end up in jail. Like it's 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?

• 1:10:54Speaker 04

  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 what 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 um, if you if yeah, I I I agree. Like you have to, if you're going to have like a 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.

• 1:11:29Speaker 04

  So when I'm starting a project, I'm not automatically bringing 1,000 potential like attacks into my into my app. Or, uh, 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?

• 1:11:52Speaker 02

  It it's not even security things like that's people say keep always bring up security like a security risk. I'm like, they're not even the biggest worries. Like at work, we use SDL2 for our window handling and input stuff. And the amount of bugs that we have found, and it we absolutely hate it to the point where we're actually, I am 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 trivially fix it. And we're not relying on an extra dependency, right? I know many people, but STL is great. It's used by millions of different things. I'm like, yeah, but we keep hitting all of the bugs.

• 1:12:24Speaker 02

  But it's great. Yeah.

• 1:12:27Speaker 04

  It's great, though.

• 1:12:29Speaker 02

  It's great, though. And it's like STL3 might fix it all, but it's like, great. But the time to integrate STL3, 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 allocate everything but written from scratch. I wish there were just libraries that just worked. But it's still, I have to depend on them. And they're a liability and like not necessarily security liability, it's just bug liability.

• 1:12:52Speaker 04

  Yeah, liability.

• 1:12:54Speaker 02

  So liability.

• 1:12:59Speaker 01

  OTP helps a lot in Elixir, just like there's a lot of things that come with the airline, like runtime and everything that like that creates more of a culture like I, I mean, when I'm doing Elixir stuff, I'm using Phoenix a lot. So like, and then 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 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. I'm not sure why.

• 1:13:40Speaker 04

  Yeah, I think, I mean, I think part of it is exactly like, I know I have this opinion, the Elixir core 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

• 1:14:21Speaker 04

  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, right? And then if the thing is good, you, 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, 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

• 1:15:05Speaker 04

  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.

• 1:15:21Speaker 02

  Yeah, if that's assuming you've got source code, otherwise you have to reverse engineer it. And I've done that a few times. But yeah, that is the problem. But yeah, 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. It's a very, programmers are very high trusting.

• 1:15:45Speaker 00

  Yeah.

• 1:15:46Speaker 02

  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 then replying that to the rest of their world and stuff like that, and it hopefully works. And I'm like, it's all 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 you say malicious, they could just make a funny bug, where if you click one pixel on the screen, it just now has Rick rolling you. But it could be.

• 1:16:21Speaker 01

  Next elixir release.

• 1:16:23Speaker 02

  Next elixir.

• 1:16:24Speaker 00

  Think about it.

• 1:16:26Speaker 02

  I know, I like that. Think about it.

• 1:16:28Speaker 00

  But no, I would actually argue, so I'm gonna, I'm gonna put it as a separate argument for why I think that it, why I think that exists. I think we've had a couple of things. One, we've had an 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 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, uh, Jelman'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

• 1:17:12Speaker 00

  you're like, man, they got everything wrong about JavaScript. You go to the next page, it's about something else, and you're like, man, I know a lot about beetles. 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. Here, let me download this library off the internet. This is gonna 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 gonna trust every open source package I've ever downloaded. And so there's like, definitely like a Gelman 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, right? It's just a thing.

• 1:17:56Speaker 02

  It's because they're assuming programming is like any other industry, like engineering that's been around for thousands of years. Or science, which in modern comparence has been around, what, for 500 years? Again, like Gelman Murray explaining there, he was a particle physicist, right? He is the guy who came up with, and then came up with quarks. These subatomic particles that make up like protons and neutrons and such. And the guy who came up with this name- You don't have to make stuff up to make your point, Ginger Bill.

• 1:18:21Speaker 00

  Ginger Bill, stop trying to sound smart, okay?

• 1:18:24Speaker 02

  Yeah, okay, come on. Stick to programming, stay in your lane, buddy. Even more fancy, because I know where the story comes from. I know.

• 1:18:29Speaker 04

  You meant quarks? Those crystals?

• 1:18:32Speaker 02

  Quarks? No, no. Quarks, the crystals. Of course, yes.

• 1:18:36Speaker 01

  Okay, now crystals have power, Ginger Bill. Okay.

• 1:18:40Speaker 02

  Quarks said they had power. It must be true, okay? Look, he was a smart dude. He was also a wrestler, so you wouldn't want to mess with him, so. But no, yeah, but this kind of thing is like, this is a, it was Michael Crichton did it, you know, the guy who made like Westworld 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, oh, this is bad, and then they all believe everything else. And it's like, yeah, you do, because you trust people you believe. Because I know this is my, like, this, go back to my old one to C++ 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.

• 1:19:23Speaker 02

  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 as you go, this will benefit me as I go along. Because I was just kind of trusting this, what I perceived 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, very, very little wisdom, I would put. And that we're in so early days, and it makes sense, because as I've gotten older, I've gotten more knowledgeable about certain things, and 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, it hasn't evolved quick enough. We'll find out in probably a few hundred years, and I mean hundreds.

• 1:20:07Speaker 02

  We'll find out where the, 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.

• 1:20:28Speaker 02

  And their projects, but that's,

• 1:20:32Speaker 02

  that's about it. Does that make sense?

• 1:20:36Speaker 01

  I got one last question to end.

• 1:20:38Speaker 00

  I can't believe you didn't say this. Ginger Bill. Books, you shouldn't read books. That's what he just said.

• 1:20:44Speaker 01

  Books are for stupid people. Well-known LSP and book hater. Ginger Bill.

• 1:20:51Speaker 02

  Books. What, what are those things? I don't know. Just don't kill a tree. Don't read books. You're killing trees, man.

• 1:20:58Speaker 01

  Hmm. You hate the environment. Smart.

• 1:21:00Speaker 04

  I always quote the Simpsons meme, "I'm here to lead, not to read."

• 1:21:05Speaker 01

  That's a great one. That's a classic. Okay, my last question. Short, short answer. Think you gotta 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? And you can't say don't, Ginger Bill, because I know that's the first thought. I wasn't saying that. I was never gonna say that.

• 1:21:26Speaker 00

  Jose actually beat you to it. He was already like, "Don't, don't do it."

• 1:21:29Speaker 01

  All right, one sentence. Ginger Bill, and then Jose.

• 1:21:34Speaker 02

  Learn the basics of how to do tokenization, parsing, and when you're doing parsing, you only want recursive descent and Pratt passing, pretty much. And then you start learning type stuff. Start with a very, and, and.

• 1:21:45Speaker 01

  And.

• 1:21:46Speaker 02

  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.

• 1:22:01Speaker 01

  Okay, so you said tokenization. So start with a crypto coin. Got it. Jose, you're up.

• 1:22:06Speaker 04

  Listen to Bill.

• 1:22:08Speaker 01

  Great answer.

• 1:22:09Speaker 00

  Damn, that is a good answer.

• 1:22:11Speaker 01

  Good answer. Good answer. Good answer.

• 1:22:14Speaker 00

  Also, Ginger Bill, I did catch that C.S. Lewis quote in there. You know, people choose hell one in there. I thought, I was like, look at that guy.

• 1:22:21Speaker 02

  Hey, I love, I love, oh god, I love that book, the books in general, uh, but yeah.

• 1:22:29Speaker 00

  Alright, I technically don't have any more questions. I think, I do actually, I have so many questions in some sense, but I don't know if we should, uh, keep going or call it a day, because we're actually 30 minutes over. Yeah, you have to go.

• 1:22:40Speaker 01

  I have to go. We'll come back, we'll invite you guys back on again, and you can argue some more.

• 1:22:45Speaker 00

  Yeah.

• 1:22:45Speaker 01

  I mean, uh, talk.

• 1:22:47Speaker 04

  Yeah.

• 1:22:49Speaker 01

  That was very fun.

• 1:22:51Speaker 00

  Yeah, that was good.

• 1:22:54Speaker 01

  Alright. Are you gonna close the episode?

• 1:22:55Speaker 00

  I'm gonna, yeah, I never close the episode, I always forget. Hey, thanks for watching. The stand-up with me today was TJ, was a Jose Valim, creator of Elixir, and Ginger Bill, creator of Odin. It's soon to be Thor, you're about to, you're about to be a granddad.

• 1:23:12Speaker 00

  (growling) Is that a thing? Can you be a granddad in languages?

• 1:23:17Speaker 02

  Uh, maybe.

• 1:23:20Speaker 04

  Joe Armstrong, he, the creator of Erlang, he considered, you know, he would say Elixir, it's like his grandchild, he's a grandfather now, so.

• 1:23:31Speaker 02

  I mean, at this point, if that's also, I mean, Nicholas, the creator of Pascal, and also worked on Algo and all that. He, so Algo, pretty much the stemming of every single, like, the imperative language from now on. Yeah, at that point, he's not a grandfather, he's like, great, great, great, great, great, great grandfather.

• 1:23:47Speaker 04

  He's Adam, right? Adam and Eve, yeah.

• 1:23:49Speaker 01

  He's the patriarch.

• 1:23:50Speaker 02

  Yeah, he's Adam. Now the question, who is Eve?

• 1:23:53Speaker 00

  Obviously, Fortran. She's a little older.

• 1:23:56Speaker 01

  Why not on the next episode of Stand Up?

• 1:23:57Speaker 02

  Yeah, there we go, Fortran. Now that is, yeah, there we go, Fortran.

• 1:24:01Speaker 00

  Alright, well, thank you very much for watching this. This was another episode of the Stand Up. I have never actually closed it. The Stand Up.

• 1:24:09Speaker 01

  Well, I didn't know if you were gonna say anything.

• 1:24:10Speaker 00

  Oh, okay.

• 1:24:10Speaker 01

  Goodbye!

• 1:24:12Speaker 00

  Bye.