Skip to content
TrackPodcasts
technologySep 20, 202625:56

Linux Dev Time – Episode 159

Get every episode summarized

Each time Late Night Linux Family All Episodes publishes, we email you a written briefing from the transcript — the topics, who appeared, and any specific claims, with the ad reads skipped.

Email me new episodes

Free for 3 shows. No card needed.

About this episode

“Thanks for choosing to listen to this late night Linux family podcast. We're only able to do this because of the people who support us. Learn more at latenightlinux.com slash support, or support us by telling a friend or colleague about everything we do.”From the transcript

Our fantasy programming language features.

 

 

 

 

 

 

 

Support us on Patreon and get an ad-free RSS feed with early episodes sometimes

 

See our contact page for ways to get in touch.

Subscribe to the RSS feed

Hosts & guests

Transcript ready

360 searchable segments. Every word is indexed and playable.

Linux Dev Time – Episode 159

Late Night Linux Family All Episodes

0:00
25:56

Full transcript

Late Night Linux Family All Episodes — Linux Dev Time – Episode 159. Machine-transcribed; use the interactive transcript above to jump the player to any line.

Thanks for choosing to listen to this late night Linux family podcast. We're only able to do this because of the people who support us. None of our showers are pay-walled, but our Patreon supporters can get most episodes early and never hear any ads. Learn more at latenightlinux.com slash support, or support us by telling a friend or colleague about everything we do. Hello, welcome to episode 159 of Linux Devtime. I'm Joe. I'm Marmalis. I'm Geven. And I'm Andy. Good to talk to you all again. Welcome back, Amrith. It's been a while. Mm-hmm. And you recently started talking about fantasy programming language features. And I'm afraid to say I didn't really understand much of what you were talking about, but I thought this is interesting to people who like this kind of stuff. So tell me about a fantasy programming language. What features would it have that you don't have in other languages? Yeah, so I always have a fantasy programming language in the back of my head.

Like, I'm always designing one, which has got all the best bits of all the things I like, and then a few extra. And generally, it's basically like, I can do this thing in Lisp. Why can't I do it in my programming language? And so here's my first one. I would like, in a different program, or a different bit of my program, I would like the plus symbol to have a different meaning. Right. So in one program, plus means you add up, and then if the number gets too big, it rolls around again, or crashes, or whatever you want. But then in another program, I want to be able to say, you know, three plus two, but I want that plus to mean, actually, if the number gets larger than the size it can fit in, it just sticks to the top, it saturates. So I want to be able to redefine things like that on a very fundamental level. And you want to be able to redefine this stuff at like, the program level, or like the function level, like what dynamically changing, like between calls, what do we mean here? So I would accept just at the program level,

like for some of these these use cases that I have, it's basically, right, this is the type of program I'm writing. So in this type of program, I want it to crash the program if something unexpected happens, or in this type of program, you know, as long as it's a big number, I don't care if it's not exactly the right answer, you know, things like that. Okay. So kind of like, like I would almost call this like a configurable language, like you configure it up front, and then that kind of applies to this compilation of, of particular, that's interesting. I've never thought about that before. I started out thinking I hated this idea, and then you turned me around saying it would be program level, because I think making it fire level, if there wasn't some way to visually distinguish between one and the other, and find that maddening. Super powerful features are always double-edged sorts, and especially changing the behavior of something that you expect to behave predictably is very dangerous. But yes, and maybe that's why program level

would make sense for that this one. I'm curious how that would work. Like I've definitely worked on things where I need a satirating ad at one point and a wrapping ad, like right after that. So I could also imagine like, well, this would be great for some things, it would be like absolutely maddening, as I'm writing something like, no, I just want this to be this call or something. Yes, so then you'd end up with a feature request to say, actually, I want to change it just in this bit. So let's go a bit further than that, right? And let's say, what if I could redefine what it means to call a function? So maybe every function call, the result gets wrapped in a particular type of wrapper that's useful for something, or like, you know, simple example, let's say, you always multiply it by two after you've called the function. Like we've changed what actually calling a function means. Wouldn't that be cool? Where would I reach for this? This sounds like more invisible side effects. Oh, yeah, it's really cool, isn't it? The reason I'm talking about it is because that is one way of viewing a monad. I thought monads were just burritos.

