Interview with Odin language creator gingerBill

Odin site: odin-lang.org/
Demo code: github.com/contextfreecode/od...
0:00 Intro & demo
1:48 Bill intro
2:03 Odin history
2:40 Pascal connections
3:27 Joy of programming
4:21 Niche among C alternatives
5:17 Procedures and functions
6:42 Error handling
8:06 Int sizes
9:33 Curated vendor libraries
11:46 Runtime type information / reflection
12:57 Generics / parametric polymorphism
14:48 Null pointers
17:01 Implicit context system
19:36 Software written in Odin
20:27 Plan for 1.0
21:20 Closing words

[@contextfree]

Thanks much to Bill for the interview! And if you liked the video, be sure to subscribe. See also: gingerbill.org odin-lang.org

[@GingerGames]

Thank you very much for having me on. It was a pleasure :)

[@MagpieMcGraw]

Odin is my favorite "betterC" language. And the only one that just worked when I downloaded it. It's very much like C, but replaces all the annoying syntax with clean and convenient syntax. It's greatest strength is that it us practical. It's not made to explore programming language theory, it's made to do things. So there's usually a convenient and sensible way to do the obvious things you want to do as a programmer.

[@rudde7251]

How did you not get Zig to work? I'm usually sensitive to a lot of manual setup and find mainstream languages like Go a fucking hellhole to get going, but I was just surprised how straight forward that was to get working.

[@MagpieMcGraw]

@@rudde7251 I downloaded, I wrote or copied some simple zig code, and it wouldn't compile. I think it was giving me an llvm error, can't exactly remember. I didn't bother troubleshooting it.

[@valeriovergni3339]

@@equinox2584 rust is not a "betterC" language, it's more like a "betterC++" language

[@stevenhe3462]

@@valeriovergni3339 I think Rust is not really a better what. It is unique. No other language I've seen has done this crazy ownership system.

[@Casilios]

Ironically, it's the only compiler I couldn't get to work till this day...

[@michaellee2786]

I’ve had the privilege of using Odin for the past month or so, it is shockingly robust for not having reached 1.0. The compiler gives good suggestions in the face of typos, it has some rough edges in this regard as well, however it has been absolutely usable- and I’m no genius. I have loved using Odin, and I hope it’s simplicity (borderline minimalism) allows it to stay in use for years to come.

[@q_rsqrt5140]

With increasing number of interviews, maybe official interview playlist?

[@contextfree]

Granted! kzbin.info/www/bejne/q6CbmoGch6d4qKs

[@gideonunger7284]

I always love Bills insights. Everything he does is very well reasoned even if he then ends up at surprising places. I was quite skeptical of Odin not having the concept of const for example but after talking to him about it i think it makes perfect sense for the domain that Odin is made for.

[@victornoagbodji]

The or_return construct is very welcome! I had a discussion a while ago with C programmers (most were I think) about an early exit construct that would return an error value on an error condition. I think I called it return_unless. Of course nobody wanted it and they wanted me to write the if statement that checks for error and returns the error value. I am happy to see that concept implemented in Odin 😊

[@kcvinu]

After one year I came again and watched once more. Now, I got the one point I missed last time. You can pass a pointer through context !!!

[@cc.jsullivan]

the vendor: namespace prefix is a brilliant idea, kinda like how zig bundles a C compiler you can use to load source- or header-available C libraries into your project directly. However, this method is kinda like having a higher-level standard library like python does with their HTTP client or TCL package. Very nice stuff!

[@AbhinavKulshreshtha]

Great interview. Not only I learned about a new programming language, but also got an insight on how and why a programmer creates a new languages. The thought processes that goes into planning which features will go into the language or how language internal works. What he said about package managers is absolutely correct. The dependency hell in javascript left a bad taste in my mouth after the whole left-pad situation. Package management must be built into the language ecosystem itself, not an after thought.

[@Elite7555]

You mean like in Go? Yeah, that works so great... And also, how does that prevent packages from being removed? And how does not using package management resolve dependency hell?

[@kodosunofficial]

Odin is very readable language, i can easily read odin code and understand what it does, because the syntax have much less noise.

[@Antonio-yy2ec]

What a great language! Pretty neat, that in-line assembly feature sounds amazing, hope you could make another video about using it once it is released

[@asandax6]

I can see it now 10 years minimum experience with Odin on Junior Entry Level job postings

[@johnhammer8668]

Love the format of showing links in the background. Thanks for putting so much effort

[@NOPerative]

Odin has come long way. Excellent vid.

[@enkiimuto1041]

Nice, thank you for making this interview.

[@zakariachahboun]

Thanks for this interview 😊

[@LivingInLowLevel]

This is amazing now I love this language

[@BryanChance]

Odin is my favorite modern language. Here are the reasons. 1. The syntax is simple, clean, sensible, familiar. 2. Use common names like function, procedure, class, etc. Instead of "func","fun", "def", "fn". 3. using Curly braces. Unlike others who use white space and indentation as part of the syntax is just stupid. 4. Better than Rust..ok much easier than Rust. 5. As powerful as Rust 6 Full-featute and flexible.

[@bandaloo7776]

