7 ms·

Odin has renewed my joy of programming. Built in bounds checking, slices, distinct typing, no undefined behavior, consistent semantics between optimization mod

Odin has renewed my joy of programming. Built in bounds checking, slices, distinct typing, no undefined behavior, consistent semantics between optimization modes, minimal implicit type conversions, context system and the standard library tracking allocator combine together to eliminate the majority of memory bugs I found use for sanitizers in C/C++. Now I'm back to logic bugs, which neither Rust nor sanitizers can help you directly with anyway because they rely on program and not language semantics. Obviously these features together do not eliminate those classes of bugs, like Rust, but Odin chooses a different point on the efficient frontier to target, and does so masterfully. To put the cherry on top, the sane package system, buttery smooth syntax, sensible preprocessor (the 'constant system'), generics, LLVM backend for debug info / optimization, open source standard library, simply build system, engaging and well intended community make day to day programming a pleasant experience.

hsn915 4y ago
Odin's stance towards undefined behavior was probably the decisive element that made me prefer it over the other languages. https://twitter.com/TheGingerBill/status/1495004577531367425 https://twitter.com/TheGingerBill/status/1495004577531367425
- raphlinus 4y ago
  How does this work in practice? Is the behavior of a use-after-free defined? Data races? The latter even more so for objects that don't fit in one machine word, such as slices. While avoiding undefined behavior is a noble goal, my personal feeling is that actually achieving that will be much harder than it might first seem, and will probably end up precluding a good deal of optimization. Of course, C has an entire class of UB that is much more excessive than useful, for example left shift of a negative integer. It's clearly and obviously possible to do much better than C. I'm just skeptical that "no UB at all" is in reach for a low-level, systems programming language that is also portable and can be compiled with optimization comparable to C.
  - hsn915 4y ago
    I think the twitter thread I linked answers your questions? "use after free" is an instance of a memory access pattern that is considered invalid from the program's point of view. What happens depends on the situation: Was the memory returned to the operating system? If so it will probably result in a page fault and if you don't have a thing to handle the signal then the OS will crash your program. Was the memory part of an arena managed by the custom allocator that still owns it? If so it will return whatever value is contained in the address being dereferenced.
    - raphlinus 4y ago
      The point of the C11 memory model is that it gives formal bounds on what optimizations the compiler is and is not able to do. In particular, it is free to reorder memory operations as if the program was single-threaded, unless the memory operations are explicitly marked as atomic. My assertion is that if you do these optimizations and then have a data race, it's functionally equivalent to undefined behavior, even if you call it something different and loudly proclaim that your language doesn't have UB.
      - jessermeyer 4y ago
        Obviously Odin does not use C's memory model. And in instances where LLVM optimizes Odin for UB, it is a bug, and not a feature. Odin explicitly opts out of all optimization passes that depend or leverage UB, but that's a moving target. For example, as mentioned in the article, Odin does not leverage LLVM's poison value optimizations, which are derived from optimizations exploiting undefined behavior. Sure, some code is slowed. But can you point to a well known and well used algorithm whose runtime characteristics depend upon exploiting UB? If you code goes fast because it's doing undefined things the compiler strips away, that's a structural bug in the application, in my view.
        spacechild1 4y ago
        > Obviously Odin does not use C's memory model. How is that obvious? And which memory model does Odin use? Just to be clear: a "memory model" is not about memory management, it is about the behaviour of multithreaded programs: https://en.m.wikipedia.org/wiki/Memory_model_(programming) https://en.m.wikipedia.org/wiki/Memory_model_(programming)
dunefox 4y ago
> minimal type inference How is that a pro? That's a net negative.
- Mountain_Skies 4y ago
  That depends on your goal. Want to move fast and break things? Then type inference is great. Want to build things that are solid and reliable? Type inference can be a very bad thing in the wrong hands and most hands are the wrong hands.
  - dunefox 4y ago
    How is type inference for "moving fast and breaking things" but not for building solid and reliable things? I'm not quite sure we're talking about the same concept here.
    - Yoric 4y ago
      Having been a professional OCaml developer, a long time ago, I found out that too much type inference gets into the way of proper documentation and, to some extent, proper naming conventions. Once code stabilized, we started annotating everything, as in languages with much more limited support for type inference, because it made finding type-level (and sometimes runtime) issues easier. Perhaps that's the GP is referring to?
      - tialaramex 4y ago
        I'm comfortable with Rust's choice to infer types only within a function, OCaml does sound like it has too much inference. But I think the GP was just confused about vocabulary and what they're really talking about is coercion and they originally wrote "minimal type inference" instead of "minimal type coercion". I think they subsequently corrected to "minimal implicit type conversions" which, is basically just more words for the same thing. Unwanted type coercions are an infamous problem in C and C++.
