What do you think it's holding Odin back?

General
1

For real, I’m not trying to start a flamewar, it’s just that I’ve been using Odin lately and I don’t understand why more developers are not using it, specially Go developers. Odin is so close to Go, but at the same time, way faster and with more features/safety.

Lack of visibility control, or at least, no easy visibility control

I found this very useful when building APIs since I can create a bunch of code and just expose what I want the user to use. It may conflict with C goals, and maybe this is why it was not included at the language.

No Immutability

Again, maybe it goes against C way of doing things. But being able to define things const at the runtime is such a good thing because you can be sure that the thing is not being mutated. “Be sure” because it’s always possible to mutate using unsafe operations, even in languages like Rust.

Package Manager

Controversial for sure. I understand Bill’s point of view, but damn, it’s just too hard to know which version you’re using, how to bump the versions, etc… I don’t think something like NPM is ideal, but I believe that the way Go does versioning is pretty good.

It’s a game development language

It’s not, it’s a generic language. But it feels like something tailored for game development, which is not a problem if this is the goal of the language. I feel that all those raylib, sdl, and alike bindings could be on a GitHub repo managed by the odin organization and be easily put at the language, but just being delivered with the language gives this feeling of “game dev language”. For example, why not add database bindings?

Let me say this again. I’m not trying to start a flamewar, I have deep respect for Ginger Bill for putting the effort on creating this language, and I really like Odin. I’m just raising this since I’m still on the path of learning more about Odin and maybe this is just me having a different understanding because I came from higher level languages.

1 Like
2

Lack of visibility control

Why don’t #+private and @(private) achieve your goals?

No Immutability

It’s a false sense of control, propagates all over the code base, clutters up the screen, and as you admit, doesn’t actually do anything.

“why not add database bindings?”

Great question, why haven’t you done that?

3

It depends how you look at it. Odin is very popular in the grand scheme of things, for that reason I guess your question’s sentiment could be something like “why isn’t Odin in the top ~20 most used languages?”

Odin is a C alternative, which means on some level its market is “people who like to use C.” That’s a tricky market to please because:

  1. C programmers have acquired a taste for the minimal toolchain. Odin has an optional library, which is good, but the language has features which seasoned C-devs have already created by their own means.
  2. A busy market; it’s being targeted (I’d argue indirectly) by a slew of new systems-languages. Zig and Rust are very popular, but they sort of “import” developers from other walks of life into this market, if that makes sense. They promise control, safety, and performance for the everyday dev.
  3. The memory-safety craze is detracting various kinds of people from trying/wanting-to-like languages which don’t make safety promises.
  4. Odin is for modern end-user hardware. Odin is far more portable than C for this class of hardware, but C is more portable across all hardware if that makes sense. This means C is genuinely a better choice for some problems.
  5. It’s not the biggest market out there. The web won the popularity contest, but that’s mostly unrelated to Odin. Odin doesn’t concern itself with what the lion’s share of developers want.

Separate from the idea of “marketing” is “promotion.” This may be related to not-having a package manager. When people love a language, and are in the early days like we are, they go mad and write scads of libraries. The libraries build on each other, people advertise their new things so others can build atop of it. This creates a ton of energy, but it also makes a mess. That energy from collaboration ends in a ton of promotion. Odin is taking the measured approach and allowing the friction to collaborate via dependencies to remain. I think this is brilliant, and I absolutely would not have thought to do this as a designer. I love that we aren’t making a mess of low quality libraries which go delinquent in 3 months, despite being heavily used. I love that we are focused on the end-product and not just being “built with Odin.”

Odin is not bought into popular programming culture, and for that reason I think the key to growing Odin is to carefully grow our corner of a more effective programming culture-- as different as it might be.

Bill has a talk and a blog post which get into this topic as well.

3 Likes
4

i use it almost daily in some personal projects but i personally hate the directory = package thing

i want to be able to arrange my files however (in different subdirectories) and not have to maintain some kind of a “strict acyclic dependency graph” about it

imo “but it makes 3p dependencies simpler, just copy the package directory and import the package” is not nearly a good enough reason to justify the hard-pairing between folder structure and the idea of ‘packages’

it’s as if with this one specific decision, the language is creating friction with how i wanna work on a more regular basis

5