swizzling in a general purpose programming language is so cool to see

[@xealit]

exceptions fit well in asynchronous situations and execution contexts. For example, if your code runs in a context with an open connection to some server over the network. The network connection can randomly break, therefore every line of your program can generate an exception.

[@porky1118]

14:38 I don't agree about generics. I use it pretty often. I sometimes make a whole library, for example collision detection or physics, generic over the scalar type, so I can have smaller types (f32), more accurate types (f64) or some more consistent type (fixed point numbers).

[@GingerGames]

This might sound like a weird question but why do you have such a generic physics library to begin with? That cannot be well optimized nor that useful in practice for any specific problem. If your problem requires high precision, then you either going to be using `f64` everywhere or a form of fixed point numbers (if performance is not a concern). But if you care about performance but not so much about precision, then `f32` would be used everywhere. Making it generic means you are not solving any specific problem. This is my main issue with defaulting to "generics": if you are designing for the "generic case" you are not NEVER developing for any specific case, which implies you are probably not solving any particular problem that you have at the moment. This doesn't mean that the general idea of having an interchangeable backing type is a bad idea but rather not necessarily a good idea. And you example is a brilliant case of NOT requiring generics and just requiring condition compilation. I'd bet good money that you are NOT needing different instantiations of your library with different types within the same project.

[@porky1118]

@@GingerGames Maybe not in the same project. But I don't want to rewrite my lib every time I start a new project. And even in the same project, I want to be able to easily switch the generic type for increased accuracy or performance. So even if I'd write a non generic physics lib, it would be useful to have a type alias at the beginning. The API wouldn't change besides of the generic type. And if the language is powerful enough, it will allow optimization for the special cases, too.

[@GingerGames]

@@porky1118 if it's just one base type, why not typedef it and then change it per project? Either by copy and paste or conditional compilation.

[@porky1118]

​@@GingerGames A "type alias" is a "typedef". This already would be some kind of generic physics library. In this case, the whole library is generic. That's probably better than having to specify generics on every type separately. But it's more comfortable to me if there is a standardized way to use some library without having to modify it manually. So it would be the conditional compilation method, but this does not work the way I want in Rust.

[@GingerGames]

@@porky1118 in the context of the video, I did say I use generics in the sense of parametric polymorphism. But if you want conditional compilation for your library, that's fine and not necessarily classed as "generics".

[@DrunkenUFOPilot]

Thanks!

[@BraxtonMeyer]

holy shit, you're alive

[@peterhelpme]

How much better is it than Delphi?

[@mendelovitch]

Do I have to be a viking in order to use Odin?

[@contextfree]

Maybe not this time. I think the Futhark programming language is also allowed for non-Vikings.

[@GingerGames]

There's only one way to find out😉

[@Intermernet]

@@GingerGames I tried writing a garbage collector for Odin and two bloody ravens flew in and told me to get off their turf.

[@ahmaddynugroho]

Interesting

[@victornoagbodji]

Is the demo code using OpenGL 3? 🤔

[@contextfree]

Since I didn't write it myself (only tweaked it slightly), I didn't look closely. But here are the bindings: github.com/odin-lang/Odin/tree/master/vendor/OpenGL and here is the demo code itself: github.com/contextfreecode/odin-demo/blob/main/demo.odin

[@victornoagbodji]

@@contextfree Thanks!

[@MrUserasd]

I don't really understand what was the point on package management. So basically Odin users are stuck with what language creator put in vendor/, all the other things they should reinvent independently, right? Because no one else could be trusted to reliably create good enough package.

[@GingerGames]

There is a bit of a misunderstanding here. I am not against third party packages, far from it, but rather the system in which you acquire them---a package manager. Odin does provide numerous different packages as part of its core and vendor library collections, but of course there will be more that you will need. Package managers hide _accidental_ dependencies and make them easier to accumulate. n.b. I know that this is a **controversial opinion**. Because of the concept of a package is well defined within Odin, this means that making a package manager is trivial, but the point I was making is that there will not be an _official_ package manager because I do not want to encourage the numerous issues that they incur by default. They sound like a good idea but they just make it easier to add more and more complexity and dependencies to your project! The things you want to encourage should be made easier but the things which should be discouraged should be made harder to do (not necessarily impossible).

[@MrUserasd]

@@GingerGames Thank you for clarifying. That approach is not to my liking, but I'm not a game developer anyway (just trying it as a hobby), and area of programming here might be important. What is usual and crucial in e.g. webdev not neccessarily should be implemented in the same manner elsewhere.

[@jabuci]

Where does Bill live? Where is he from?

[@GingerGames]

Why does that matter?

[@navjotsingh2251]

@@GingerGames haha, he’s gonna track you down 😂 just joking…I hope he doesn’t find you bill

[@nested9301]

iwill say it : odin sama

[@Jaqu3Mate]

Basically the only reason I don't use odin is because of the lack of a package manager. I'm sorry, I love my cargo add, go get, v install, npm i, pip install...

[@yuirio8228]

Okay, from the demo it looks a lot like Golang

[@contextfree]

