[HN Gopher] Odin, a Pragmatic C Alternative with a Go Flavour
       ___________________________________________________________________
        
       Odin, a Pragmatic C Alternative with a Go Flavour
        
       Author : hmac1282
       Score  : 50 points
       Date   : 2025-05-09 18:01 UTC (4 hours ago)
        
 (HTM) web link (bitshifters.cc)
 (TXT) w3m dump (bitshifters.cc)
        
       | WhereIsTheTruth wrote:
       | I like odin a lot, however, there are two things that just don't
       | stick with me, and i ended up quitting:
       | 
       | - RTTI: just give me compile time type introspection and let me
       | disable RTTI without making the language unusable
       | 
       | - when/import: just let me wrap an import inside a when block,
       | being forced to split my file in 3 made me quit the language
        
       | pbohun wrote:
       | I've started experimenting with Odin for some personal projects
       | and it's been great. The built-in vendored libraries make
       | creating certain programs trivial. For example, just `import rl
       | "vendor:raylib"` and you can use `rl.InitWindow(800,600,"Test")`.
       | No need to install Raylib, add to path or use special linker
       | directives, just `odin build .`!
       | 
       | Also I think Odin struck the right balance of features while
       | trying to keep to the spirit of C.
        
       | throwawaymaths wrote:
       | > This is the polar opposite of Zig's embracing of
       | metaprogramming for as much as possible.
       | 
       | I found this claim a bit strange. do people actually use
       | metaprogramming in Zig a lot?
        
         | Cieric wrote:
         | I can't comment about everyone, but I use it a lot for building
         | libraries and such. I just recently built a database ORM, but
         | since their metaprogramming is used for their generics I've run
         | across it a lot just for those case.
        
         | jamiejquinn wrote:
         | IMO it's one of Zig's advantages over C (text substitution
         | macros are both too powerful and not powerful enough). If
         | you're using Zig without metaprogramming, you're leaving a
         | useful (if advanced) tool on the table.
        
           | johnnyjeans wrote:
           | C's preprocessor not being powerful enough is less a problem
           | with text-substitution macros, more that they're not allowed
           | to expand recursively which was an intentional design choice.
           | There are some hacks you can do to get around it, and people
           | have done cool things[1] within the limited space those hacks
           | grant you, but there's a reason many C projects with
           | extensive metaprogramming just use an external macro language
           | (which is also just text-substitution).
           | 
           | IMO AST Macros are an even bigger problem than text
           | substitution. Debugging metaprogramming of any kind past a
           | certain point of complexity is a royal pain in the ass (even
           | in a Lisp, Forth or Prolog), but AST explorers are next to
           | useless for complicated logic problems that involve needle in
           | a haystack searches of side effects. If you're dealing with a
           | large AoS of heterogeneous SoAs which influence each other to
           | shuffle around, and most of the related code and the
           | structures themselves are generated via AST macros, you
           | better be _really_ comfortable with assembly analysis and
           | debugger scripting.
           | 
           | [1] - https://github.com/Hirrolot/datatype99
        
         | kristoff_it wrote:
         | Depends on the project, the general recommendation is to use
         | metaprogramming like salt: just a pinch to add some flavor.
         | Newcomers sometimes go bonkers with it though.
        
       | James_K wrote:
       | A C alternative means a language that will last for 50 years,
       | whereas this seems more like "whatever's popular by way of LLVM".
       | I can see some real smart stuff coming out of languages like Zig
       | and Rust, where Odin seems just to follow along.
        
       | taylorallred wrote:
       | Odin really hits the sweet spot for everything you would want
       | from a language for the game dev and game-dev-adjacent space in
       | terms of simplicity, convenience, and speed. I think a major
       | design decision of the language that will make or break it for
       | users is the fact that the language gives you common features
       | instead of giving you the means of abstraction to make those
       | features yourself. For example, instead of preprocessor macros
       | you get the `when` clause for conditional compilation because in
       | Bill's estimation, that's one of the only real needs for macros.
       | The same goes for data structures. Odin gives you the certified
       | classics like dynamic arrays and maps but doesn't give you a
       | whole lot to make your own custom data structures (it's possible,
       | just not encouraged by the language design). All in all, I think
       | if you want to make an application with a language that has
       | batteries included and you don't need a lot more than that, Odin
       | is nearly flawless.
        
         | johnnyjeans wrote:
         | > but doesn't give you a whole lot to make your own custom data
         | structures
         | 
         | For anyone unfamiliar with Odin that might misinterpret this,
         | Odin has structs and parametric polymorphism for those structs.
         | What it does not have is operator overloading or methods (which
         | also means no constructors or destructors). In this sense, its
         | product types are like ocaml's, only without methods too. Odin
         | is not object oriented.
        
       | mcbrit wrote:
       | I am currently limiting myself to 500 lines of (particle engine)
       | code while listening to visual artists talking about their
       | workflow in UE5 or Houdini, and Odin+Raylib are lovely to work
       | in.
       | 
       | GingerBill has shouted out Go, but Odin doesn't particularly feel
       | like a Go flavo(u)r.
        
         | mcbrit wrote:
         | To point out something that is a fail: I don't want to hear
         | about how you simulated 10M particles on the GPU without
         | acceleration forces.
        
       | vandyswa wrote:
       | FWIW, another take on "C Alternative" is the D programming
       | language:
       | 
       | https://wiki.dlang.org/Tutorials
       | 
       | Comparatively mature, there's even a freeware book which is quite
       | good:
       | 
       | http://www.ddili.org/ders/d.en/index.html
        
         | macintux wrote:
         | Walter Bright, the creator of D, is an active commenter here.
         | 
         | https://news.ycombinator.com/user?id=WalterBright
         | 
         | Zig is also worth mentioning, and pops up frequently.
        
         | bsrkf wrote:
         | I always thought it was more akin to a C++ than a C
         | alternative, and reading
         | https://en.wikipedia.org/wiki/D_(programming_language) seems to
         | rather confirm this notion:                 "originated as a
         | re-engineering of C++"       "influenced by Java, Python, Ruby,
         | C#, and Eiffel"       "design by contract, ranges, built-in
         | container iteration concepts, and type inference"       "array
         | slicing, nested functions and lazy evaluation."       "Java-
         | style single inheritance with interfaces and mixins"
         | "function overloading and operator overloading"       "supports
         | five main programming paradigms" (including OOP)       ... et
         | cetera
         | 
         | Though it does support things like in-line assembly and the
         | like, I'm sure most C programmers would pass on it, as a
         | C-alternative, based on those factoids.
        
       | ultrarunner wrote:
       | As a completely incidental observation (and maybe related to the
       | article from a few days ago considering the importance of
       | language skills compared to math skills for software
       | development), I'm interested in what people choose to capitalize
       | when developing languages. With c, lowercase seems to be the
       | default, signifying variables or function calls. Adding
       | inheritance in c++ leads to Proper Nouns like classes being
       | capitalized, while their instances are often lowercase. This
       | communicates a subtle "feel" for the language, meta information
       | about what's being accomplished.
       | 
       | Capitalizing method calls (`rl.InitWindow()`) seems to place the
       | importance on the Method being called, but at first glance (ASP,
       | or Go off the top of my head) it muddies the waters. If this
       | isn't clear, consider that capitalizing ALL code would reduce
       | clarity as all letter shapes are now essentially the same (a
       | box).
       | 
       | I spend most of my time in c, c++, ruby, and javascript, but
       | maybe I should try to do a personal project in Go (or Odin) for
       | this reason alone.
        
         | xemoka wrote:
         | In this case, I believe the capitalization is a hold-over from
         | raylib's c library, Odin doesn't appear to put any preference?
         | 
         | In Go it has a specific meaning: starting an identifier with a
         | capital causes it to be exported for use in other packages.
         | Identifiers with a starting lowercase char are package private.
         | 
         | Apologies if this is explaining what you already know...
        
         | munificent wrote:
         | I believe most of this is language designers picking their
         | personal preference and then that percolating down through
         | history.
         | 
         | The original UNIX folks really love lowercase. Executables are
         | lowercase, most file names are lowercase, file extensions are,
         | etc. That extends to C where DMR and Ken Thompson chose
         | lowercase names for keywords, built-in types, and standard
         | library functions. If I remember right, Thompson uses all
         | lowercase in most of his communications too, so I suspect it
         | comes from him. Or maybe it was a flex because the PDP-11
         | _could_ do lowercase when some other early computers didn 't
         | support it at all?
         | 
         | The early Pascal compilers from Niklaus Wirth and friends
         | appear to be all caps, probably because that's all the machines
         | supported. The language itself generally isn't case sensitive.
         | (I say "generally" because there are many flavors of Pascal.)
         | 
         | When Anders Hejlsberg created Turbo Pascal (which is also case-
         | insensitve), he introduced a convention of lowercase for
         | keywords what we now call PascalCase for function and type
         | names and (judging by the Wikipedia article) a mixture of
         | PascalCase and camelCase for variables.
         | 
         | Perhaps because Straustrup built on C but is a Dane like
         | Hejlsberg, he picked a mix for C++: camelCase function and
         | variable names with PascalCase type names.
         | 
         | These conventions then flowed down through time. Java was
         | heavily inspired by C++ and takes the same convention. C# is
         | another Hejlsberg creation and follows his preferences.
         | JavaScript follows Java. (It must annoy Hejlsberg to no end
         | that his third baby TypeScript breaks with his own convention.)
        
       | leelou2 wrote:
       | Odin seems to strike a really interesting balance between
       | simplicity and practicality, especially for game development. I
       | like the idea of having "batteries included" without too much
       | abstraction getting in the way. For those who have used both Odin
       | and Go, how do you feel about the differences in day-to-day
       | development? Are there any features in Odin that you wish Go had,
       | or vice versa? Would love to hear more real-world experiences!
        
         | dismalaf wrote:
         | I mean, the biggest difference is that Go has a GC and Odin
         | doesn't. And each's ecosystem reflects that... In practice
         | they're simply not used for the same types of software.
        
       | gitroom wrote:
       | been playing around with odin and honestly the ease of getting
       | started feels way better for me than most c-like stuff ever has.
       | you ever think these smaller pain points keep more folks from
       | switching than big technical features?
        
       ___________________________________________________________________
       (page generated 2025-05-09 23:00 UTC)