The author based this book on their blog post Intro to the Odin Programming Language. There’s a lot of overlap if you’re curious what the chapters might look like outside the free sample. The book...
The author based this book on their blog post Intro to the Odin Programming Language. There’s a lot of overlap if you’re curious what the chapters might look like outside the free sample. The book goes more in-depth than the blog, at least for the first three chapters. I’m working through some simple programs trying to determine whether I want to purchase the book- it definitely fills some gaps the official docs gloss over.
Odin is an interesting language (I think all languages are interesting), I think it might be a better tool than Zig for my planned projects in OpenGL. I thought the C interoperability in Zig was fantastic, but it looks like Odin’s vendor libraries might offer an even comfier experience for the same programs.
A lot of online discussion refers to Odin as a modern C but from my perspective it feels more like a lower level Go. This is no accident, Odin creator Ginger Bill lists Go and its creators as a major influence. Personally this makes Odin much easier to write because I use Go all day at work. I feel a bit like that bell curve meme where the low-end says “Go is the best language,” the peak says “Every language is a tool with proper use cases,” and the high-end says “Go is the best language.” That said, some of my Go muscle memory is presenting hurdles where the same paradigm doesn’t work in Odin. Working with string types and byte slices is confusing me when trying to trim newline characters read from the standard input. I’m sure once I figure that out I’ll have an EmberGen clone shipped by the following weekend.
One nitpick I have about the error handling is an intentional departure from Go, where you can reassign to an error type using the := shorthand if there is at least one new variable on the left side of the operator:
foo, err := mightErr()
if err != nil {…}
bar, err := mightErr()
if err != nil {…}
Is valid Go code, but the Odin compiler will not allow variables to be redeclared. Technically this isn’t a difference in error handling but because I don’t redeclare any variables other than err it’s the only place I feel it.
A bit off topic but could you talk about what you like about go? I've tried a few times in my life (2019, 2022, 2024) and every time I've despised it. What makes it tick for you? What makes you...
A bit off topic but could you talk about what you like about go? I've tried a few times in my life (2019, 2022, 2024) and every time I've despised it. What makes it tick for you? What makes you reach for it and what are you doing with it?
My languages are Java, Python, C, Kotlin, C#, Scala, and Clojure in decreasing order of comfort, if that helps with discussion.
There’s a lot of surface level reasons why I like Go, the fast compile times, easy dependency management, large community, etc. Then there’s reasons that carry more weight, like colorless...
There’s a lot of surface level reasons why I like Go, the fast compile times, easy dependency management, large community, etc.
Then there’s reasons that carry more weight, like colorless functions, or the stellar standard library. Going from Go to an async/await language is annoying. It’s a problem I don’t realize is solved until I run into it again. Having the Go runtime built into every binary makes it bigger (~2MB) but for my use cases this isn’t an issue. When I first started using Go my instinct was to search for third party libraries to assemble into an application, over time I realized most applications can be built using the standard library. At my job we don’t use third party packages since it’s fairly easy to roll our own.
Having to check err for nil every time you call an errable function felt annoying and overly verbose at first, but I do miss it when I need to handle errors in other languages. It’s easy noise to tune out when writing and reading, and there’s less opportunity for lazy devs to hide behavior on accident with a giant try block.
I think Go markets itself as a general programming language but I would make the distinction that it’s certainly a web-oriented language. Any high performance or systems development projects would be better off with a lower level language focused on speed like C or Rust. There are popular databases written in Go, but nobody’s writing a Vulkan renderer with it.
Another increasingly important aspect of Go is the commitment to backwards compatibility. Upgrading to a new version of Go is typically a positive experience, I think there’s only been a small handful of instances where there were breaking changes to some of the standard library modules. A big highlight at my job is how often they hire people who have never used Go because getting up to speed usually only takes a couple of months.
I used Java at my last job and I’ve never had any desire to use it outside of work because the syntax and boilerplate code was ugly to me. Java has similar advantages to Go and a healthy host of battle tested libraries and frameworks. There’s a reason over 3 billion devices are running it ;) but I think every place that Java shines, Go shines much brighter.
All of that said, I just like the simple syntax. I think it’s an elegant language without much friction.
The author based this book on their blog post Intro to the Odin Programming Language. There’s a lot of overlap if you’re curious what the chapters might look like outside the free sample. The book goes more in-depth than the blog, at least for the first three chapters. I’m working through some simple programs trying to determine whether I want to purchase the book- it definitely fills some gaps the official docs gloss over.
Odin is an interesting language (I think all languages are interesting), I think it might be a better tool than Zig for my planned projects in OpenGL. I thought the C interoperability in Zig was fantastic, but it looks like Odin’s vendor libraries might offer an even comfier experience for the same programs.
A lot of online discussion refers to Odin as a modern C but from my perspective it feels more like a lower level Go. This is no accident, Odin creator Ginger Bill lists Go and its creators as a major influence. Personally this makes Odin much easier to write because I use Go all day at work. I feel a bit like that bell curve meme where the low-end says “Go is the best language,” the peak says “Every language is a tool with proper use cases,” and the high-end says “Go is the best language.” That said, some of my Go muscle memory is presenting hurdles where the same paradigm doesn’t work in Odin. Working with string types and byte slices is confusing me when trying to trim newline characters read from the standard input. I’m sure once I figure that out I’ll have an EmberGen clone shipped by the following weekend.
One nitpick I have about the error handling is an intentional departure from Go, where you can reassign to an error type using the
:=shorthand if there is at least one new variable on the left side of the operator:Is valid Go code, but the Odin compiler will not allow variables to be redeclared. Technically this isn’t a difference in error handling but because I don’t redeclare any variables other than
errit’s the only place I feel it.A bit off topic but could you talk about what you like about go? I've tried a few times in my life (2019, 2022, 2024) and every time I've despised it. What makes it tick for you? What makes you reach for it and what are you doing with it?
My languages are Java, Python, C, Kotlin, C#, Scala, and Clojure in decreasing order of comfort, if that helps with discussion.
There’s a lot of surface level reasons why I like Go, the fast compile times, easy dependency management, large community, etc.
Then there’s reasons that carry more weight, like colorless functions, or the stellar standard library. Going from Go to an async/await language is annoying. It’s a problem I don’t realize is solved until I run into it again. Having the Go runtime built into every binary makes it bigger (~2MB) but for my use cases this isn’t an issue. When I first started using Go my instinct was to search for third party libraries to assemble into an application, over time I realized most applications can be built using the standard library. At my job we don’t use third party packages since it’s fairly easy to roll our own.
Having to check err for nil every time you call an errable function felt annoying and overly verbose at first, but I do miss it when I need to handle errors in other languages. It’s easy noise to tune out when writing and reading, and there’s less opportunity for lazy devs to hide behavior on accident with a giant try block.
I think Go markets itself as a general programming language but I would make the distinction that it’s certainly a web-oriented language. Any high performance or systems development projects would be better off with a lower level language focused on speed like C or Rust. There are popular databases written in Go, but nobody’s writing a Vulkan renderer with it.
Another increasingly important aspect of Go is the commitment to backwards compatibility. Upgrading to a new version of Go is typically a positive experience, I think there’s only been a small handful of instances where there were breaking changes to some of the standard library modules. A big highlight at my job is how often they hire people who have never used Go because getting up to speed usually only takes a couple of months.
I used Java at my last job and I’ve never had any desire to use it outside of work because the syntax and boilerplate code was ugly to me. Java has similar advantages to Go and a healthy host of battle tested libraries and frameworks. There’s a reason over 3 billion devices are running it ;) but I think every place that Java shines, Go shines much brighter.
All of that said, I just like the simple syntax. I think it’s an elegant language without much friction.