- jessermeyer 4y ago
Yoric 4y ago
My experience of Rust is that affine types go a long way towards eliminating some classes of logic bugs. That being said, there's always space for exploring other design choices! I haven't tried Odin yet, but it looks very interesting.

hsn915 4y ago

Odin's stance towards undefined behavior was probably the decisive element that made me prefer it over the other languages. https://twitter.com/TheGingerBill/status/1495004577531367425 https://twitter.com/TheGingerBill/status/1495004577531367425

raphlinus 4y ago
How does this work in practice? Is the behavior of a use-after-free defined? Data races? The latter even more so for objects that don't fit in one machine word, such as slices. While avoiding undefined behavior is a noble goal, my personal feeling is that actually achieving that will be much harder than it might first seem, and will probably end up precluding a good deal of optimization. Of course, C has an entire class of UB that is much more excessive than useful, for example left shift of a negative integer. It's clearly and obviously possible to do much better than C. I'm just skeptical that "no UB at all" is in reach for a low-level, systems programming language that is also portable and can be compiled with optimization comparable to C.
- hsn915 4y ago
  I think the twitter thread I linked answers your questions? "use after free" is an instance of a memory access pattern that is considered invalid from the program's point of view. What happens depends on the situation: Was the memory returned to the operating system? If so it will probably result in a page fault and if you don't have a thing to handle the signal then the OS will crash your program. Was the memory part of an arena managed by the custom allocator that still owns it? If so it will return whatever value is contained in the address being dereferenced.
  - raphlinus 4y ago
    The point of the C11 memory model is that it gives formal bounds on what optimizations the compiler is and is not able to do. In particular, it is free to reorder memory operations as if the program was single-threaded, unless the memory operations are explicitly marked as atomic. My assertion is that if you do these optimizations and then have a data race, it's functionally equivalent to undefined behavior, even if you call it something different and loudly proclaim that your language doesn't have UB.
    - jessermeyer 4y ago
      Obviously Odin does not use C's memory model. And in instances where LLVM optimizes Odin for UB, it is a bug, and not a feature. Odin explicitly opts out of all optimization passes that depend or leverage UB, but that's a moving target. For example, as mentioned in the article, Odin does not leverage LLVM's poison value optimizations, which are derived from optimizations exploiting undefined behavior. Sure, some code is slowed. But can you point to a well known and well used algorithm whose runtime characteristics depend upon exploiting UB? If you code goes fast because it's doing undefined things the compiler strips away, that's a structural bug in the application, in my view.
      - spacechild1 4y ago
        > Obviously Odin does not use C's memory model. How is that obvious? And which memory model does Odin use? Just to be clear: a "memory model" is not about memory management, it is about the behaviour of multithreaded programs: https://en.m.wikipedia.org/wiki/Memory_model_(programming) https://en.m.wikipedia.org/wiki/Memory_model_(programming)

dunefox 4y ago

> minimal type inference How is that a pro? That's a net negative.

Mountain_Skies 4y ago
That depends on your goal. Want to move fast and break things? Then type inference is great. Want to build things that are solid and reliable? Type inference can be a very bad thing in the wrong hands and most hands are the wrong hands.
- dunefox 4y ago
  How is type inference for "moving fast and breaking things" but not for building solid and reliable things? I'm not quite sure we're talking about the same concept here.
  - Yoric 4y ago
    Having been a professional OCaml developer, a long time ago, I found out that too much type inference gets into the way of proper documentation and, to some extent, proper naming conventions. Once code stabilized, we started annotating everything, as in languages with much more limited support for type inference, because it made finding type-level (and sometimes runtime) issues easier. Perhaps that's the GP is referring to?
    - tialaramex 4y ago
      I'm comfortable with Rust's choice to infer types only within a function, OCaml does sound like it has too much inference. But I think the GP was just confused about vocabulary and what they're really talking about is coercion and they originally wrote "minimal type inference" instead of "minimal type coercion". I think they subsequently corrected to "minimal implicit type conversions" which, is basically just more words for the same thing. Unwanted type coercions are an infamous problem in C and C++.
jessermeyer 4y ago

Yoric 4y ago

My experience of Rust is that affine types go a long way towards eliminating some classes of logic bugs. That being said, there's always space for exploring other design choices! I haven't tried Odin yet, but it looks very interesting.