4 ms·

I would highly recommend Odin to anyone who has looked at Zig or Nim (as the author did here). Also not corporate controlled, but used in production at several

I would highly recommend Odin to anyone who has looked at Zig or Nim (as the author did here). Also not corporate controlled, but used in production at several corporations. https://odin-lang.org/ https://odin-lang.org/

brokencode 4y ago
My problem with Odin is the same as Zig. I think that manual memory management is a bad choice for most applications and only really has a place in very low-level or performance-critical code. To me, the most promising newer languages all attempt to make automatic memory management faster, more predictable, and more scalable. That’s what I think is so compelling about Rust. Koka is a promising upcoming language as well, and there are many others in this space.
- Calavar 4y ago
  Outside of Rc and Arc, which part of Rust memory management is automatic? The whole pitch for Rust is making manual safety management safer by using more sophisticated compile time checks. It certainly doesn't make automatic memory management faster or more scalable. (Rc and Arc are both regressions from tracing GC in that regard.)
  - brokencode 4y ago
    The whole ownership and borrowing system is a type of automatic memory management. It just happens at compile time instead of runtime like most automatic memory management systems. Manual memory management is possible in Rust, but is not typically something developers need to interact with. There is typically no need to manually free objects when you are done with them. You just let the system destroy the objects automatically when they go out of scope.
    - Calavar 4y ago
      > There is typically no need to manually free objects when you are done with them. You just let the system destroy the objects automatically when they go out of scope. By deciding where to scope the variable with the destructor/drop function, you've already made a manual decision about memory management. The compiler implicitly inserting a call to the destructor does not automate the decision of when/where to allocate or free memory - its just syntax sugar over the decision that you already made. This is just as true of Rust in 2023 as it was of C++ 40 years ago. With true automatic memory management like tracing GC or reference counting, you have no idea where the or when the memory will be freed as you write the code, and the answer will usually be different over different invocations of the same code. > The ownership and borrowing system is a type of automatic memory management No, it isn't. The borrowing system is completely orthogonal to memory management. You can write a function that takes a borrow, do all sorts of things with that borrow, including forwarding it along to other functions further down the call chain, and the memory backing that borrow could be statically allocated, dynamically allocated with the default rust allocator, or allocated by some custom solution like a slab or pool allocator. The code reads the same regardless of the memory management scheme because you make the decision on how you will allocate (and eventually free) the memory before you ever create a borrow. The borrow checker can help keep you from making use-after-free errors, but it doesn't dictate when, where, or how memory is freed. That's still up to the programmer.
      - kortex 4y ago
        > By deciding where to scope the variable with the destructor/drop function, you've already made a manual decision about memory management. That's not really what's meant by manual memory management. MMM almost always means things like malloc/free, arenas, buffers with pointers, etc. I would not call stack allocation "manual", and IMO Rust's system is closer to stack allocation than it is to either manual or automatic memory. In terms of DX, bugs and ergonomics, you only really have two schemes: ones which requre some kind of free() call and thus permit use-after-free bugs (manual) and those that make it impossible (ignoring weakref and friends). Rust is not manual by virtue of no free() instruction. In the same breath, "automatic memory management" is not an exact antonym of manual.
      - brokencode 4y ago
schaefer 4y ago
Odin looks super interesting. Thank you!
jeltz 4y ago
What does Odin do better than Zig? To me the languages seem very similar except that Zig has its very heavy use of comptime.
- alphazard 4y ago
  Zig's comptime idea is definitely an edge to Zig. It's an elegant feature that solves a lot of problems. However, using it for parametric polymorphism is very clunky. Not that it's a bad way to think about PP, but right now the ergonomics are just not there yet. Odin has a sophisticated PP system, which supports something like dependent types last I checked. Odin's context system is excellent. It is similar to implicits in Scala, but Odin's is by far the best implementation of the idea that I have come across. If Go wanted to make context part of the language, they would do well to understand Odin's context. Odin doesn't do OOP. Zig does. I don't know why a C replacement would try to. As far as leadership, Andrew (Zig) is the better open-source leader. He's better at engaging with the community, attracting people to his cause etc. But as far as a language designer, GingerBill (Odin) really "gets" it. If you listen to him talk about language design, it's very clear he's given it much more consideration than pretty much anyone.
  - TUSF 4y ago
    > Odin doesn't do OOP. Zig does. I don't know why a C replacement would try to. What sort of OOP does Zig do, exactly?
    - alphazard 4y ago
      The kind with objects that have methods. Look at the examples. They don't have a class hierarchy, but they have something very similar to Go where a data type (object) "owns" a set of procedures (methods). https://ziglang.org/learn/samples/ https://ziglang.org/learn/samples/ `try int_queue.enqueue(25);` Go has a pretty sane approach to OOP, with methods forming the basis for interfaces (one of Go's most powerful concepts) very nicely. But Go is not really a C replacement. I know Rob Pike said they "started with C", but realistically Go replaced Java in its niche. It's not a C replacement in the way that Zig and Odin are.