I’ve known some decent programmers who would probably organize things the way you’re describing, so I don’t think it’s a bad idea entirely (granted I haven’t thought hard about it,) and I hope you find a good compromise. That said, when I experienced the same friction I simply stopped writing many packages for one program. I’ve got my app, which is one package, and I actually find that to be very freeing. I may not be in the same situation as you, though, because I don’t have to distribute any “subpackages” that are part of my project separately from my project’s distribution.

6

i don’t have to distribute any “subpackages” either, it’s just one of the things what bill gave as an example for why directories = packages is desirable

it isn’t about that, it’s about being able to group files together based on their real-world modelling use-case without having to unnecessarily make it fit on a dependency graph

an example off the top of my head is gameplay code

i’d like to be able to organise like

GameplayScripts
├── PlayerCharacter
│   ├── SkinSelect.odin
│   ├── PlayerStats.odin
│   └── /* more files */
└── Vehicles
    ├── DrivingPhysics.odin
    ├── VehicleUI.odin
    └── /* more files */

where character and vehicle code is interdependent on each other (freely use structs/procedures declared in the other one)

based on the way odin is set up currently, i gotta either:

  • give up on how i actually want to organise my files
  • make one of them dependent on another
  • create some kind of a third “interface” package that both of them depend on
  • add no dependency between them at all, and move any cross cutting concern (no matter how minor) to the calling site

the first point there is the reason for my friction, and the rest have their own disadvantages that add more points of failure and slow down iterations (+momentum) and what not

7

—-

I love the directory = package feature.

Lot less imports at the top, no artificial hierarchy, locality of behaviour, things that work together stay together.

After being burnt by dependency hell of package managers, versioning conflicts, cyclic redundancy, import barrels, and so on and so forth, I prefer the simplicity of Odin.

2 Likes
8

The main thing that makes me think twice before using it in a serious project is that the compiler is still being developed, and things will sometimes break backwards compatibility.

It’s actually good that we’re still in that phase - it’s needed to improve Odin and I’m not complaining. But realistically speaking, for me that is the biggest barrier to using it more. I just don’t want to have to fix some of my projects when they no longer compile.

9

I’m with you on this one! I don’t need to make some kind of taxonomic family tree where every (deeply nested) file only has a couple of functions!

I absolutely hate managing cyclic dependencies in Python, for example.

I find the Odin way of doing it refreshing!

1 Like
10 
@(static, rodata)
1 Like
11

imo even the perception of different subdirectories only really exists because it’s still being looked at as “subparts” of a larger structure, that still have to maintain some amount of dependency graph

in production code, it isn’t super uncommon (or much of a curse) to end up with different directories that have code, which have cyclic dependencies among them

it adds a certain amount of flexibility that helps with building faster and focusing on iterations (while maintaining quality) for the production app (/game) you’re developing, without having to worry about your directory structure (more for categorisation purposes) maintaining some kind of a strict graph

i’m also against having small files with 3 functions in them, and i don’t really think it somehow goes hand in hand that if you have a lot of subdirectories, they’ll for sure have small functions in them

12

You don’t have to separate everything into lots of different sub-directories though. You can just put them all in the same folder.

I do understand why people like to do that, but I think people spend a lot of time thinking about how to classify what their code does in granular detail and make this “family tree” of folders and files. With modern tooling (and I just use vim so not exactly cutting edge) it’s very easy to search for your code even if its in one big file, and most editors have things like “jump to definition”.

Having packages and sub-directories be the same thing makes it easier to figure out where the file is in the first place!

13

i don’t think i can agree with that one

i mean yeah sure, vscode, or jetbrains ides or even emacs/vim can probably “search everywhere” or “jump to def” but imo that’s not necessarily enough

that’s where my personal disagreements begin; yeah i can put everything in the same folder, i just don’t want to because it helps with mental organisation at a personal level

anecdotally, it is also the more preferable route for the teams i’ve worked with who can navigate Source/Settings/Runtime/GraphicsSettings.cs while having some amount of cyclical dependency with Source/Rendering/Vegetation/Trees.cs (for whatever reasons; i mean they’re both a few thousands of lines)

there’s some more nuance that’s needed here - i mean i obviously agree with the part that subdirectories can help you figure out where the file is, but i disagree that that should somehow also lock me into having to maintain an acyclic dependency graph between different subdirectories of my project

14

Threads like this one. Just write code, who cares about this popularity meme.

5 Likes
15

I feel, its changing for the better, and at least not in drastic way like Zig lang.

And the language is really focused, minimal, so I doubt it’s going to keep changing in a way that will make it not be Odin lang anymore.

