Thought that a fun topic might help kick off some discussion on the new forum and, hey, you never know, someone might drop an interesting feature you didn’t know about!
For me, I think the switch statement is my favourite thing so far. Union type switches are so useful, but the simple idea of having implicit breaks, with fallthrough being a keyword, just sums up the ethos of the language.
For me my favorite features are bit_set, enumerated arrays, and the way the compiler infers if .Foo in my_bit_set, as well as or_return.
Thanks to or_return and Odin’s already terse syntax, core:math/big, which started as a source port of libtommath, has more functionality than the original in about 30% of the lines of code.
Pros:
I like that the basic first class string is just a []u8 with simple utf-8 integration, and there is actual friction in getting to strings.Builder.
Slices in general just eliminating the whole pointer + length dance you have to do in C while providing a simple interface for bounds checking.
Multi-return values simplifies the error handling and control flow around it.
Favorite: distinct is the feature I didn’t know I wanted, but now I can’t live without it.
Cons:
bit_set, distinct, be/le int types, and default ability to print anything via %v
Those are the features I miss the most whenever I’m at work (C and C++)
I’d pick distinct, bit_field and the explicit little/big endian types. If you work a lot with binary protocols or file formats most types are a one-to-one mapping to the spec, which saves a lot of time on shuffling bits around (and a lot of debugging because of forgotten htonX()/ntohX()).
jasonKercher’s list already covered all of mine, but I must also add that I absolutely adore bit_set and enumerated arrays.
I especially love enumerated arrays, I adore them.
Odin has completely usurped C as my go-to language. I will now only go to C at utmost end of need.
There are a lot of nice things about it that make me like it.
One of the things that drew me in was the first-class #simd support. I’ve been extremely interested in generalized SIMD lately, and Odin’s built-in support for it has been really nice to work with. Odin’s also enabled me to set up a workflow for multiversioning SIMD functions too, through core:sys/info and its enable_target_feature attribute. That whole process has made me miss meta-programming a bit, as the multiversioning aspect has resulted in a fair bit of boilerplate, but overall it’s been the best experience that I’ve had with using generalized SIMD with any language so far. It’s already driven me to contribute code to core for additional CPU features (AVX-512), and I’ve also dug into the compiler a small amount to figure out how to implement a SIMD intrinsic for packing the most significant bits of the vector’s elements into a single bit_set (a la x86 movemask), and I’ve seen quite a bit of use for it so far. I plan to contribute that at some point too, probably along with some other SIMD-related contributions as well.
I really like that Odin is so simple; it feels like I can “see the bottom”, so to speak, and makes it very approachable to add things to the standard library and the compiler alike.
I’ve come to really like a lot of the other features of the language too, though. The general syntax of the language is very clean, as are the for loops, both with slices and ranges.bit_set is quite nice; the intrinsic I mentioned above uses it for the result, and the two make it extremely easy to iterate over SIMD lanes selected by a mask. bit_field is also quite nice, though I haven’t used it as much (yet). Built-in maps and dynamic arrays are also quite convenient and nice to work with.
I also like the idea of the context and its usage in managing allocators (though I haven’t done too much with it yet). I like the idea of having control over allocators, but found the “explicitly pass allocators around” approach of Zig to be a bit cumbersome. Odin’s context feels like a nice middle ground between “fully explicit” and “fully implicit”.
For my own entertainment, I re-created many of the odin primitives in C. Mostly with macros (because how else would you do it in C), bounds checking and all. It was a fun learning experience. Some of the statements balloon out to 4000+ characters in a single line. While applying it to some code I was working on for an actual product. I found 2 out of bounds access errors near instantly. That was a scary reminder that all safety being opt-in in C is really flying by the seat of your pants.
So, in comparison to C, bounds checking should be on the list.
Hmm… That’s a tough question.
Does base:intrinsics count? Being able to access so many low-level features really is handy. I like being able to dive in and build my own structures from the ground up while being able to access the CPU-level bit-twiddling buttons, all with a standard interface across different architectures. Just being able to have that there has let me learn so much more.
If we’re talking pure language (no packages, not even base), then context is really good, particularly the allocator interface like @Barinzaya pointed out. I can casually allocate strings that I know won’t be used for long just by summoning up context.temp_allocator and away I go. You also get the PRNG and logging interface through context. There’s nothing stopping you from adding more to it if you wanted, too. There’s a lot of freedom to the language.
One of the great things about Odin is that so much of the language works so well in general, that I hardly notice it, so it’s hard to point to many things that I think are astounding on their own. It’s a well-organized orchestra that lets you solve the problem you’re working on.
A complete lack of exceptions and the try-catch-finally dance found in C++ and Python is great. Error handling by value is so much simpler. No class methods either. It might be easier to point to things that Odin doesn’t have as being part of my favorite features. =)
Wow, a lot of love for bitsets, huh.
I reckon stuff in the standard lib counts, yeah. The features in a core/std lib are often a big part of one’s reasoning when considering a language.
Surprised no one has mentioned the package system/semantics. The whole ‘dir as a package’ concept is surprisingly effective, and once you grasp it, it just makes so much sense.
just having map in the language is a huge one for me. i need them in a ton of my projects and allowing them first-class syntax is just a huge QoL improvement compared to other languages
another one is how foreign automatically appends the correct linker flags, honestly really great how little code it takes to get bindings up and running
Native support for array programming, hands down.
To me, it’s the readability and consistency.
The linear algebra package combined with array programming is such a great idea. Imagine how many hundreds of thousands (if not more) of lines of code would have been saved if C/C++ had something like that?
Also bit_set and switch are great. Odin manages to feel high level while giving you low level control.
It doesn’t get in my way 
The whole standard library and vendor libs (raylib my beloved).
Array programming, swizzling and scope based defer.
Also the way of making bindings to the external libraries. I’ve never tried write anything complicated in C but with Odin the way things work just clicks! And now I can somewhat understand how to do C programming lol. And I was kind of script-kiddy before, used to write in Lua, GDScript and other similar languages.
My favorite feature is the comprehensible core library. I found out about sync/chan before it was included in the package docs, but simply reading it made it clear how to use it.
Also that it naturally encourages simple and straightforward programming.
My favorite feature about Odin is Ginger Bill criteria on what to add and what to not add to the language. i.e.: he didnt added metaprogramming because he managed to solve all problems so far without metaprogramming.
I think people don’t talk enough about how easy odin makes it to completely change everything in your project, including vast memory layout changes. Moving from AOS to SOA is more often than not a single directive change. Dropping a semicolon turns your function into a function pointer. There are so many little things that you usually want to do and they are made easy to do, like bit_set, enumerated arrays, etc.