bogwog 4y ago
Is it really used in production at several corporations, or is it more that several corporations happen to use a popular product that was built with Odin? Besides the JengaFX people, who else is using this language?

brokencode 4y ago

My problem with Odin is the same as Zig. I think that manual memory management is a bad choice for most applications and only really has a place in very low-level or performance-critical code. To me, the most promising newer languages all attempt to make automatic memory management faster, more predictable, and more scalable. That’s what I think is so compelling about Rust. Koka is a promising upcoming language as well, and there are many others in this space.

Calavar 4y ago
Outside of Rc and Arc, which part of Rust memory management is automatic? The whole pitch for Rust is making manual safety management safer by using more sophisticated compile time checks. It certainly doesn't make automatic memory management faster or more scalable. (Rc and Arc are both regressions from tracing GC in that regard.)
- brokencode 4y ago
  The whole ownership and borrowing system is a type of automatic memory management. It just happens at compile time instead of runtime like most automatic memory management systems. Manual memory management is possible in Rust, but is not typically something developers need to interact with. There is typically no need to manually free objects when you are done with them. You just let the system destroy the objects automatically when they go out of scope.
  - Calavar 4y ago
    > There is typically no need to manually free objects when you are done with them. You just let the system destroy the objects automatically when they go out of scope. By deciding where to scope the variable with the destructor/drop function, you've already made a manual decision about memory management. The compiler implicitly inserting a call to the destructor does not automate the decision of when/where to allocate or free memory - its just syntax sugar over the decision that you already made. This is just as true of Rust in 2023 as it was of C++ 40 years ago. With true automatic memory management like tracing GC or reference counting, you have no idea where the or when the memory will be freed as you write the code, and the answer will usually be different over different invocations of the same code. > The ownership and borrowing system is a type of automatic memory management No, it isn't. The borrowing system is completely orthogonal to memory management. You can write a function that takes a borrow, do all sorts of things with that borrow, including forwarding it along to other functions further down the call chain, and the memory backing that borrow could be statically allocated, dynamically allocated with the default rust allocator, or allocated by some custom solution like a slab or pool allocator. The code reads the same regardless of the memory management scheme because you make the decision on how you will allocate (and eventually free) the memory before you ever create a borrow. The borrow checker can help keep you from making use-after-free errors, but it doesn't dictate when, where, or how memory is freed. That's still up to the programmer.
    - kortex 4y ago
      > By deciding where to scope the variable with the destructor/drop function, you've already made a manual decision about memory management. That's not really what's meant by manual memory management. MMM almost always means things like malloc/free, arenas, buffers with pointers, etc. I would not call stack allocation "manual", and IMO Rust's system is closer to stack allocation than it is to either manual or automatic memory. In terms of DX, bugs and ergonomics, you only really have two schemes: ones which requre some kind of free() call and thus permit use-after-free bugs (manual) and those that make it impossible (ignoring weakref and friends). Rust is not manual by virtue of no free() instruction. In the same breath, "automatic memory management" is not an exact antonym of manual.
    - brokencode 4y ago

schaefer 4y ago

Odin looks super interesting. Thank you!

jeltz 4y ago

What does Odin do better than Zig? To me the languages seem very similar except that Zig has its very heavy use of comptime.

alphazard 4y ago
Zig's comptime idea is definitely an edge to Zig. It's an elegant feature that solves a lot of problems. However, using it for parametric polymorphism is very clunky. Not that it's a bad way to think about PP, but right now the ergonomics are just not there yet. Odin has a sophisticated PP system, which supports something like dependent types last I checked. Odin's context system is excellent. It is similar to implicits in Scala, but Odin's is by far the best implementation of the idea that I have come across. If Go wanted to make context part of the language, they would do well to understand Odin's context. Odin doesn't do OOP. Zig does. I don't know why a C replacement would try to. As far as leadership, Andrew (Zig) is the better open-source leader. He's better at engaging with the community, attracting people to his cause etc. But as far as a language designer, GingerBill (Odin) really "gets" it. If you listen to him talk about language design, it's very clear he's given it much more consideration than pretty much anyone.
- TUSF 4y ago
  > Odin doesn't do OOP. Zig does. I don't know why a C replacement would try to. What sort of OOP does Zig do, exactly?
  - alphazard 4y ago
    The kind with objects that have methods. Look at the examples. They don't have a class hierarchy, but they have something very similar to Go where a data type (object) "owns" a set of procedures (methods). https://ziglang.org/learn/samples/ https://ziglang.org/learn/samples/ `try int_queue.enqueue(25);` Go has a pretty sane approach to OOP, with methods forming the basis for interfaces (one of Go's most powerful concepts) very nicely. But Go is not really a C replacement. I know Rob Pike said they "started with C", but realistically Go replaced Java in its niche. It's not a C replacement in the way that Zig and Odin are.

bogwog 4y ago

Is it really used in production at several corporations, or is it more that several corporations happen to use a popular product that was built with Odin? Besides the JengaFX people, who else is using this language?