If you're deep into Haskell, then you might see why you might want to change what happens when you call a function. Because that's what monad's one way of looking at it is, that they're a way of changing what happens when you call a function, so that you're kind of wrapping your stuff with a thing that's being carried forward from function to call to function. Okay, you're maybe selling me on this one too, because that is broadly useful. In fact, I mean, obviously a lot of languages have a lot of the things that we're talking about, or similarities to it. So I could definitely see that one now. But I think I've scared you. What about you? What's your fancy language features? So not necessarily a fantasy thing, because this does exist in other languages. But obviously, I write a lot of stuff in Rust, and I like a lot of the features of Rust. I don't like all the features of Rust. So even though I would classify myself as a Rust fanboy, not all the features are for me. Either way, the feature that I find missing a lot that I would love, because I like a lot of the rust features, but there's one I would love to be able to have ranged integers. So I could say this particular type is values 2 through 8,

or whatever I need. And that being forced as just a standard integer type across my program. And I think things like Ada have this, and there's just so many times where I need a particular range of things. But I don't want to go through all of the weird shenanigans to have the compilers today, in force of that, where you have to have new types. And then there's like method calls and things to... I want to treat just like a normal integer, but I want it to air out or have some sort of condition that I control, whether it be saturating or wrapping or whatever, if I get outside that range. So I would love to have that. And I guess very similar or closely related to that is variable bit width integers, where I can have a integer that's like seven bits wide, or one that's three bits wide. And that would also be another thing. And I think these two things could kind of combine would basically solve all the issues that I fight with regularly.

And would you be okay with a runtime error when you went outside that range? I think it would have to be... So I've never implemented a language myself, and that's one of the... Even that's what call it a right of passage first, developers. I've never done that. I've always thought about trying it. I think it would have to be. So I've never put a whole ton of thought into this and how this would work under the hood. But I cannot fathom that all of these values would always be known at compile time. So I think you'd have to result to some sort of runtime errors. And that's why I was saying maybe there's a way you could define that this is a saturating thing outside the bounds or maybe just clamped. I'm not really sure, but I would love to be able to just treat it like a normal integer, but only within these particular bounds. Because one thing you could do if you really want to take that a long way, and I think a language like actor or something like that might do this. Things with dependent types is that you could... You could say, okay, I've got this number that's anything between 0 and 3. I've got this other number that's anything between 0 and 4.

And then when I add them up, the type of that thing is now anything between 0 and 7. And you can go that far, you know, if you really want to go that far. Right, which is there are times where I want something exactly like that, where it's a new type entirely or other ones where it only comes out to one or the other pre-existing type. So there's all kinds of things, but like that's kind of the direction I would go and I think maybe just because of a lot of the weird networking stuff that I end up writing, I'm always feeling like I need this kind of a thing, and it is more of a pain to add it than I think it should be. What about you, Amalus? I've got two. They're kind of higher level. I'd like go just as it is, but with no runtime or with a lighter weight runtime, I don't know that you can really do without any runtime. And for every programming language I use to have as good an ecosystem and like tool set and what not as go. You know, it's funny. When I read through a lot of other languages like Zig is one that I think I

actually feel this way quite a bit, where they have a particular feature or it might even be a language feature, it might be a tooling feature. And I'm like, why can't Rust have that? Or whatever language I'm having to be writing in. And sometimes the answer is not trivial at all. And other times it's because the other language has made a trade off that the language I'm currently using didn't agree with or won't make the trade off. So that's a big way. I do find myself in a similar position of like, hey, I want to write this language, but I like I want this other feature. Some other language has. And some of it I think is also due to like how modern a particular languages are like rather when it was created because more modern languages modern as in like more recently created have different sets of tooling than languages, you know, a longer time ago. There are different expectations about how you'll develop a thing. Yeah. And so some of that I think is like tooling related, which if it's tooling related, that's kind of cool because that actually means you probably could if you wanted to spend all the

