Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Is Odin, "programming done right"? (with ‘Ginger’ Bill Hall)
1.9k Plays10 months ago
Odin’s creator, Bill Hall, makes some bold claims about the language, including that it’s “programming done right”. Before that starts a war on the internet, we’d best ask him to explain what that means, and how Odin tries to achieve it. And while we get deep into the details, overall his answer seems to be, “By gathering masses of feedback and then refining C until it feels joyous again.
Of all the C-like languages we’ve looked at on Developer Voices, Odin seems to be the most at-ease with its progenitor. It’s not trying to be a revolutionary new way of thinking about systems programming; it’s just trying to rethink C for modern conventions. If Bill’s hit his goals, it might be the most comfortable way to get a language that’s C, but C done better…
–
Odin: https://odin-lang.org/
Odin Packages: https://pkg.odin-lang.org/
Newsqueak [pdf]: https://swtch.com/~rsc/thread/newsqueak.pdf
EmberGen: https://jangafx.com/software/embergen/
Raylib: https://www.raylib.com/
RayLib bindings for Odin: https://github.com/odin-lang/Odin/tree/master/vendor/raylib
Verse language: https://dev.epicgames.com/documentation/en-us/uefn/verse-language-reference
Algorithms + Data Structures = Programs: https://en.wikipedia.org/wiki/Algorithms_%2B_Data_Structures_%3D_Programs
Bill on Twitter: https://twitter.com/TheGingerBill
Kris on Twitter: https://twitter.com/krisajenkins
Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
--
#podcast #software #softwareprogramming #programming #odin #odinlang
Recommended
Transcript
Introduction to Odin Language
00:00:00
Speaker
This week on Developer Voices, we're looking at a systems programming language called Odin, which is trying to be C but older and wiser, how we might implement C if we knew then what we know now. And that's led to a few really interesting choices. At a low level, it's got things like native support for matrices, control over how data gets laid out in memory, some things that can have a really huge impact on performance when they're used well,
00:00:29
Speaker
And then at a high level, there are some ergonomic improvements. We have them writing C for 50 years now. There are patterns and conventions and expectations that should probably be supported by the language because they're so ubiquitous. In practical terms, it's been built from day one to support Mac, Linux and Windows and some embedded hardware. Most languages treat at least one of those as an afterthought, so that's nice to see.
00:00:57
Speaker
And I thought this was really cool. There's a good chance, even if you've never heard of Odin, you've already seen it in action. Because its first big commercial user used it to write CGI software for generating things like smoke and flame and particle effects. So there are little bits of Odin that can be found in video games and movies these days.
Interview with Odin's Creator
00:01:20
Speaker
Joining me to discuss it all is the creator of Odin, Bill Hall, who goes by the handle Ginger Bill. And I would expect Odin to be a friendly and approachable language, because Bill is a terribly friendly and approachable guy. But one with some strong opinions, so we need to get into that. I'm your host, Chris Jenkins. This is Developer Voices, and today's voice is Ginger Bill Hall.
00:01:58
Speaker
joined today by Bill Hall, the creator of Odin. Bill, how are you? I'm good. How about yourself? I'm very well. Yeah. Yeah. I'm looking forward to the weekend, but I'm looking forward more to this conversation. Well, thank you. Thank you. You've got some very interesting ideas about programming. In fact, right? You created Odin. I assume you're responsible for the language on the homepage. Yes. And one of the headlines it has right at the top is programming done right.
00:02:26
Speaker
Yes. Which is about to start a flame war on the internet as we speak. Of course it is, of course it is. It kind of implies that you think someone out there is doing programming wrong and you're here to fix it.
00:02:38
Speaker
In a partial way, it does, yeah. To a certain extent, how do I put this?
Odin vs. Other Programming Languages
00:02:44
Speaker
There are people doing programming of, some people doing it right. Doing it right is just a very general term. Again, it's a marketing term, to be honest with you. But the reason why is for us is that Odin, as I'm the creator of, I've tried to be kind of like an alternative to C.
00:02:58
Speaker
And a lot of new languages out here today are trying to do other big ideas and many ideas. They have different ideas about safety or memory allocations or even just different paradigms in general. And it's kind of like, look, we want to be a C alternative, so we're going to keep within that kind of tradition. So we're going to keep doing it with doing it done right in of that tradition. So you're saying your idea is what if C had had a version two or whatever the next version along is?
00:03:27
Speaker
Not necessarily C itself, but more of the imperative procedural tradition itself. So the C, the Pascals, even the new ones, even the more probably closest can they copies go nowadays. They're all in that lineage and more of a like, okay, how would I improve of that lineage rather than trying to go like, oh, we're going to try something completely different.
00:03:46
Speaker
Right, right. So it's not like an experimental research language. No. Most of the ideas within this language are so old. I think some of them are brand new, but the vast majority of it is from the 80s or even early 90s. The ideas are they're not new, but they're well-tested in that regard and I know how well they work. OK, so give
Control Flow and Code Intuition
00:04:05
Speaker
me an example. What's something you've picked out as C should have had this by now?
00:04:09
Speaker
One of the basic simple ones is the defer statement. Now, some languages have had this for ages, but this is another way of doing control flow, so you defer a statement to the end of a scope. Languages such as D have had this with scope exit. Go has defer, but that is function exit, so that calls a statement at the end of a function rather than the scope.
00:04:30
Speaker
I know other languages out there as well have it as well, but it's a very simple thing, but it improves your control flow with something that C would have, and it would work absolutely well in C as well. Because all it's doing is saying, hey, defer this statement, or any statement, in fact, whatever it is, to the end of the scope and call it. And there's a lot of things that would help with cleanup. If you've ever done in the base of things like FOpen in C, opening a file, and then you've got to close it, well, you've got to be careful where you close it,
00:04:58
Speaker
But if you just define it right behind it, it's fopen, handle the error, defer fclose, it's done. It makes the API a lot clearer. So that's a very simple thing that should have been, not with us, it should have been in C already, but it would complement in C already. You'd be happier if it were. Indeed, yeah. Yeah, yeah. So contrast that for me, because that makes me think of something like in Python, we have a with statement. Yes. But that's less explicit.
00:05:28
Speaker
Yeah, with Python's with is effectively a hunt like it goes over like the try, except finally kind of thing. That's what it's doing and wrapping around there. So the thing that you call handles that are for deferred thing, the finally thing for you would be it either be like a note, like a
00:05:47
Speaker
a co-routine kind of style thing, or just whatever, with an exception, whatever has been handled. With this one, it's very explicit where the control flow is like, hey, we're going to defer this statement here, and it'll be called the end of the scope. So it is similar to like, Python's width in that regard, but it isn't the same thing, it's a bit more explicit.
00:06:02
Speaker
clear what's going on. You seem to favour explicit behaviour as a design feature for Odin. Not always, but usually yes. So when you're dealing with C, you kind of want control over how things work, usually, how things operate. So you want to be a bit more explicit, but one of the design goals of Odin is more of minimising implicitness, not maximising explicitness. So there's a lot of things in Odin which are very
00:06:25
Speaker
implicit, but they're very intuitive at the same time. So even though they are a bit implicit, it's very much like, I know why it's there, it's not a problem. That's intuitive and simple, which is another word. Yes. Everyone thinks that they're simple and intuitive. No, they're not. They're really not. Give me your definition.
00:06:51
Speaker
I'm going to be very careful here. So simple in this case is an overloaded word. There's two different kinds of simple. There's simple as in the opposite of complex. So I would call this simplex if you want to be the technical term. So simple and complex. And then there's the opposite of simple, which most people mean is easy. So the opposite of that would be hard. So you've got easy and hard and simplex and complex.
00:07:13
Speaker
When it comes to intuitions, intuitions are kind of an instinct in general built over time, and they're kind of sometimes heuristics, or sometimes they're just ways that seem correct to you. That's a way of what an intuition in the way an intuition is what to you says, Oh, this seems how I know to know things. So when you've come over programming over the years, you build up many of these intuitions. And these intuitions are very complex, but they're easy to you to understand and grasp because they are like a big web of different ideas all meshed together. But they're like a small unit.
00:07:42
Speaker
of you, easy to understand, but complex in their construction. So a lot of this, when I was designing the language, you actually have to ask a lot of people and see what they do and see what actually happens when they do this with things. Why were you expecting this? Well, it seemed intuitive to me. That's usually what they will say. This is what I expect. And I'm like, OK. And then you find out what people like, you have to dig further. Why did they figure that out? Find out and go, oh, yeah, what it is.
00:08:09
Speaker
And usually these minor, these intuitions you kind of have to play with, and sometimes there's a lot of, like there's a lot of implicitness in that intuition. But if you make it kind of explicit and make it into a concrete idea, it can simplify it a lot. That makes it easier to understand. Can you give me a concrete example of that?
Type System and Code Correctness
00:08:30
Speaker
Actually, probably I can actually. Just let me think through the language. So Odin has a very basic rudimentary type inference system.
00:08:38
Speaker
Just to help out. A lot of the time, how it came to be, the inference works is through that intuition stuff. So a lot of things have numbers in Odom, right? So if I write the number one, it's the number one, but it's untyped. So this is similar to a language like Go has something like this, or you may call them existential types in Haskell, or there's all different things, what you call them like this. But this is a number, and this number can then be represented by multiple different things, like number one could be an integer,
00:09:07
Speaker
It could be a float. It could be any of the stuff like this. But if you have the right number 1.0, by default, this is why we call it an untimed float. So it's default type with BA float type, specifically an F64. However, 1.0 is representable as an integer.
00:09:24
Speaker
Yeah, right. So why can't you just assign that to a specific integer type? And as soon as you can, you know, because the only understands the value system from these basic ideas of having all that they build up the complexities and the intuitions of people because then things just start to feel correct.
00:09:42
Speaker
And this may seem like why is this such a big deal why do you have to make even the basic of numbers and constants feel correct one thing is in C everything is typed even the numbers if you write the number one and see there's an integer if you want one point oh that's a double if you want to get flow you have to do one point oh f. Or if you want to do an unsigned you have to do like one u or one u l or one u l l for a long long.
00:10:05
Speaker
So you have all of these different subscripts because every little literal is typed. And the thing is making it feel correct with all these different semantics about how constants values work. Again, compared to see where it's everything is explicitly typed.
00:10:19
Speaker
And then sometimes this causes bugs in C as well, like when you've written like 1.0 and that's a double, but actually what you wanted was a float, so you wanted an F on the end, but the thing is there's some implicit conversions going on everywhere and these implicit conversions in C are usually sometimes to get around the constant value system in the language and it causes some friction. So if you actually try and make it much more
00:10:40
Speaker
make it just work. So I'm sounding like Todd Howard here, but it does make it feel correct. And it does. It's kind of like you figuring out what those intuitions of people have. And that took a lot of experimentation to get it to go. Hmm. That's what people actually want. Let's do that and codify the rules. That's
00:10:57
Speaker
I mean, it does take a lot of work. It's very easy to get wrong. I'm thinking of like JavaScript, which has a lot of type coercion, which doesn't really work that well. But Odin actually has a version in no implicit conversions whatsoever, because those values don't really have a type yet.
00:11:13
Speaker
in a weird sense. Some people in the comments will go, yes, they do. I understand the type, it's not the point. It's just they don't really have a concrete type yet. So when they come to, when used, they will usually in a concrete specific case, they will get a concrete type, but they'll work and figure out which is the best one, not the best one, but the most intuitive, technically speaking, it's the best word I can use to describe this. And it's just a little thing, just the little things like that, but it makes it more intuitive and get you actually solving the problem and not having to worry about other things.
00:11:44
Speaker
Did you, was this born of just frustration with C or were there other languages inspiring you?
00:11:50
Speaker
Loads of other languages inspired me, but a lot of it was born from frustration C, because most of my day job was writing C, and mostly C was plus. But I did know a lot of other languages out there. I've forgotten too many languages, that's half the problem. But it's very much like I know how other languages solve certain problems. It's like, I wish I had this idea from here, or even just simplify. I wish I got rid of some stuff in C. Why do I have to deal with this stuff?
00:12:15
Speaker
Can I just have a small language in times? When I was making Odin,
00:12:21
Speaker
I was kind of very drawn towards more of the Pascal tradition. So one of my favorite language designers anyway is, depends on how you pronounce the name, it's either Nicholas Wirth or Nicholas Wirth, depending on if you do it by name or by value, his name is the joke goes. Because he is the creator of Pascal. But one thing he's always done, Pascal was a teaching language. So he's done a lot of stuff over the years for teaching resources. But one thing I've always loved about the Pascal family in general is it's very clear, very clear what's going on usually, and very well defined.
00:12:52
Speaker
And from that tradition, many other things came out. So another one of my design idols is actually Rob Pike. So he's most people probably know him nowadays for the Go language, but he has done so many languages over the years for many domain specific tasks, but also things like in the 90s, one of them, the Odin's declaration syntax comes from technically speaking is the New Squeak language.
00:13:13
Speaker
which is back in the early nineties he developed. So there's a lot of these different things which I've tried to draw together and I'm like, look, I know how these ideas work. They've kind of been tested in the field. Like, right. Can I have this back and keep it in the same kind of tradition of the sea Pascal tradition here and make it feel
00:13:30
Speaker
all better for people and also make it to solve problems. I don't have to be fighting the language every day, which I was doing with C++ and even C at times. You fight the language because it's like, oh, no, I can't do that. No, I can't do that. I'm going to invite you to find a behavior. No, I can't do that because grammar doesn't work. No, there's all loads of problems and you can't fix it, unfortunately. C is not fixable.
00:13:48
Speaker
So, and I found that out the hard way, trying to make my own C-compile and trying to fix it. I'm like, nope, the foundations are broken, so we're going to have to go somewhere else. Do you know, I've heard a lot of people recently, because we're doing a few episodes about C-like languages, and a lot of people have said, well, why not just fix C? So maybe you can help us pin that down once and for all. Why is C unfixable?
00:14:10
Speaker
Firstly, CS50 is old. When it was first created, it was designed for certain systems, had many ideas baked into it. The reason why, again, the simplest one is to look at the types. You've got char, you've got short, int, long. Well, that's because those are generic terms, because on the systems we were running on, all of them were different size bytes. It could have been 6-bit bytes, could have been 12-bit, 8-bit.
00:14:32
Speaker
Could be anything in that real sometimes even nowadays still get 32 bit by sometimes on certain systems so you get all of these different size. Systems and it's like okay that would be very generic is a lot of ideas which seemed good at the time or were actually good at the time but not good nowadays very good example of this is strings being no terminated. No terminator strings made sense back in the day because it was costly to actually store an extra interest somewhere where of the extra check the length and it was a cost.
00:14:59
Speaker
So back then it made sense, but very much like you don't want to do that nowadays. There is literally no real good reason to do that ever. So unless you're interfacing with C, obviously that's the problem, the interfacing aspect. So it is always the question of
00:15:17
Speaker
which bits can you fix, but then the type system's broken with C. There are loads of little things like the type, all the implicit casts causing issues, the operator precedence, not even just syntax, but the semantics of language. There's a lot of undefined behavior. One thing I really don't like, you can define the vast majority of the behavior.
00:15:33
Speaker
And the stuff that is, let's say, I'm playing pretty much everything you can define. The question is where you're defining it. And that's always the caveat when people always bring up with undefined behavior. I'm like, well, you just specify who defines what. Like, is it the compiler? Is it the language? Is it the platform? Is it the, who is defining the language? You tell them you must define that for us, and therefore it's now defined. And you get a lot rid of the vast majority of that undefined behavior that C has, which is a massive annoyance. We have to always kind of think like, what am I invoking here again? Oh yeah, great.
00:16:02
Speaker
kind of thing. So does that mean you've got like an official spec for Odin that you're happy with? There is no fully written spec yet. I need to write it. It's going to take me a few months, pretty much. But there will be an official spec. And once that spec is written, and the compiler adheres to it, that is 1.0 for the language. How far away is that?
00:16:22
Speaker
Well, the language itself is pretty much done, but I've got to write the spec and I have no idea. It's just because it's writing a big spec. It's not like a little toy language anymore. This is a huge language in many regards. So it could take a year or more, a lot longer, maybe. I'm not putting a date on anything. So if anyone's put me to a date, no, no. Fair enough. Yeah, pretty much. Yeah. It's like, I don't really have an official roadmap because it's very much a,
00:16:49
Speaker
We don't know when we need things, we just do it when we need it pretty much. When people ask, are we working on it now? Official roadmaps, I've always found most people never keep up to them anyway, ever. It's just you're advertising something that's not going to happen. To be honest with people who are using it, I'm like, no, we're going to do this or no, we're not going to do that.
00:17:10
Speaker
Okay, honestly, then what state is it in now? Is it production ready alternative to C? So we, for my job, I work at Jango Effects and we develop real-time simulation software for like the game, film and motion graphics industry.
Odin in Real-World Applications
00:17:24
Speaker
Our main product is Embergen, which is a real-time volumetric fire, smoke and explosion simulator, which many people in the games, pretty much many games are using nowadays. Loads of game studios have it. Most modern games are using our software for that.
00:17:38
Speaker
All of our products, tried Imogen, Geogen and Liquigen, are all written in Ogen. How did that come about? Because they're not, those aren't your products. It's not your company. No, not exactly. No. So you couldn't dictate that they use your language.
00:17:55
Speaker
No, so when they first kind of started up, there was two co-founders, there's Nick, and there is Nick Severt and Morten Basfik. These two were going to co-founders the company. I've known Morten for years, he's a friend of mine.
00:18:09
Speaker
And they were starting up because they were thinking like, OK, let's do this thing. Nick is an artist by profession, not a programmer. And he was thinking like, OK, I know this real time smoke stuff. I know it's possible. Can I find something to do? It's important to say, I'll do it. I've helped start off with you. And the language, he said, look, we're not doing C++, Nick. Whatever we do, just don't use C++. Look, my friend Bill, he's got his own programming language. And I want to be using that instead, pretty much. So they were working through that and doing their own tools and got other things before.
00:18:37
Speaker
eventually trying to get me on the team. And the venture went, oh, do you want a job working for us, Bill? And initially I went, maybe not. And then I eventually went, yeah, OK, sure, pretty much. So that's kind of got on there. So I've now been with them since early 2020, so nearly four years at this time of the recording. So it's been quite a long time I've been there. But it is surreal that I'm working in a job where they use my language. And I program in my language every day. And we produce products that people actually want.
00:19:06
Speaker
It is so surreal, to say the least. It's just lovely. Now, on our team, we've got about 20 different people at the company, over probably a dozen programmers, all using the language. It's an experience, I can tell you that. How does this work as a language designer in residence?
00:19:29
Speaker
Quite well, surprisingly. So usually, because we're using in production sense, I'm not saying I recommend other people to use in production, obviously, that's any language use at your own risk, obviously, there's warranties that don't really exist in that domain. But
00:19:44
Speaker
One thing that was helping me is that usually they would have like, oh, we found a compiler bug, but okay, I'll fix it. Go just go fix the bug. No problem. Then go back to working programming and Odin. And again, most of the time I will not necessarily working on the compiler. I'm working on the products written in the language, but also sometimes we came up to problems. You're like, actually, we've got a problem. There's a, there's a deficiency in the language. Like we've got an issue here. Like semantics aren't correct. Or we need an extra feature or something. Would you consider doing it? Adding it into the language. I'm like, okay. And a lot of the time I'd go, yeah, sometimes I'll go, no.
00:20:13
Speaker
I'm just having a hard line then. And luckily, I've got the freedom to say, no, I've got a hard line. I'm saying, no, I'm the dictator of this language. So this is how it goes. Because sometimes when people suggest things, you have to go like, it sounds good, but it won't work out. Trust me about that kind of thing. Because I've probably tried it already. It didn't work out. But it's very much like that. So sometimes we added features. And one little feature, I'm trying to think, yeah, one little feature we added, which
00:20:41
Speaker
It was mainly for profiling and the immediate mode UI that we make as well. And it was this, again, is coupling this to first sometimes. Sometimes we wanted to say, we call a function, and it also defers another one. So is this in case it is an implicit case, but these two cases are pretty much the only cases you'll pretty much ever need this implicit deferred attribute on a function. So where you call one function, it defers another one. So it's kind of like a weird bit of like RAI, if you use C++, but it's not on the type, it's just on the function call.
00:21:09
Speaker
And the only two cases we needed it for were profiling. So if everyone wanted to put this at the top, we could say, begin profiling, instead of defer end, we just put it in block. But the other one was also for Imgo. It's like, if you know, like, um, Dear Imgo is a popular Imgo library. It was popularized by, the idea was popularized by Casey Motori about 20 years ago, but we have our own in-house one. And, um, we, for a lot of the UI stuff, it is really nice to actually have these scoped things.
00:21:36
Speaker
Where we open up an if tree and you just open up the body or if menu and he does that for you. So these are implicit. But it was very much like we started noticing there was a deficiency in the language and we kind of needed it.
00:21:48
Speaker
because we could just be explicitly defer every time, but it really was really cluttering up the code and actually causing certain bugs because you wanted to only open it up if it was valid or not. So you'd have to defer if this condition, so you had to defer an if statement as well. So it was getting like the logic was getting a bit cumbersome like that. So that's one kind of those examples. We've got loads more on top of that, but certain things like that, we go, yeah, we've got to do that. OK.
Design Philosophy and Hardware Support
00:22:18
Speaker
delve into a few more of the features of the language that caught my eye when I was looking at it. A headline one is that you say it's a data-oriented language. Yes. Tell me what you mean by that and how it supports it.
00:22:32
Speaker
Data-oriented design was popularized a few years ago as an idea. It's like, hey, look, it's not focusing on the data itself rather than object-oriented or functional or whatever the paradigm that's in vogue at the moment. Data-oriented is very much like, look, what's the data you've got? How do you need to manipulate the data? What is the best way that can actually make it run to the fastest on that machine as well?
00:22:56
Speaker
So a very good example of this would be there's a feature node in which we have is SOA arrays. So this is structure of arrays. It's the difference for some people if you're in a database, it's different between row oriented and column oriented in that regard.
00:23:10
Speaker
So instead of having an array of structures in your data, or rows of the data, you can then reorganize the data by just adding a little tag that says hash SOA. And now it's structuring as if it's like a array of columns. It's like, oh, the first element array of that, second element array of that, third element array of that. So it changes that. And certain things on the data access on the machine, it makes it even better, because modern machines have things called like cache lines and stuff like that. So you want to utilize them as much as possible. Right, so this is like, if you've got 1,000 user structures,
00:23:40
Speaker
Yeah. You've normally you'd have the username, the age, the next username, the next age, and this you'll have like a thousand usernames followed by a thousand ages. Correct. Correct. That's one thing.
00:23:53
Speaker
So that's kind of sometimes haven't changed in the memory layer on that regard and keeping the same syntax as well, which is actually the real point here. You've got the same syntax as if it was like an array of structures like this row based, but it's actually internally laid out as thing. But the thing is the computer likes many cases, loves having in that layout.
00:24:11
Speaker
When it comes to other things within language age, we have array programming as well. You can actually add two arrays together, element-wise, and it will actually lower down to the correct machine code, like the SIMD for it. But we've abstracted it so it actually feels really high-level in many ways. It makes you feel like you're actually programming in a shader language. If you ever use GLSL, where it's got the swizzling, you can do .xyz or .yyyz.
00:24:35
Speaker
uhm, to a rush reference for some reason. But then there is the, you can, and then multiply it together. But the thing is there's actual instructions on your CPU for the hardware to do that. So it's like, why don't you bring that to the, the fold and actually say you can manipulate and actually process the data in a much better way. Is this because you, you're like looking at CPU architectures 50 years on from C and saying, here's a bunch of interesting new features we should bring into language space.
00:25:02
Speaker
Pretty much, yeah. It's pretty much like we know how the hardware works for the most part. So like, why can't we actually utilize that? Because again, C was built back in the 50s. Yes, the most modern incarnation really hasn't changed since the 90s in many ways. Yes, it's been minor extensions like C99 and C11, and now the new C23. But they really haven't changed the essence of the language. The essence is pretty much the same. And for the most part, it still works.
00:25:29
Speaker
But a lot of people still have to rely on extensions or into the language to get these new features that the compiler can do.
00:25:39
Speaker
can do. But the thing is, it's like, okay, why can't you design a language for the more modern machine, a more high performance machine? Because, but still have the control that C would have gave you anyway. And there's, weirdly enough, many languages out there don't try and do that. They're trying to be highly abstract and then take their abstract model and then apply it to the computer, rather than kind of start looking for the bottom line. What are the patterns that we can bring out from the computer and give it a nice construct from there?
00:26:05
Speaker
Ah, so this is because I often think programming is divided into people that think programming is maths down and people who think it's CPU up.
00:26:17
Speaker
I know both thinkings, but I'm usually CPU up rather than the maths down. I know the maths, which does help you formalise it in many ways. Because my background actually isn't in programming, my background is in physics. So I very much know my history and background is from quantum mechanics and such. So I do know loads of the mathematics when you have to do quantum mechanics and such. But you do have to build up as well. It's like you have to know both the directions.
00:26:41
Speaker
which come through and it actually helps you to like kind of ground you but also formalize you. You have to know a bit of both about usually more intuitively come from the CPU up and try and look at the abstractions where come there and make them concrete whilst being influenced by the mathematical side. Right. I have to ask this if you've got a background in quantum physics. Is there going to be a version of Odin that supports primitives for quantum computing? No.
00:27:08
Speaker
So the reason as to why is classical computing and quantum computing are very different beasts. And quantum computing at the moment is still in the very, very early days. There's not really any quantum computing programming which is out there. At the end of the day, they're just more elaborate mathematics. Like, hey, look, we've done a nice little matrix thing we've got here that we're doing through this Fourier transform thing. It's like, okay, great. This is still like raw math. It's not really abstracted. It haven't found the abstractions yet.
00:27:36
Speaker
Quantum Computing again is not going to, it has very specific domains where it's very good, and certain domains, most things aren't good. Like if you're going to make a compute game, you're not going to use quantum computing, classical can be fine kind of thing. There seems to be a lot about Odin that is leaning towards specifically the gaming world. Is that a deliberate choice? Originally, no.
00:27:59
Speaker
But again, from my experience, I usually do a lot of graphical stuff like physics and also 3D graphics. So there are some things in there which are kind of tailored towards it. And as a result of those little features, really, many people have been more drawn to like, oh, I'll make a game with this or I'll
00:28:16
Speaker
I make some application development. Again, in Jenga Effects, we are doing stuff that's not very dissimilar to making a game, really. We're utilizing the GPU a lot. We are doing a lot of physics and graphics and stuff that many games would also use in other 3D applications. So many of the language itself, Odin, is very tailored to those tasks.
00:28:36
Speaker
It's, but the thing is, we also, as a part of the Odin's core library and vendor library, we know that when people think about a language, they don't just think about the language itself. They think about everything, the entire ecosystem, thinking about the language itself, the core library.
00:28:52
Speaker
the tooling around it and the ecosystem in general packet that's what people think i say language that's the language for person if you ask a computer scientist i'm sorry a scientist uses computers what python is still think what python yeah it's got no pie and it's got cycles they don't think them separate they think that is what python is.
00:29:10
Speaker
Yeah, so we've been trying to put effectively the kitchen sink in there as well in many ways, but but the nice packages. So we have all of the graphics APIs. We have OpenGL, Vulkan, direct 3D, metal, WebGL. We have all of those graphics APIs and all native like metal is native in Odin. It's not a wrapper around anything. So we are calling the direct objective sequels underlying for it.
00:29:33
Speaker
which is quite nice. We've got other things in there, which is very nice, like even for Proton, like Ray-Lip. Many people may use that to make little games or prototypes. It's just the box, we've got STL, GLFW, all these things that are great for making little prototypes or tools, or even full-on-fledged games. It's in there as part of your download compiler, and it's there, getting ready to go. It's kind of the kitchen sink. Here's kind of the philosophy. The batteries include, as some of you may call it. Yeah, yeah. How fully featured is that today?
00:30:00
Speaker
Quite actually. So we have quite an extensive vendor stuff, the vendor libraries we're calling it, rather than the core, which is called the language, the vendor stuff. If I can remember what's in there, we've got, we've got loads of cryptography stuff in there as well. We've got some like markdown readings, the common marks specifically as that one.
00:30:17
Speaker
We've got networking things in there. We've got our own Odin network stuff, but we've also got E-Net, if you want to use that, or the GGPO. So GGPO is mainly for games, so that you can have, I'm trying to think, deterministic gameplay across online such. Because that's something I need to roll back as well. So you need to have a rollback deterministic gameplay. So that's a very simple thing that's useful in there. We've got even like, what's it, micro UI, mini audio,
00:30:42
Speaker
We've got a lot of tools in there already, which help you to make graphical applications for your desktop and mobile devices sometimes. Mobile is not officially supported, but some people have been tweaking. Who's using this outside of the company you work for? Quite a few, actually. There's a lot of people who've been using it for tooling. Again, it's mainly for a lot of tooling is a lot of what people are doing in that regard. There'll be some people who don't like profilers and such.
00:31:07
Speaker
comedy called they're doing small making this is a high performance, uh, tracing and profiling application. And it's one of the fastest out there as well, which is pretty interesting. There's some people are using it to make games. There's a lot of people make them nice little games, 3d, 2d, all the range out there.
00:31:22
Speaker
A lot of people just general for tooling and they like doing as a tooling application so they may be at work. It may not be their main product but I've been using like I've been really like just to make tools in it so I can make build scripts or make them like passing tools like that it's just much easier for them. Even though they would've gone I would've gone for python like yeah but python slow in comparison so I still get the high level features but I actually still get the performance in many ways and people that's why they're using it for those reasons.
00:31:46
Speaker
But they're finding it more pleasant than the C-based alternatives. Yes, surprisingly. Yeah. Interesting.
00:31:55
Speaker
If it's a simple and pleasant language to use, there's one particular feature jumped out at me as being very curious for a language that claims to be simple. I want you to justify this for me. Tell me if I've got this wrong. The way you call procedures in Odin, you can use or specify the calling convention, whether it's passed by value or passed by reference. Not exactly.
00:32:24
Speaker
So how do I explain this? So Odin, you can actually specify the calling convention usually. That is necessary when you're dealing with foreign code in general. The calling convention could be C. It could be the standard calling convention, which is Pascal-like on Windows. It could be more fast call. There's multiple different calling conventions. If you know low-level C, you know different calling conventions. But the thing you're referring to here is more of how those certain calling conventions define things. So in C specifically, C passes everything by value.
00:32:53
Speaker
So what this means is if you pass a integer, depending on the calling convention, this is usually passed as a register. But if it's big enough, what will happen is the stack will copy it and pass it through there. So it takes a copy, it passes it on the stack, and it has a copy. So you've got a thing like that. The problem is, in CC programmers are so used to knowing this, they go like, OK, we're going to have to pass it by pointer, because this is going to be too big otherwise. Otherwise, I'm going to blow out the stack or something like that. It's not going to be fast. And it will mark it as const as well to notice this is an input only parameter.
00:33:24
Speaker
And that's usually what's really common in C. And in C++, many people do the same thing. They use a cont reference explicitly and say, I won't do this. But there's a problem. A lot of the time, people either forget to do this or they overdo it.
00:33:37
Speaker
And it's very hard to do. So when you're passing something in, you kind of want to say, look, this is an input parameter, but I actually want it just be like, do which is ever the most efficient way of doing things effectively. Like that's what most people would write intuitively, surprisingly, even though that many people say, no, I want it to be, I want it to always be the same. Obviously, I want it to be like, you don't write code like that. People don't. They actually write it as a pass by point or pass by reference, even if this causes a listing issues in the future.
00:34:04
Speaker
So that's the thing is that is a fundamental problem, but it exists in those languages because of the, it's not even the implicit, it's just the explicitness of doing it. And people just forget there's aliasing happening. So what Odin's kind of done is kind of codified those general conventions that most people do. So if the structure is too big to be passed in registers,
00:34:21
Speaker
it will just pass it internally as a pointer, a reference whenever we call it. But one of the benefits of Odin is all of the procedure parameters in Odin are immutable. So you can't take the pointer of them, you can't reassign them in a sense. If you want an explicit copy, you have to do an explicit copy onto the stack.
00:34:38
Speaker
So it's more of a, we're making those general conventions that most programmers in this domain would have done anyway, and make an explicit. And implicit in that regard, so implicit. And it's just one of those that you do get a lot of benefits. Yes, I'm being obvious, honest here, there are sometimes aliasing issues, but empirically speaking, those aliasing issues even exist if it was explicit. They're the same problem. It's nothing to do with the implicitness or explicitness. It's just due to what people write, effectively.
00:35:06
Speaker
And unfortunately, there's not really much way to prevent this unless you add more complications to the language. Rust gets around this by having ownership semantics. But we didn't want to go that far down the substructural type system route. Right. So you're staying within normal C. Yes. Just trying to codify what's evolved as a convention in the language. Correct. Yes. That makes sense. That makes sense.
00:35:31
Speaker
So you touched on this briefly. I think we should dig into this a bit more, calling foreign code. Yes. So can I call C code from Odin? Can I call Odin? Yeah, absolutely fine. And vice versa, you can call Odin code from C. So that is very easy. The foreign import system, the foreign system in general, Odin, it understands C in that sense. But the thing is, you cannot say,
00:35:55
Speaker
It knows what the C calling convention is, so you can define the foreign blocks, you can define the signatures in there, whatever you're deforming, and it will actually understand and call it. Because that's just what the linker does. At the end of the day, you're just linking code together. And as long as they know their name, the symbol names, and the calling convention, you can call between C and O, no problem. Like that.
00:36:14
Speaker
The thing about Odin as well, in our foreign system as well, when you import a foreign library, you actually say which libraries you're importing, like the .lib, or the .dll, or the .ls, or whatever it is, and you actually link and say, hey, these foreign import names and stuff like this, they're associated with this import thing. That's what it is. This foreign procedure is associated with these import symbols. So if you don't use that foreign symbol,
00:36:36
Speaker
those things don't get linked against. But if you do use it, then it automatically link against what you need. So it has something which in C people may know as an extension, which is like pragma lib, which is one of those old extensions. This is kind of kind of codification of that. And also, not just making it always link, it links only when you need it and use it like natural tree shaking. Pretty much yes. Yeah. That's nice. That's nice.
00:37:02
Speaker
If we're getting into pragmas, this raises another thing you say on the website, which is no, I'm going to quote this specifically, no bad preprocessors. Yes. That's a very judgmental statement. I assume you're saying that the macro system is bad in C.
00:37:22
Speaker
Yes, so C's macro system is textual based. It's the best way of putting it. And as a result, everything about the language is kind of based around that. People always forget that the preprocessor is technically a separate language. You could use the C preprocessor in many other things, languages on top of it. You could even use it in Python if you wanted. I would not recommend this whatsoever, but you could.
00:37:44
Speaker
And that's kind of the thing. So you've got things like when you include a file, actually what's happening in C when you include a file is it pretends that these files are the same, you're actually including it as one giant file. So in that sense, that's what's going on. But there's a lot of issues with it because it's textual has not a lot of safety. Now, I know you're a bit of a lisp guy yourself. So you're more close to these more hygienic macros and such like that, where they're working on the AST level in that regard.
00:38:08
Speaker
which is not necessarily a preprocessor in many ways, because it's technically part of the same language, but sometimes they can be conceived that way. You could design a preprocessor that works on the AST level, modifies the code at the AST level, and then goes back again. Now, Odin, we don't have a preprocessor whatsoever as part of the language, because we've not actually required it, surprisingly.
00:38:29
Speaker
you'd be surprised how if you actually do the things that people did in C with the preprocessor and actually just codify them as things, actual constructs, you'd be surprised how little you actually require something like a macro system to begin with. And the more and more you do that, you realize, yeah, we don't need a preprocessor, let alone a bad one anymore.
00:38:51
Speaker
Okay, so does the phrase no bad preprocessor mean we've thrown out the bad preprocessor but we're still open to adding one if need be? We probably won't ever add one ever again. If you want to add your own on top, you can. But one of the reasons why there won't be a preprocessor for owning is because we've got everything's out of order in owning how it compiles.
00:39:09
Speaker
So in C everything's top down you go from the top to the bottom and the grammar of C requires this. For Odin, it's effectively you pass files but each file gets passed into different threads, it's completely out of order, so it's a context-free grammar in that regard.
00:39:24
Speaker
And when you do all this, it means that you can actually, and then everything gets type checked out of order. So a preprocessor in that regard would, unfortunately, linearize and make it in order if you did that on top. Now, sometimes it is useful to have a generator, like some code generation. But I just write that in Oden to generate the code. If I've got some really complex table, I don't need to have a preprocessor per se as part of the language. I can just add a tool. Usually, most of the time, they're just one-offs. You just write the code, it's done.
00:39:52
Speaker
And that's what I found most of the time over my life in Korea in general, most people have as well. Right. So instead of doing things at compile time, you just have a separate file phase. Yes. But you say that we have separate files, but literally usually gets ran once and never again in practice. And that's the thing. It's like in practice, that's what the case is. Okay. So
00:40:17
Speaker
If we're talking about compiling and the parallel compilation, we should talk about compilation speed and platforms that it's supported on. So starting with platforms, Odin is officially supports Windows, Mac, Linux,
00:40:35
Speaker
numerous of the BSD ones like free BSD, OpenUSD, whatever, stuff like that. We also support Wasm as a target as well, in that regard. But also, as long as the operating systems we also support, it's AMD64, so that's Intel x64, x8664, whatever you call it, AMD64 is what we'll call it. There's ARM64, which is again what the new Macs are using as well, we support that. And we
00:41:00
Speaker
I think that's what we only support officially at the moment anyway. We could support more targets, but that pretty much covers 99.99% of use cases for most people is AMD64, ARM64, and Wasm. That's quite a lot, though. Yeah. That's quite a wide arc for a relatively young language. Well, that was one of my main goals when I made the language. I wanted those specific targets. I wanted Mac Linux and Windows, and AMD64 and ARM64.
00:41:29
Speaker
And a lot of new languages out there at the moment don't usually focus on Windows at all. They really don't care. They're really very much the Linux Mac focus. And I'm like, but I work on Windows a lot all the time. That's how I make my job. I do make Windows applications mostly. So it's kind of like why most of them are kind of ignoring that. And when they do add it, it's more of a second thought usually. When I developed it, everyone's always been on Windows. It's always kind of been like, be polished. Make sure it works on Windows, because when you port to Linux Mac, it's easier than going the other way around, if you know what I mean.
00:41:58
Speaker
I can believe that, yeah. Because when you're on Windows, you know what doesn't exist. Put it that way. Like when you're on Mac or Linux, you know, the POSIX stuff. I see my POSIX and you go to Windows like, what's POSIX?
00:42:10
Speaker
So you don't always assume those libraries exist. As for the compilation speed, so there's different parts of the language in that. So you'd call it the front end and the back end. Usually people have this. So the front end is the tokenizer, the parser, the semantic checker, kind of that stuff. That part of the language is pretty damn fast because the language I designed it to be fast in that regard. So I try to do all of that and
00:42:37
Speaker
That's good, but the problem is our backend, currently at least, is LLVM. And LLVM is very, very slow, even when you're doing development builds. And it takes about over 90% of the entire compile time is LLVM. And we've tried our best to even make it faster as well. Problem is LLVM is slow inherently. And to try and multithread LLVM is not easy either, because it doesn't really want to be multithreaded. The only way you have to multithread it is you have to do a lot of tricks.
00:43:08
Speaker
And most of them aren't even documented well, because there's virtually nothing documented well in OVM. But let's not go into that rant, shall we? But that's the kind of thing. So the Odin itself, it should be intrinsically fast to compile. There is nothing like it should be as fast as you can get. Because again, it's been designed to be very multithreadable.
00:43:24
Speaker
Like even the language when I designed the semantics, I said that on average, my heuristic was that most of the time when you're doing semantic checking is spent within procedure bodies. So, okay, I'll design the language so that I can compile all the procedure bodies out of order and multi-threadable. Right, okay. That heuristic seems to be true even to this day, so I made a good decision now in regards. There are some bits where if it isn't the case, then clearly it becomes kind of more single-threaded.
00:43:53
Speaker
If everything's just like big data structures, like if 99% of your code is data structures and there's no procedure bodies, then it will be more single-threaded. But that's just kind of how I designed the language. The last thing is I was designing a language, knowing how modern hardware worked. I tried to design it around that as well. Not just saying, oh, we'll try and just make it fast and make it a really fast single-pass compiler like the old Pascal compilers. I'm like, yes, that'll get you so far, but how can we expand this and go further?
00:44:18
Speaker
Again, this is modern programming has moved on and most code bases are a lot of different files, right? Pretty much. Yeah, you'll have hundreds, hundreds of thousands some people have. And it's not just one big file or small things anymore. And it's not even that, it's that we have threading now. We have multiple calls on our machines. Most people have at least four.
00:44:39
Speaker
Even my phone has like four cores on it, which is when you think about, wait a minute, my phone is more powerful than my machine from like 15 years ago, which is crazy to think about, but it's true. Yeah. Yeah. Moore's law in action. Yeah. Yeah. But yeah, so it does make sense, put it that way, that we should be designing our programming languages to take advantage of the CPU. Yes. The de facto CPU layout of today. Pretty much yes.
00:45:07
Speaker
This is slightly harking back to an earlier question, but I've just thought, we've been talking so much about CPUs. Do you target GPUs as well? No. And half of the reason as to that is GPUs are not as general purpose as a CPU is, obviously. They're very more specific in what they do.
00:45:27
Speaker
And for a GPU, there's two different types of things you can run on a GPU. There's one that's shaders. Pretty much everything's a shader on a GPU, really. But most of the type of shaders you're doing would be like someone's like GLSL, or the Direct 3's HLSL, the metal one, or whatever. And you do it through there. So you do like the pixel shaders, the fragment shade, or the same thing, sorry, pixel shaders, or the vertex shaders, or the compute shaders, and such like that. There are other languages such as like OpenCel, and the CUDA, and all that a lot, which try to be a bit more general and make these
00:45:56
Speaker
kind of like kernel shaders, in a sense. But the thing is, it's a very more different environment. Like how the GPU works is not the same as how the CPU works. So in my personal opinion, I wouldn't want to try and design a language to be the same across both. I'd rather be, for instance, like at Jenga Effects, we technically have our own shading language, which compiles down to either GLSL or Metal, depending on which platform we're on.
00:46:23
Speaker
But it's very much like we've designed it, so it is for the GPU, so it models all of their specific memory models as well. For instance, atomics works different, obviously. So you have to deal with how those things work on those
00:46:36
Speaker
Again, those types of machines. So if you try to have a unification between the two, it doesn't really help.
Future Outlook and Core Features
00:46:43
Speaker
Now, many people just want the same syntax, which is like, okay, syntax, whatever. But the semantics have to be really different. And there probably will be a point in the future, hopefully, where the two will merge.
00:46:55
Speaker
And again, with the Apple stuff, what they're doing with their system on a chip, they're slowly getting that way. So eventually, there might be a unified language that'll be able to work on both CPU and GPU. But we're not there yet. And I'd rather see it first and then develop for that, rather than like, I'm going to design it and hopefully this will work in the future. I'm like, I don't know the future. If I did, I'd be a millionaire.
00:47:20
Speaker
Or you despair about the state of the world. Yes, that's another thing. It's probably either going to hell or heaven. I'm not sure which. So again, you're waiting for the hard way to tell you what to do. Pretty much, yes. Because I don't think... How do I put this? The languages of today aren't going to be the languages of the future necessarily. C will probably be... C has been around for 50 years. I'm expecting there's going to be another 50 years of C.
00:47:47
Speaker
that it's not going to be the only language. And I don't know what the new languages are going to be like. They're probably going to be very similar to what we have today, but they'll be more tailored, hopefully, to the hardware. Yeah, I can see them being quite similar because I think the slowest part of the system that changes most slowly is actually us programmers. Yeah. Well, the other thing is also there's only a few different computational paradigms anyway.
00:48:11
Speaker
The C tradition is based on the von Neumann idea, like von Neumann architecture, which nowadays modern machines are modified Cambridge, technically speaking, but that's still of that tradition. But then there's also the ML languages, that's still just like, what's it called? What's the ML family? It's church.
00:48:31
Speaker
whatever it is, I can never remember names of people. But there's different computation models. But as you look at the computation models, there's usually like a family of language around that model. Like there's the fourths, there's the MLs, there's the C and the Pascals, which I'd call the ALGOLs technically speaking, that's the ALGOL family. And then you'd probably, who else is on that list? You got the lists as well. Like the small talks of the world.
00:48:51
Speaker
Those are really actually part of the alcohol family at the end of the day. Yeah, they're just a bit more extended. They've still got the same kind of memory model as the alcohols in many ways. Usually, I know there's exceptions to that rule. But that's pretty much the families do kind of bundle that. So in the future, I'm expecting unless they figured out a new computational model, the language would look about the same. 2030 would be the decade of Prolog on the desktop.
00:49:18
Speaker
Probably not. Probably not. It'd be interesting to see a data or a data language anywhere like that, but yeah. I'm sure this line might be actually because of what Unreal is doing with their language, which is technically just prologue with different syntax. I've not heard of it. Yeah, I can't remember what it's called. Unreal's got their own little scripting language now, and it's effectively a prologue. It's curious. Why? I think it's just because they want to have a lot of constraint-based stuff, so they want to...
00:49:47
Speaker
Like, you've got these constraints within games and such. That's the thing that they think is a better way of explaining things, rather than more of a procedural way. I think that's what they do. I can't remember the name of the language. Someone told me in the description, like, is this one? Sorry, I just names. I forget them all the time. I'll research it and stick it in the show notes. Maybe find a few guests to talk about it. That sounds cool. There you go.
00:50:07
Speaker
There was one other thing on my tick list, the things I definitely wanted to talk to you about, was your core data types. So we've talked a bit about arrays, but you've got like matrix and complex number as a core data type. Yes. We even have quaternions as well, by the way, yes. So we have complex numbers, quaternions, matrices, array programming in general. So the reason as to that is it is pragmatic.
00:50:29
Speaker
So the complex numbers and quaternions are there just because, again, I do a lot of 3D stuff. And it's useful to just have them in. But also the one reason is Odin doesn't have operator overloading. So as a result, we don't have operator overloading. I thought, OK, what is the 99% overlap that can get most people happy without operator overloading? OK, just do that.
00:50:52
Speaker
rather than trying to make it as generalized as possible. The problem with operator loading, I have seen a lot of horrors with it. I'm having a lot of horrors. And it's one of those where it's a slippery slope when you add it as a feature into a language. And it's very much like I drew a hard line and went, no, we're not going down that route, no matter how much. I know there are uses for it.
00:51:13
Speaker
And but even like most uses, most of the time, it fits into two categories. The first one is the mathematics. Well, we have all that now you're pretty much everyone's pretty much happy. That's why I've got the matrices, the Raper and the Quaternions. That's all in there. Most people are happy. They don't even need to worry anymore. The other side is the data structures. Well, you know, and we have built data structures like we have actual string type on like say we have array types, proper array types, we have even a basic hash map built, say basics are heavily optimized. But yeah, with SOA data structures inside. But yeah, it's what pretty much like
00:51:43
Speaker
We've got the basic data that most people want, 99.9% of the time, if not higher than that. And if they do need something more complex, personally, I don't mind just calling some functions from time to time, because it's not like I need it to be a syntax level thing for those things. If I've got a red-black tree, I don't really need syntax for that, because it's only in very specific cases where I need one of those data structures.
00:52:04
Speaker
Yeah, I'd agree. I think a lot of the time it's just laziness of typing, I think. I really have to type five letters rather than one symbol. Which makes me laugh because it's like, do you know what your profession is, right? Yeah. Because if you're optimising for typing, you're in the wrong job, in my opinion. I know you shouldn't be writing loads of stuff. Yes, I understand writing loads can be annoying, like redundant stuff. But just trying to reduce like, oh, instead of writing five characters, I can write two.
00:52:33
Speaker
Really? But so many people want that. And it's kind of a, think about just kind of, you need a bit more self-reflection in some basis for something. It's like, oh, for the sake. There is a balance to be struck between a single character, Glyphs, and the abstract proxy factory bean instance. Yeah, I do write long function names, but they're usually very, very descriptive. So like, oh, this thing does that thing. And it's just usually kind of nearly in English. But it's easy to read. The thing is, most of the time, you're reading code. You're not writing it.
00:53:03
Speaker
So why are you optimizing for the writing? When it sounds like you're writing, write once, never be able to read by anyone else. Again, we have a team of nearly a dozen programmers. So we kind of have to write code that other people can read. And a lot of Odin's stuff within the language has actually helped us make it more readable. Just because of the constructs kind of force you to kind of like, yeah, you know what, we're going to have to be readable in this regard.
00:53:25
Speaker
This makes me think one day we should do a podcast episode where we get all the different language designers we've had in to judge each other's code. Oh, that's great, yeah. That would be great fun. So we've talked about what's in Odin. Is there anything that's missing? Anything you'd like to add or anything you think someone would say, oh, Odin doesn't have X and maybe I should stay away?
00:53:49
Speaker
There's nothing I actually want to add to Odin at the moment anymore. Or if there is, it's very much I've chosen still not to add it because there's other like trade-offs you have to deal with. But one thing like many people ask sometimes, oh, is there any methods in Odin? Like, nope, Odin does not have any methods. It's just standalone functions everywhere. And it's like, oh, why am I? It's very much a, I'm not saying against object-oriented programming, it's just,
00:54:15
Speaker
I'm not going to do the C++ style one if I did it. And also, it's a rabbit hole of a feature. If you want to go down it, I might not say I want to do the exact same semantics, but one way Go does it is I quite like the implicit interfaces. But I wouldn't go down that route because it is a rabbit hole of a feature. Once you do it,
00:54:33
Speaker
No, no, no, no, no, no, not worth it. It's kind of a, you start then bifurcating language into multiple dialects. This is the problem. When people start asking for features, they start asking, they're effectively asking for dialects. And I'm like, that's, I've already come from C++ where this is a huge problem. So I didn't want to have to introduce that into my language already. Like I know there's going to be dialects, but I kind of want to minimize them as much as possible by just not having so many options.
00:55:00
Speaker
Yeah, yeah. It makes me think of, you know, Java, they say everything's an object. I don't necessarily agree that everything should be modeled as an object. If you're going to have a language that treats nearly everything as an object.
00:55:14
Speaker
then it probably is better to have everything being an object. You just have one paradigm, right? Like if you're going like a functional thing, everything's a function. Like Haskell, pretty much everything is a function. But in Odin, not everything is something. There are very distinct categories of what things are. Not everything is the same thing.
00:55:31
Speaker
And that's a very common thing in the imperative procedural tradition anyway. Some things are different things. There's not like a unifying principle. It's very much like a lot of those kinds of unifying principles are mathematically nice, but practically don't help you at all.
00:55:48
Speaker
I would say that pretty much everything is either data or a transformation of data. That's my way of thinking. Yeah. Yeah. That's the Nicholas Siviat one. It was one of my favorite books I always recommend from beginners. It's not in print anymore, but you can get the PDF for free. It was data structures plus algorithms equals programs.
00:56:07
Speaker
And it's a lovely way, it's a good book, but it's a really nice way of thinking about things for most people, because it's technically a wrong model of thinking, because it isn't technically correct, but it is very useful. Like most things are just thinking of the data and the data structures and the algorithms and how they operate together. What do you think's missing from that? Why is it not technically correct? Technically wrong. Technically, data structures are actually things that encode an algorithm already implicitly.
00:56:34
Speaker
Because they do have an algorithm when you use that data structure. It's just implicit. It's not made explicit. OK. Yeah, yeah. Yeah, yeah. So that is technically the case. But what I'm saying is it's a good idea to think of that distinction usually. It's very practical. Yeah. Yeah. I can see that that's particularly true when you think of something like a red-black tree, right? Yes. Because a red-black tree is an explicit data structure. But it has algorithms about how it works, obviously. Absolutely. Yeah. Encapsulation back again. Yes, back again. OK.
Getting Started with Odin
00:57:03
Speaker
If someone wants to try out Odin, how do they get started? Oh, the easiest thing is just go on to the odinlang.org website and you can download it and such, no problem. And you can just give it a go. It's pretty easy to download, pretty simple, small executables. If you're on Mac or Linux, just follow the instructions. Mac, Linux, Windows, there's instructions on how to install it. And you should be getting going pretty quickly, actually. What's a good starter project? Where would you kick off?
00:57:28
Speaker
It depends on what you want to do. It's like how long is a piece of string, really? If you want to make games, we've got Raylib built into the language, so you could probably try the Raylib library and try and do it that way. It's another good thing. If you want to do a little networking thing, you could probably just use the networking things with TCP or something like that and make your own, I don't know, web socket thing. I don't know. Just make something up that you want to try a language to get a feel of it.
00:57:50
Speaker
I recommend this for anyone who's trying out any new language, be it Odin or any other language, try it out for at least over a week and I mean properly make stuff in it to get a feel of what you like or dislike about that language. Because you might not like Odin, you may love Odin, but you don't know until you try, obviously. And I recommend people do that with as much as they can. If you've got the option to actually choose a new language, try them all out as you can.
00:58:12
Speaker
Yeah, yeah, and give them a proper try. Don't just bounce. Yeah, exactly. I don't just like look at it and go, well, it doesn't seem right. I'm like, try it out. Don't just read this like the overview. You'll get a different feel sometimes. Well, I hope from listening to this, a few people are tempted to give it a proper kick of the tires. As do I. Groovy. Bill, thanks very much for joining us. No, thank you very much, Chris. Anyway, see you again. See you. Bye.
00:58:36
Speaker
Cheers, Bill. As usual, you'll find links to all the things we referenced in the show notes. There's a link to Odin's homepage, of course, and its package library. I always like when I'm checking out a new programming language, I always like to see which libraries are already available, gives you a sense of how mature it is, what people are using it for all that. And the one that Bill mentioned, Raylib does look really interesting.
00:59:02
Speaker
If you're ever doing like a game jam or just playing around with implementing games, might be a fun one to take a look at.
00:59:09
Speaker
Oh, and if you're wondering, I did look up the logic programming prologish language that Bill mentioned. It's called verse, and I'm pretty sure we're going to be having an episode on verse before long as well. That's almost all for this week, but before you go, please take a moment to like, subscribe, rate, share with a friend, and generally, you know, feedback if you've enjoyed this episode.
00:59:34
Speaker
We'll be back next week with another, so until then, I've been your host, Chris Jenkins. This has been Developer Voices with Ginger Bill Hall. Thanks for listening.