Personally, I'd say Odin is a systems language, and Go is more focused on network services. GC or not matters. Other differences include that Odin has had generics for quite some time. And lots of other differences, too.

[@gideonunger7284]

@@contextfree i guess its fair to say that go was an inspiration for some aspects of odin. but there are quite a few other sources as well.

[@kim15742]

For me it looks a lot like Jai and it has the same philosophies as Jai. As such I'm surprised Jai was not once mentioned in here

[@Elite7555]

I heavily disagree on his points against package management. Even if you write all the code yourself, you still want to use a package manager. And if you use third-party libraries, well, what are you going to do about their dependencies? Isn't the package manager's fault they depend on other libraries. If you really need to assess their code quality, then do. But even to do that a package manager is useful; for example, to run a code analyzer on them.

[@AdroSlice]

Gives me JAI vibes

[@contextfree]

github.com/odin-lang/Odin/wiki/Odin-vs-Jai

[@astphaire]

Reminds me of Jai

[@contextfree]

See here for some compare and contrast: github.com/odin-lang/Odin/wiki/Odin-vs-Jai

[@austinmajeski9427]

15:06 No, null pointers are the hardest to find. You often have to find the thinnest edge-case that creates it, which takes time and analysis - IF you catch it after it has crashed your program.

[@marcs9451]

The fact that your program crashes is great, compared to dangling or out of bounds pointers which often lead to unexpected behavior, null is very easy to diagnose and inspect.

[@churchianity]

​@@marcs9451 Yeah, saying null pointer issues are hard to find just means you probably haven't dealt with a lot of memory overruns :P

[@cedricvillani8502]

Ginger Bill what’s up with the beautification?

[@GingerGames]

I'm not sure I understand the question.

[@cedricvillani8502]

@@GingerGames on your zoom call unless I’m mistaken, I am on a phone after all. I remember pascal in 10th grade, first time I saw a high level language

[@GingerGames]

@@cedricvillani8502 I still don't get your initial question regarding "beautification" and the context of that.

[@ArtemKharytoniuk]

the language should be called "minor jai inspiration", when abbreviated MJI looks pretty good

[@TheMrKeksLp]

I don't really agree with him on nullable pointers being fine. Null pointer errors might be not that hard to fix, but they're still a hassle if they happen 10 minutes into the applications lifetime on a customers computer. And really all you're doing is introducing potentially invalid states to your program. Because now every pointer might be a valid value OR it might be null. Do you want to add a null check everywhere you are about to deref a pointer? I don't, and even if you do, now you have to deal with the case of it being null when you really didn't expect or want it to be null which needlessly complicates control flow and logic. IMO non nullable pointers are such an easy feature to add to a language that the cost of doing so far, far outweighs any other consideration. They have no downsides and let programmers be at ease that their function isn't potentially broken in ten different ways if used incorrectly, something that always bothered me when I programmed in Java

[@marcs9451]

It's not an easy feature at all, you have to create a whole reference system on top of that. it is much better to get a null pointer error than to use an invalid pointer that does not cause the program to crash and results in security and integrity issues.

[@_slier]

kinda love the lang..but geez, colon galore..i blame on u pascal.. and why struct dont have method on it :(

[@cedricvillani8502]

Housekeeping() lol something script kiddies don’t know but a EE vs a CS student isn’t as separate as we used to be, you could tell a CS and EE student by the way they pronounced Linux

[@GingerGames]

What are you even on about?

[@Pspet]

It is embarrassingly obvious how much of a clone of Jai these new languages like Odin and Zig are.

[@contextfree]

github.com/odin-lang/Odin/wiki/Odin-vs-Jai

[@GingerGames]

Jon Blow's language talk was a minor inspiration, and thus his language Jai, of which I am quite open about. I have found that the main reason people compare the two languages is purely regarding the similarity of the declaration syntax. From a semantic standpoint, they are quite different (Jai being very C++ like, and Odin being more Pascal/Go like). I do get regularly asked about it so I have produced a minor table for people to understand the differences at a glance. The declaration syntax is similar to Jai's but Blow didn't invented it, and in fact took it from Sean Barrett. And with a little research, you can find that it was Rob Pike who first invented that syntax back in the early '90s for Newsqueak and Limbo. Some of the similarities that Odin and Jai hold are not unique to either and can be found in earlier languages. `using` is a good example of this in that I was originally going to have `with` from Pascal but seeing how Jon applied that idea to "live variables" was pretty clever. And the uninitialized value `---` syntax is copied from Jai but it turned out to be a life safer in that it saved the declaration syntax for (foreign) procedures literals without a body. I seriously changed the syntax of Odin for a week to a more conventional `proc main()` syntax because I thought the problem was unsolvable until I realized I could reuse this token. Other than that, Odin and Jai are very different languages with very different philosophies behind them.

[@UliTroyo]

And yet Odin and Zig actually exist and you can use them.

[@contextfree]

Yeah, technically Jai exists, but it's vapor to me. I'm glad Andrew and Bill believe in community. (I do intend to try out Jai if/when it gets released and documented someday.)

[@FiveNineO]

Jon is a perfectionist, he won't release it until it's perfect, and it never will be, so he'll never release it.