[HN Gopher] Introduction to the Odin Programming Language
       ___________________________________________________________________
        
       Introduction to the Odin Programming Language
        
       Author : ibobev
       Score  : 74 points
       Date   : 2024-06-15 10:51 UTC (12 hours ago)
        
 (HTM) web link (zylinski.se)
 (TXT) w3m dump (zylinski.se)
        
       | donlzx wrote:
       | I like the Odin language because it is really joyful to
       | programming with it. Hope there are more resources and mature
       | packages besides gaming development.
        
         | CyberDildonics wrote:
         | What is joyful about programming it?
        
           | Sparkyte wrote:
           | The advertisement on Y Combinator.
        
       | eterps wrote:
       | In my opinion, Odin is the most Pascal-like language with C-like
       | syntax.
        
         | Rochus wrote:
         | Why not directly use a modern Pascal? What's the advantage of
         | Odin in this respect (besides the C-like syntax)?
        
           | bobajeff wrote:
           | Like what?
           | 
           | The only one I can think of is Ada.
        
             | Rochus wrote:
             | FreePascal, Delphi, Oxygene, Oberon+
        
       | techn00 wrote:
       | The syntax looks very similar to Go
        
         | thomascgalvin wrote:
         | There are only so many ways to write "C, but better," or "C++,
         | with fewer warts."
         | 
         | Any languages that want to be recognizable to people
         | comfortable with the C-lineage are going to converge on a lot
         | of points.
        
         | desdenova wrote:
         | And some of the bad ideas are also there.
        
           | lostdog wrote:
           | Like what? I'm seeing that the Union is by-type and not by-
           | name (such as C vs Rust enums). I didn't see good support for
           | preventing null pointers, but maybe I missed that. And it
           | wasn't clear if RAII works.
        
           | metaltyphoon wrote:
           | Zero values is just bad
        
       | Lyngbakr wrote:
       | > If you want to use one of Odin or Zig but don't know which one,
       | then I recommend spending 1-2 weeks using each and then make up
       | your own mind.
       | 
       | That's fair enough, but has anyone who has done this got any
       | thoughts? Zig seems to have a lot of admirers on HN. Is Odin on
       | par with Zig?
        
         | desdenova wrote:
         | Just by reading this introduction, Zig seems like a much better
         | designed language so far.
         | 
         | Odin inherits a lot of warts from horrible languages like Go,
         | and they seem to have run out of ideas to solve some problems
         | at some point.
        
           | forrestthewoods wrote:
           | Can you be more specific? What do you like about Zig? What
           | warts does Odin inherit?
        
             | metaltyphoon wrote:
             | I don't think zero values is a good idea on Odin. In Zig,
             | anytype will be a mistake.
        
           | cardanome wrote:
           | > Odin inherits a lot of warts from horrible languages like
           | Go
           | 
           | Still waiting on you to list what those "warts" may be. I
           | mean sure golang may be overly conservative in its design but
           | calling it "horrible" is a very wild take.
           | 
           | The only evil I know of that golang has perpetuated is making
           | an unused-variable error an compile error that will block
           | compilation instead of an linter error. This makes
           | prototyping much more annoying.
           | 
           | Ironically a design mistake that Zig has copied as well. Not
           | sure if Odin does actually
        
         | sarchertech wrote:
         | I investigated both for a side project. I ended up going with
         | Odin. Primarily because despite them both being non-GC
         | languages, Odin felt higher level to program in. Also Odin has
         | official Direct3D and Metal support.
        
       | sidkshatriya wrote:
       | (Syntax is not as important as the intrinsic attributes of a
       | language)
       | 
       | Why Odin -- Can someone tell me ?
        
         | diggan wrote:
         | Odin website sure could! Highlights according to landing page:
         | 
         | > Data-Oriented, Simplicity, High Performance, "Batteries
         | Included", Open Source (BSD 3)
         | 
         | https://odin-lang.org/
        
         | rerdavies wrote:
         | The FAQ hides an excellent description of the philosophy of
         | Odin, once you get past the first couple of FAQ entries.
         | 
         | https://odin-lang.org/docs/faq/
         | 
         | A shame that it isn't broken out into an explicity "Why Odin"
         | page.
        
           | fuzztester wrote:
           | >A shame that it isn't broken out into an explicity "Why
           | Odin" page.
           | 
           | This make me think that every programming language web site
           | should have a Why $language page, either as the home page, or
           | prominently linked from it.
        
             | fuzztester wrote:
             | The same for every other type of software's web site, of
             | course.
        
       | jakjak123 wrote:
       | This looks so much like Golang, weird to not mention it
        
       | Sparkyte wrote:
       | Another one to collect dust. The problem I run into with new
       | languages are the often dissolving community when they first gain
       | popularity and then run into a critical design flaw. How is a
       | person who goes about learning a language to find extendability
       | of a language if it never gets out of the early-alpha stage and
       | has more than 5k followers?
        
         | diggan wrote:
         | Seems EmberGen (and all products JangaFX produces) are made
         | with Odin, so one can be fairly confident it won't disappear
         | over night. I'd probably consider Odin production ready already
         | since EmberGen works pretty well for its use cases, and is
         | blazing fast.
        
       | James_K wrote:
       | Based on what I've seen of the guy who designs Odin, I would not
       | recommend it. I remember seeing him talking about the morality of
       | memory allocation as it relates to market economics, which is a
       | load of gibberish that you could only produce if you are truly
       | clueless.
        
         | keb_ wrote:
         | Same, except I read him say he prefers pineapple on pizza.
         | After reading that, I knew Odin was no good.
        
           | efnx wrote:
           | Tabs or spaces? ;)
        
             | thechao wrote:
             | I'm a \v & \f -man, myself, but my colleagues just don't
             | get it.
        
             | Groxx wrote:
             | Null bytes.
        
         | szvsw wrote:
         | > the morality of memory allocation as it relates to market
         | economics ... that you could only produce if you are truly
         | clueless
         | 
         | I'm actually very curious to see that! I'm not sure what the
         | angle espoused there is, but it seems fun at least from the
         | perspective of academic science and technology studies to
         | consider. This person might be going through a few too many
         | scales to make meaningful commentary there though... In any
         | case, there can be interesting connections and bidirectional
         | influence found between technical systems and social
         | organizations/politics/commercial industry, especially when it
         | comes to things like how standards are defined over time. Even
         | selecting the standardized sizes of containers for shipping and
         | the technical design of connectors between shipping
         | containers/cranes for picking them up has an interesting social
         | and economic history that touches on questions of changing
         | relationships to labor in post-war America!
         | 
         | This guy might be spouting total nonsense, but it seems
         | interesting and fun to read either way!
         | 
         | Edit: I'm also not sure why trying to understand relationships
         | between technical entities (like a programming language) and
         | the systems it exists within, even if misguided, disqualifies
         | the outputs of this person? Maybe there are plenty of other
         | reasons, and maybe what they were saying was in fact batshit,
         | but with zero context, I'm genuinely curious to learn more
         | about what was said that was so crazy!
        
       | JonChesterfield wrote:
       | I think I'm over "C but better" as a language design premise. C
       | is really good as a low level language. The control you give up
       | over assembly is well chosen. The syntax is fine. You have to
       | tell the compiler to now screw you which is crazy as a default
       | but doesn't matter much in practice.
       | 
       | I've just spent a week doing ~ nothing other than writing C. It's
       | been great. The language does exactly what you tell it to.
       | Generating C to do things from tables of data is very easy. I
       | especially like the zero context switching that comes from being
       | able to remember the language. Python or C++ involve far too much
       | looking up documentation.
       | 
       | It's the wrong tool for solving most problems but the right tool
       | for telling a computer what to do.
        
         | bxparks wrote:
         | C may be the best example of "worse is better", but every time
         | I do something non-trivial with it, I wish there was something
         | better:
         | 
         | * Undefined behavior, there are apparently over 100 of them. I
         | can probably name about 5, maybe 10. Will the compiler warn me
         | if I accidentally trigger undefined behavior? Of course not, it
         | assumes that I am super-human who never makes a mistake.
         | 
         | * Code sharing using '#include', god I hate 'em.
         | 
         | * No namespaces, which means a single global namespace for all
         | functions.
         | 
         | * Strings: every time I have to manipulate strings in C, I want
         | to shoot myself.
         | 
         | * Arrays decaying into pointers, very clever, causing so much
         | misery.
         | 
         | * Array length decoupled from the array pointer. No way to pass
         | around both of them together, and checked automatically by the
         | compiler.
         | 
         | * The C preprocessor #define magic. Love 'em when they are
         | mine, hate 'em when they are someone else's. Hate 'em even more
         | when they are mine 6 months later.
         | 
         | * The #define/#ifdef spaghetti code. There ought to be better
         | ways to support multiple architectures.
         | 
         | Those are just off the top of my head. I'm sure I could come up
         | with a few more items.
        
         | tobyhinloopen wrote:
         | Yeah writing C is like a little zen garden. It's so relaxing.
         | It's simple, and you get a lot of freedom. I love it, wish I
         | could use it more.
         | 
         | I also really love Zig but for some reason I still prefer C
        
       | mrichman wrote:
       | Why is manual memory management a virtue? I'd rather fight the
       | Rust compiler than deal with runtime errors, memory leaks, etc.
        
       | WhereIsTheTruth wrote:
       | Odin is pretty nice, except for its RTTI, bloated executable as a
       | result with the name of your types in clear, author of the
       | language is against having compile time type introspection, so
       | you are stuck with having to do reflection at runtime..
       | 
       | It could have been the perfect language for me, it's unfortunate
        
       ___________________________________________________________________
       (page generated 2024-06-15 23:01 UTC)