1. 20
    1. 14

      Odin is nice, IMO it just doesn’t quite reach the threshold of “worth using over Rust or Zig”. My personal, unfair, gut reaction on seeing it is “the author needs to use more functional programming languages for fun”; it very much feels like something in the imperative lineage, opposed to Rust’s “ML dressed up like C++” which makes my brain happier.


      • Ternary operators instead of if being an expression
      • No pattern matching
      • Multiple return values instead of tuples
      • Variables mutable by default (except for function params, apparently, so you have to jump through a Magic Hoop to mutate function params through pointers)
      • 0 is considered an acceptable default value for most types
      • Map’s are a built-in type, which in a low-level language is a warning sign to me that the generics system is not powerful enough

      There’s other things that annoy me but they’re more personal preference than actual design stuff. So instead here are some things I do like:

      • Built-in array programming – I think this is a special case that deserves more love, because it’s a real pain to write SIMD stuff manually or use a particular library and learn its ins and outs
      • Slices – dynamic arrays are actually pretty difficult to deal with sanely in languages that want to have fixed-length arrays too, slices are a nice tool for thinking about them
      • bit set type – IMO bitsets express what one actually wants more nicely than just stuffing together an int and a bunch of constants. I haven’t used them enough in practice to know if they’re an improvement For Real, but I like the idea.
      1. 2

        I think Odin is better understood as a Go alternative. Go matches all your examples (no pattern matching, no tuple types, mutable by default, zero initialization, built-in map type) except ternary operators.

        1. 2

          Eh, maybe. Go is higher level than Odin and has garbage collection. If I wanted an alternative to Go I’d be looking at things like .NET or JVM languages, Nim, OCaml, Erlang/Elixir, maybe Python/Lua+JIT, etc. I’d only want something in the Rust, Zig or Odin realm if I actually needed strong control over memory.

          1. 6

            What I am saying is that just as Rust is “ML with control over memory”, Odin is “Go with control over memory”.

            1. 1

              thaaaaaaat makes more sense. Thanks.

    2. 4

      Kinda sad to see no discussion on this one. I find Ginger Bill (the guy behind Odin) to be fairly entertaining, and of course he does a lot of promotion (self promotion? 🤷‍♂️) of the language, but it’s usually interesting stuff to watch. For example: https://www.youtube.com/watch?v=2YLA4ajby00

      I’d skip his reviews of other languages (he feels a bit threatened by Google pouring money into the new and doesn’t-quite-exist-yet Carbon Language, for example), but his thoughts on Odin (what he did, how he did it, and why he did what he did) are worthwhile reading/watching.

    3. 2

      An implied length is one where the length is known through some other means other than being explicitly associated. This can be encoded in the function signature like in the case of glVertex3fv where you know the pointer to the float* parameter will be of three floats, […] These ideas, while more dangerous, are simply not expressible with slices.

      Doesn’t Odin have fixed-length arrays too?

      Related to packages are that of package imports. Odin’s import system only allows forming a singular directed acyclic graph of packages, rather than that of a strongly unambiguous graph. What this means is that in Odin, your imports must have no directed cycles and must be topologically orderable.

      I’m confused. According to the linked article, a strongly unambiguous graph is a directed acyclic graph (with an additional restriction).