effort time and things like you could create tooling for particular language. Now the weird parts are like, let's say you wanted to create a modern tooling for C and there's a different thing that may not work for that, right? Like you very well could do that, but it probably would not be adopted by the wider C community, right? Like you just have to be okay with that being a sort of niche use. And if that's what you need for your thing, like have at it. That's awesome. And if that's not a goal, yours them, then great. So speaking of ZIG, I would really like one of the things about ZIG, which is that you can run code at compile time and you can have that code kind of build your code in some sense and have types come out of the compile time function and then use those types at runtime. Yeah, ZIG has that thing called calm time that you're describing. And I think that is a really cool aspect. I've heard mixed, I don't want to say mixed reviews because almost every review of ZIG says that calm time is amazing, right? And that it is one of the features of it.

But I've also heard like it's somewhat limiting, right? Like it's not exactly just pure ZIG programs, right? It's like pure ZIG syntax. And I wonder if taking that same idea to another language to this fantasy language that you'd be creating and saying like arbitrary code could be compiled. And then you're kind of like in the rust proc macro sense, but without the weird proc macro syntax and libraries. So like that would be a super cool middle ground. Yeah, I think the attraction of running code at compile time and having it like not literally, but effectively spit out code that runs at runtime is that potentially you get simplicity out of that because a lot of the features that a language like Rust or C++ has in order to get you all these kind of powerful constructs require new language features. You know, you need generics, you need templates or whatever. All this stuff that happens at compile time, maybe if we designed it right, all of that could be

replaced by just code, like essentially kind of a standard instead of generics, you'd have the standard library function that does generics for you that is just written in your language and runs at compile time. And that could be really cool. I think the worry with that is that you might end up in a situation like something like what sometimes happens in JavaScript, which is that there are 10 different competing implementations of modules or whatever language feature you want because they're written by people who aren't like in control of the language just by anyone. And that's pretty terrible. Well, like you said to these really powerful language features often are double-edged swords. And not only could you have like competing implementations of various language features or what another language would be language features, but you can also sometimes take these to like arbitrarily weird limits and then you end up with something like, you know, C++ templates and you're just getting to this like whole other domain of difficulty. So I guess

like limiting features, you know, if we're talking about like something like ZIG comp time, limiting features on purpose can actually be a benefit as well. So maybe I'll retract my previous statement. How does this fantasy feature we're talking about differ from something like code generation during the build process just before compilation? Yeah. So ZIG's comp time from my understanding, right? I don't write ZIG daily is limited in the fact that it will execute the code, but it's very limited. Like there's no file system or network access. There's no, I believe there's no like standard library calls that are available. So it's effectively like kind of syntax only very, very limited. And then what it generates is effectively more syntax. So it's kind of like code generation, but on a very limited scale. Don't quote me on this because someone's going to say I'm absolutely wrong with this, which I probably am, but I believe the syntax part of the

like the calm time syntax itself is not like pre compiled and executed. I think it's executed more longer lives of kind of like interpreted during compilation, but I could be entirely wrong about that. Yeah. And certainly true. The code that rust runs at compile time because it has like a very, very limited form of this is effectively interpreted. Yeah. And then rust has another weird thing that I was mentioning a second ago called proc macros where that is effectively like another program compiled and then executed, which has other sets of downsides, not only like syntax wise and complexity, but also like it's another rust program. You effectively can do whatever you want. You can make network calls and you know, do anything. Yeah. And that's bits out not textual code, but effectively it's bits out bits of syntax tree. So effectively it's generating code. But yeah, so let's go back to the fantasy world, right? So the reason why this is better than just generating textual code, which isn't infinitely flexible is that like it's really easy to mess that up. So when you're