16

Odin is simple and this is its big benefit. Because you should not care about how to write code, what smart pointer to use, how to organize your project folder; you just write your project and love what you are doing. What else do you need. You have got good performance despite someone’s annoying that Odin does not use all LLVM optimizations. I have written dumb simple ECS with Odin and got very fast memory processing, better than in C3 for example (btw I love C3 also, thanks Lerno for that language).

I think it depends on where you have come to Odin from. It can feels unusual to have such simplicity and you look for some silver bullets, features, tricks and syntaxis sugar you wanna add to your coding coffee cup.

Thank you, Odin team for that amazing language!

1 Like
17

Lack of visibility control, or at least, no easy visibility control

This isn’t as useful as you’d expect. Python has even less visibility control than Odin does and yet has loads of production code out there. Usually an underscore-prefixed variable is good enough for signalling that you should only modify this value if you really know what you’re doing.

No Immutability

This is not really something you can practically promise to the end-programmer in a low-level systems language like Odin where it can be sidestepped fairly easily with casts and pointer manipulation. Immutability additionally requires constructors and various other affordances that ultimately railroad you into the individual-element mindset rather than the grouped-element mindset that Odin tries to encourage in its design.

Odin does apply immutability to a few specific contexts such as procedure parameters and loop variables, as that allows it to apply optimizations such as using constant references instead of copying big structs.

Package Manager

I don’t really have much to add to Bill’s opinions here, but I do basically agree with him.

It’s absolutely true that not having a package manager slows adoption of the language, but that’s a good thing. Quite frankly, it keeps lazy developers from using it and making garbage with the language, which benefits the language in the long run by bringing up the average quality of software written in Odin.

I don’t want Odin to be a hype-driven language and you shouldn’t either. Saying no to package managers helps to keep the hype train in the depot, where it belongs.

It’s a game development language

Honestly I think this is primarily a historical accident of the mentality that goes into game dev libraries. They’re designed not to need updates all the time, as it’s generally best practice in game dev to stick to the same version of all your libraries from start to finish of the project. As a result, these kinds of libraries are, by far, the easiest to vendor in, especially given that they’re written in C or C++ and are pretty easy to link to from Odin.

SQLite would be a good candidate to add to vendor and I think there is some talk of that. I’ve done it before in my own project, but it’s a bit unclear how to best expose the API other than doing a 1:1 mapping which includes all of the legacy functions and whatnot.

As for networking libraries… those are better language-native in most cases. I’m sure those will start coming in, but even still, I think Go will likely remain a better option for servers.

3 Likes
18

Honestly I think this is primarily a historical accident of the mentality that goes into game dev libraries. They’re designed not to need updates all the time, as it’s generally best practice in game dev to stick to the same version of all your libraries from start to finish of the project. As a result, these kinds of libraries are, by far, the easiest to vendor in, especially given that they’re written in C or C++ and are pretty easy to link to from Odin.

Other than the FAQ answer about people thinking Odin is “just” for game dev, I think that’s also a good point that those kinds of libraries are very stable and easy to vendor compared to many other ones out there. I think that’s more of an indictment of the rest of the software world than “gamedev” being “good”.

As for SQLITE, one of the reason I am EXTREMELY hesitant of including SQLite into vendor is because as soon as you add one database, people will be asking for another, and another, and then a generalized interface for SQL databases, and more. It’s honestly a slippery slope I can trivially see going down if we even start there. I know I am BDFL and I can just arbitrarily say no to things, but I don’t like to have “arbitrary NOs”, I want a decent justification, and just stopping at SQLite isn’t enough of a good justification.

4 Likes
19

I understand the hesitation. However, sqlite and postgres are in a league of their own. A lot of databases speak the postgres protocol. Having vendor support for their client libs would open up Odin for a lot of prototyping that people like to do when testing a new language. Nobody wants to start a toy project by making bindings to libpq.

Similar to how Raylib opens up game development “messing around” for early odin users, postgres and sqlite (especially sqlite) bindings open up such play with “user account apps”.

Also, making bindings for sqlite is super easy and wouldn’t take much work to maintain. Can’t speak to postgres but I believe Laytan or another OG already made pretty good bindings to it.

2 Likes
20

It might be a very dumb idea but:
In case that can help, having a symlink might be a workaround if you really want to still be able to reconcile sub-folders being in the same package. Though then you have those symlinked files to maintain.