generating code, you might say just miss out semi-colon and then your code doesn't compile. So that's the like the dumb example of why this could be a bad idea. But if you imagine sophisticated compile-time code running that knows the shape of a class or an enamel or whatever, you can guarantee that it's bits out semantically and definitely syntactically correct code. And you have high level constructs as opposed to you having to get it all right and generate the right characters in the source code that you generate. So in the ideal scenario, it would you just have kind of godlike powers of saying I need 17 classes that all look like this, but they have different names and like they want some of them have this property, right? And then it would just produce you all those classes and they'd be correct. All right, I've got one more and I almost feel like this is this ought to be possible. I would just like a way of saying a function is pure in the sense that if you give it the same argument, it gives you back the same answer and it doesn't touch anything

else in the outside world. It doesn't print anything, you know, it's just, you know, in the computer science terms, it's a pure function. I want to be able to write pure fun or whatever and then write my function and then I know it's pure. And this is enforced by the compiler or enforced by some sort of runtime. Infulspile compiler. And that means I can do it in parallel or I can like memoize the answer or whatever and I just don't have to worry. It's definitely definitely going to work. That would be nice. I guess if we're talking pure fantasy. So this is like this as far as I'm tracking, this is not even possible. So pure fantasy feature. It's not even really a language feature. It's more like I wish the world was different. And that strings were just strings. It was a quote with some characters and an end quote. You don't have to carry about like bytes under there and byte encodings and whether or not they're null terminated or not. And whether or not the like things are UTF8 or just like I just want simple strings. I know this

is probably is a more privileged way to look at it because I don't have to deal with a bunch of other characters that's very often unless you include like emojis which get weirdly complicated as well. But like I just want strings to be strings. I just want them to be simple. I want strings to be the thing that when you first start computer science 101 or whatever it is or even just like a high school class and you're just like, Oh, I get this. It's just string a character. I want that to be true forever. I think the language that should give us that is Python 3. Now I'm not saying Python 3 does give us that. But that is the language that should work like that. It probably gets us the closest to that. Yes. Yeah. Part of the problem with Python 3 is it has the legacy of Python 2 still hanging over it. But yeah, in Python 3, a string is just some characters and normally you shouldn't have to think about it more than that. What's funny is like if you look into rust strings which are notoriously people look at them just say like what

is going on here? And it's because rust says like we're not going to hide the scary parts from you. And in rust, there are like 16 string types or something along those lines. Now I would say of those 16 probably 14 of them are esoteric and not not. You need to. You need to. Right. But or I would say three maybe if you're talking C strings as well. But either way, well, maybe for an affinatical devotion to the public. So with these different string types, like there is a lot to care about and Rust even gives you the caring about like whether or not the the memory is owned by you or not or it's just borrowed or whether it's a sequence of certain Unicode characters or it is not or it's just bytes like rust actually does expose all these things to you. And normally I would say 99% of the time I like having that type of control. I like having seeing through the curtain. I like seeing all of the little details of why something is the way it is. And that's probably why I like languages like rust. However, when it comes to strings, this is just one of those things that I'm like strings. I just wish that they were simple and they're not. So what you want is the

fantasy language that nearly got written or is nearly finished, which is called parrots, which is language that underlies the rewrite of pearl that has never quite been finished. Where it's like a machine code. Parrots is like not exactly machine code like a bytecode except it has high level strings in it that work like you don't have to know. It's just it's just right. I'd they have never heard of this. So I know what I'm going to be googling this weekend. I'm pretty sure it's Pearl six, which never actually happened or now they released something else, which they calling Pearl six, which is not it or I can't remember. I lost track of where it got to. There was something called like racco or something that was related. I don't know. I think racco is what they named the language that was going to be the sixth version of pearl, but it turned out too different. I think I think anyway that actually that does bring me on to a point of like what is your level of abstraction? So for me, the reason why I named and shamed Python 3 here for it ought to be able to handle strings and to some extent it handles strings very well.

A very like you don't have to think about it is because Python's level of abstraction is right for that. And like like you were saying Kevin, rust's level of abstraction is not right for that. If rust tried to do that, it wouldn't fit because in Rust you're like you are talking about bytes and stuff. And in Python, you can be working at that high level of just talking about characters, whatever you mean by that. I guess if we were to merge that idea with your like configurable by program type idea, I wonder if something like that would be possible with strings because like Rust does have some light syntax for certain types of strings. And by light syntax, I mean there's no like class or object call and method call or function to create it is just like the quotes, the things inside the quotes and that's it. However, in Rust, that's a very particular thing. And it has a very particular meaning. But what I'm curious about is like, what if I could say for

my particular program, when I do quotes some stuff inside of it and in the quote, that it means this other type of string, like a heap allocated string that I own or something. And various libraries have tried to do something like this, but I'm talking about like taking Andy's idea from that sort of configurable by program language where I can say this syntax means this thing for this program. That would be really cool. I'm sure a lot of people would hate it, but I would love it. So there is such an important and useful use case for that, which is when you're compiling Rust to Wasm and you're interacting with JavaScript and all the strings in JavaScript, UTF 16 or sometimes UCS 2, which is even worse, but anyway, don't think about that. Then if all your strings in Rust are UTF 8, which is what they are, then every time you interact with something that's seen that the browser, or something like that, there's a conversion happening. So yeah, let's have a program-wide thing that just says all the strings in quotes are UTF 16. Oh, that'd be great.

Okay, we're going to do this. We're also going to remove the go-run done. Awesome. But keep garbage collection? That's a good question. Do you keep garbage collection there with when you remove? Good, we'll do it without it. Okay, well, it adds some kind of concepts of object ownership and maybe we can to borrow things. Well, it's index for lifetimes, maybe to- I don't know. We're going to need them. We'll have rest before we know it. If all you ever do is allocate, you're never free, then you're fine. Yeah, you just turn off the garbage collection and like exit is a great garbage collector. I am somewhat curious, Amnesty. You mentioned that there's a lot of aspects of go that you would apply to other languages. Like what specifically? I said, tools and the ecosystem, like the expansive standard library or batteries included standard library, you might say. GoLangCiLint is a awesome linter that bundles a bunch of other linters created by other people. So you can get this one piece of software and then run like 20 checks

on your code at once and very easily have all these different ways to make sure it's not doing bad things and it is doing what you intend it to do. Go with the leading language that brought about like you should just be able to format your code and not think about the formatting. Yes, that's another thing I really like. Yeah, not just not think about it. Like you can't think about it. You can't even figure it. There's the GoSpace FMT tool that's built into the GoTool for formatting your Go Code. But I don't even use it because it's not opinionated enough. I use a different tool called GoFumped.g-o-f-u-m-p-t. I think that has more rules and standardizes even further. But then doesn't that just like kind of go against the original? Like there are no options. All Go Code looks the same. Now you have like kind of strict and very strict Go Code. Presumably the strict one complies with the less strict one, right? Yes, it does. Okay, so you're okay. You're just getting extra opinions on top of what's in for.

I'm surprised I believe you wouldn't like Rust. There's a lot of opinion there. Oh, so many opinions. I have done a very little bit and the very little bit I have done feels it feels almost like the puzzle solving gets in the way of the problem solving. That was a dagger to the heart. You put your finger on something there. I enjoy it. I just don't know that I always want to use it. So yeah, my fantasy language right now is essentially Rust with compile time execution and pure functions and being able to redefine whatever I like up front. Yeah, it sounds like my fantasy language is a weird abomination of like Rust and Ada and Python and Go. I don't know. It's just this like absolute mismatch. And I'd also like to remove almost all the complexity from Rust, but still keep all the capabilities. Oh, I'm sorry. I'm into ad Zigg in there too. There's love for sick too. Yeah, yeah. I think I would like something that is just completely reconfigurable the way list is right. In less, you can define effectively your own language and then use it. And that's kind of what I'm getting at with a lot of these things I'm

playing. And I'd like it to interface with all other programming languages seamlessly using the CABI or like no seamlessly. I said. Well, do write in and let us know your fantasy programming language features show at the next DevTime.com. We better get out of here though. We'll be back in two weeks. Until then, I've been Joe. I've been Omeleth. I've been Gavin and I've been Andy and I want to clarify that's fantasy programming language features only. Yes. See you later.

More episodes

More from Late Night Linux Family All Episodes

View all episodes →