6 ms·

I think Odin just doesn't do enough. The improvements over C are there, but imho too small to justify/motivate a large-scale change. And personally I think (!)

by dxuh 4y ago

I think Odin just doesn't do enough. The improvements over C are there, but imho too small to justify/motivate a large-scale change. And personally I think (!) there is no reason to introduce a new programming language without RAII these days. If you don't solve memory management any more than C did (not), then you are ignoring the biggest problem that needs solving and every replacement that does address this problem looks more attractive.

gingerBill 4y ago
And for you, you clearly don't need manual memory management nor high control over memory, memory layout, and memory access. And that's absolutely fine, but don't criticize something which other people REQUIRE and DESIRE. You cannot "solve memory management" because there isn't just "one problem". As for RAII, the article itself showcases some of the alternatives Odin has with the `defer` statement and `deferred_*` attributes. So Odin can have many of the aspects of RAII without tying it directly to a data-type/struct/class, which itself as many costs and trade-offs. RAII has loads of problems to it and many other things which are required to solve those problems. This language is just not for you, and that is absolutely fine! But don't proclaim that it's "ignoring the biggest problem that needs solving" when you are assuming everyone has the same needs, requires, and desires as yourself. n.b. I am the creator of the Odin programming language; go use a language that will help you solve your problems with your requirements.
- mplewis 4y ago
  But safe memory management is the biggest problem that needs solving. It’s empirically impossible for humans to write secure, complex programs while managing memory by hand. I agree with OP, that Odin doesn’t go far enough toward safety in this regard. We do all require and desire security.
  - gingerBill 4y ago
    What it is interesting is that the comment never mentions memory safety, only memory management; you just added memory safety into the discuss. Memory safety and memory management are not equivalent concepts. As I state in another reply (https://news.ycombinator.com/item?id=32629951 https://news.ycombinator.com/item?id=32629951), you have memory safety and manual memory management. And Odin offers numerous memory safety features as well as being designed around the power of custom allocators.
    - avgcorrection 4y ago
      > What it is interesting is that the comment never mentions memory safety, only memory management; you just added memory safety into the discuss. Can’t speak for OP but I also assumed that you were alluding to being able to use unsafe memory management in this part > > And for you, you clearly don't need manual memory management nor high control over memory, memory layout, and memory access. Since high control usually means being able to do whatever you want (compilers always have to be a bit conservative).
      - gingerBill 4y ago
        "usually" by whom? "High control over memory" doesn't necessarily mean doing anything "unsafe" with it either. That term could allow for "unsafeness" yes, but it is not solely restricted to that. High control could just mean adding extra annotations about the access, or not having padding in a struct, or specifying the alignment, or many other things, none of which may be classed as "unsafe".
- avgcorrection 4y ago
  Quite the outlashing. One can use both default RAII in a programming language as well as opt-in unsafe memory management. So you are clearly wrong in your assumptions about what the OP must clearly not require/want.
  - gingerBill 4y ago
    Still no. Many problems require manual memory management of which custom allocators aid a lot with. Odin has extensive support for custom allocators and many other things. RAII may not even make sense within the type system of a language too. Languages with RAII (C++, D, Ada, Rust (through Drop), and Vala) all have higher level constructs such as methods, and many have automatic memory management too (Rust's is automatic but at compile time). First let's take C++ as an example of a RAII language, RAII has numerous flaws to it: * In practice (but not necessarily) couples allocation/initialization together meaning that allocations are rarely bulked together and are scope-governed (which can be very poor with performance). (And I know placement `new` exists, but that isn't implicit RAII any more and doesn't solve any of the other problems) * C++ originally only had copy constructors which usually involved loads of implicit allocations everywhere. This lead to copy-elision optimizations and the introduction of move/ownership semantics as a way to minimize these issues. * RAII is very implicit to the reader that it is even happening, meaning you cannot just read the code and know what is happening. * Ctors and dtors usually have to assume to never fail, or require exceptions to handle the failure cases. And not everyone wants, or can even have, software exceptions. In sum, adding RAII is not a minor thing and to make it even useful without too many flaws requires loads of extra things on top. It's not a simple construct. I also never said anything about memory safety in my comment. You can have memory safety and manual memory management. The question is what level of safety and in what form. Odin has pretty much all the general memory safety features (bounds checking, Maybe types, distinct types, no pointer arithmetic, default to slices, virtual memory protections, and many more). What Odin does not offer is ownership semantics and lifetime semantics, which is an entire discussion itself which I won't talk about in this already long comment.
    - dxuh 4y ago
      I want to address some points for people that are reading and don't have enough C++ experience to judge that they are not as serious as they might seem. * You can just have your constructors not initialize your member variables. If they don't have default constructors that do work, then no work is done. * Yes, originally. Move-semantics are part of the language since C++11. Enough time has passed. * I read and write C++ every day at work and in my free time and I rarely find this to be a problem. If I see a non-trivial type, I assume it's destructor is called at the end of scope. And whether I have to look up the destructor of some type or a corresponding free function (like in C code usually), makes no difference to me. * Gamedev can live entirely without exceptions and many other software projects do as well. You just have to write your constructors so that they do little work (which is encouraged anyways) and use methods to initialize them. Having static methods that return an optional<T> is also pretty common. Of course you can also have constructors that do a ton of work, so you never know what is being done, exception handling everywhere to error handle all that code and not use move semantics or very old C++ versions. There are always ways to use a language in a bad way and get bad results. I am sure you have seen bad C code. Of course RAII is not simple. It's extremely complicated, which is why I consider it missing. Using a new language needs be justifyable by some significant added value.
- dxuh 4y ago
  My point was that I don't see much of a point in yet another language that is C with an extra 10%. There is another one like that almost every week. Plenty of applications that require manual memory management have been written in C++ or Rust, which do provide RAII. If you know that manual memory management is required for some applications, you also know it's not 100% of the code that needs it.
  - gingerBill 4y ago
    Do you honestly think Odin is "C with an extra 10%"? Or any of the decent alternatives that are available (e.g. Zig, Jai, etc)? Because if you really think that is the case, you know nothing about these languages nor have ever used them. All of these languages provide a hell of a lot more than "10%". As for RAII, I do explain in another comments (https://news.ycombinator.com/item?id=32629951 https://news.ycombinator.com/item?id=32629951 & https://news.ycombinator.com/item?id=32631462 https://news.ycombinator.com/item?id=32631462) why RAII has alternatives and not necessary for every language. If you truly believe that RAII is necessary for you, then use a language that has it (e.g. C++, Rust, D).
  - davedx 4y ago
    - jessermeyer 4y ago
      As someone who programs professionally in C but writes Odin as a hobby, Odin contributes more like 1000% ease of use, comparatively. And I bet that scales up even more on a team as compared to C. ASAN, complex build tools, undefined behavior, implicit type conversions, etc, each of these contribute substantial problems all on their own, and they basically don't ever arise in Odin from the start.
    - dxuh 4y ago
      You're right. I'm sorry. It got too heated below my initial comment and I got upset. I'm not in a good place currently and I should probably refrain from commenting at all. And yes, I am not fun at parties.
Kukumber 4y ago
How do you write your garbage collectors or RC without precise manual memory management? How do you render billions of vertices and maintain a gameplay loop under 8ms for AAA games without precise manual memory/layout management? Not everyone is writing websites in javascript
- YuukiRey 4y ago
  I guess they are referring to something like Rust which manages to "solve memory management" while still letting you write high performance code.
- dxuh 4y ago
  RAII is often optional automatic memory management, like in C++ or Rust. Both of these languages are used for AAA games and rarely used for websites. My point was that if you don't go as far as those two, there is just not much of a point to not using C instead.
  - Kukumber 4y ago
    Rust is not used in the AAA industry, it was advertised by a company (Embark), but they ended up using Unreal Engine 5 for both of their new upcoming games
  - godratio 4y ago
    NOT TRUE you would of course choose Odin over C unless you could not for some reason. Odin is 100x better environment to program in than C. C++ is used for AAA games. Rust is not really used if hardly at all because of the highly competitive and time critical nature and very much the need to change things fast.
- pjmlp 4y ago
  Here, a GC implemented in Oberon, a GC enabled systems programming language, https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kernel.Mod.txt https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne... For something more modern in D, also a GC enabled systems programming language, https://github.com/dlang/dmd/tree/master/druntime/src/core https://github.com/dlang/dmd/tree/master/druntime/src/core
samatman 4y ago
I don't think any feature should be a mandatory part of a programming language, provided its reasons for not including it make sense. I'm fuzzy on Odin, if you showed me some Odin and some Hare I bet I couldn't tell them apart, but it kinda looks like a nice C with syntax inspiration from Go and (hence) Pascal. A language like that, as long as the object code is correct, then hey, it's there for people who want it. I think Zig, which I understand better but don't use, has a good reason for not building in RAII. Zig has a "no allocation without an allocator" rule, and what's easiest to describe as native valgrind. It also has comptime, and RAII loses some conceptual simplicity when you start doing transformations between what-you-see and what-you-get. I think it's worth continuing to explore whether that's a sufficient approach to memory safety, rather than doing something which has already been done, prematurely. I happen to think it's a promising approach, favoring clarity and simplicity. We'll see. Zig can always add RAII later, and so can Odin. But at most once each, so it pays not to be hasty.
- gingerBill 4y ago
  Regarding Odin and Hare, I'd argue most people would easily be able to tell them apart from the syntax alone because the declaration syntaxes are quite different. And most people judge a syntax pretty much solely by the declaration syntax itself. Regarding RAII, I explain in another comment (https://news.ycombinator.com/item?id=32629951 https://news.ycombinator.com/item?id=32629951) the issues with RAII and what it requires to be useful. Odin has the similar rule of "no allocation without an allocator" but has the implicit `context` system which passes the current context's allocators around. Odin also has core library support for valgrind, callgrind, memcheck, and soon helgrind. Odin has features (which this article does showcase) which are akin to RAII but are not attached to the type system. And as I explained in the previous comment, RAII wouldn't even make much sense in Odin (or Zig for that matter) and would probably never a good idea to add it later. There are better alternatives to RAII for languages such as Odin and Zig.
  - samatman 4y ago
    Hi Bill, wasn't intended as a criticism of either, or as an observation about the syntax choices, but rather as a way of saying how familiar I am with both: I could say some things about them which are accurate, but not tell code samples apart. RAII isn't something I happen to be looking for in a language, it kind of falls between Rust and your work in a way that I don't have a use for. It's an interesting domain, isn't it? You'll always have people reacting from the hip to the problems C has given us, but they'll be back a couple hours later to talk about the wonders of SQLite. SQLite got there by being careful and building tools to keep them out of trouble. I see an important role for languages which build those tools in, but don't try to replace a manual transmission with an automatic.
stjohnswarts 4y ago
I agree RAII at a minimum should be available, but why not just use c++ at that point? I'll just go to something like zig or rust that is established and has thousands of libraries available.
- gingerBill 4y ago
  I recommend reading my reply to another comment regarding RAII: https://news.ycombinator.com/item?id=32629951 https://news.ycombinator.com/item?id=32629951 Also the article itself demonstrates different approaches to achieve behaviour similar to RAII through the `defer` statement and `deferred_*` attributes.

by dxuh 4y ago

gingerBill 4y ago

And for you, you clearly don't need manual memory management nor high control over memory, memory layout, and memory access. And that's absolutely fine, but don't criticize something which other people REQUIRE and DESIRE. You cannot "solve memory management" because there isn't just "one problem". As for RAII, the article itself showcases some of the alternatives Odin has with the `defer` statement and `deferred_*` attributes. So Odin can have many of the aspects of RAII without tying it directly to a data-type/struct/class, which itself as many costs and trade-offs. RAII has loads of problems to it and many other things which are required to solve those problems. This language is just not for you, and that is absolutely fine! But don't proclaim that it's "ignoring the biggest problem that needs solving" when you are assuming everyone has the same needs, requires, and desires as yourself. n.b. I am the creator of the Odin programming language; go use a language that will help you solve your problems with your requirements.

mplewis 4y ago
But safe memory management is the biggest problem that needs solving. It’s empirically impossible for humans to write secure, complex programs while managing memory by hand. I agree with OP, that Odin doesn’t go far enough toward safety in this regard. We do all require and desire security.
- gingerBill 4y ago
  What it is interesting is that the comment never mentions memory safety, only memory management; you just added memory safety into the discuss. Memory safety and memory management are not equivalent concepts. As I state in another reply (https://news.ycombinator.com/item?id=32629951 https://news.ycombinator.com/item?id=32629951), you have memory safety and manual memory management. And Odin offers numerous memory safety features as well as being designed around the power of custom allocators.
  - avgcorrection 4y ago
    > What it is interesting is that the comment never mentions memory safety, only memory management; you just added memory safety into the discuss. Can’t speak for OP but I also assumed that you were alluding to being able to use unsafe memory management in this part > > And for you, you clearly don't need manual memory management nor high control over memory, memory layout, and memory access. Since high control usually means being able to do whatever you want (compilers always have to be a bit conservative).
    - gingerBill 4y ago
      "usually" by whom? "High control over memory" doesn't necessarily mean doing anything "unsafe" with it either. That term could allow for "unsafeness" yes, but it is not solely restricted to that. High control could just mean adding extra annotations about the access, or not having padding in a struct, or specifying the alignment, or many other things, none of which may be classed as "unsafe".
avgcorrection 4y ago
Quite the outlashing. One can use both default RAII in a programming language as well as opt-in unsafe memory management. So you are clearly wrong in your assumptions about what the OP must clearly not require/want.
- gingerBill 4y ago
  Still no. Many problems require manual memory management of which custom allocators aid a lot with. Odin has extensive support for custom allocators and many other things. RAII may not even make sense within the type system of a language too. Languages with RAII (C++, D, Ada, Rust (through Drop), and Vala) all have higher level constructs such as methods, and many have automatic memory management too (Rust's is automatic but at compile time). First let's take C++ as an example of a RAII language, RAII has numerous flaws to it: * In practice (but not necessarily) couples allocation/initialization together meaning that allocations are rarely bulked together and are scope-governed (which can be very poor with performance). (And I know placement `new` exists, but that isn't implicit RAII any more and doesn't solve any of the other problems) * C++ originally only had copy constructors which usually involved loads of implicit allocations everywhere. This lead to copy-elision optimizations and the introduction of move/ownership semantics as a way to minimize these issues. * RAII is very implicit to the reader that it is even happening, meaning you cannot just read the code and know what is happening. * Ctors and dtors usually have to assume to never fail, or require exceptions to handle the failure cases. And not everyone wants, or can even have, software exceptions. In sum, adding RAII is not a minor thing and to make it even useful without too many flaws requires loads of extra things on top. It's not a simple construct. I also never said anything about memory safety in my comment. You can have memory safety and manual memory management. The question is what level of safety and in what form. Odin has pretty much all the general memory safety features (bounds checking, Maybe types, distinct types, no pointer arithmetic, default to slices, virtual memory protections, and many more). What Odin does not offer is ownership semantics and lifetime semantics, which is an entire discussion itself which I won't talk about in this already long comment.
  - dxuh 4y ago
    I want to address some points for people that are reading and don't have enough C++ experience to judge that they are not as serious as they might seem. * You can just have your constructors not initialize your member variables. If they don't have default constructors that do work, then no work is done. * Yes, originally. Move-semantics are part of the language since C++11. Enough time has passed. * I read and write C++ every day at work and in my free time and I rarely find this to be a problem. If I see a non-trivial type, I assume it's destructor is called at the end of scope. And whether I have to look up the destructor of some type or a corresponding free function (like in C code usually), makes no difference to me. * Gamedev can live entirely without exceptions and many other software projects do as well. You just have to write your constructors so that they do little work (which is encouraged anyways) and use methods to initialize them. Having static methods that return an optional<T> is also pretty common. Of course you can also have constructors that do a ton of work, so you never know what is being done, exception handling everywhere to error handle all that code and not use move semantics or very old C++ versions. There are always ways to use a language in a bad way and get bad results. I am sure you have seen bad C code. Of course RAII is not simple. It's extremely complicated, which is why I consider it missing. Using a new language needs be justifyable by some significant added value.
dxuh 4y ago
My point was that I don't see much of a point in yet another language that is C with an extra 10%. There is another one like that almost every week. Plenty of applications that require manual memory management have been written in C++ or Rust, which do provide RAII. If you know that manual memory management is required for some applications, you also know it's not 100% of the code that needs it.
- gingerBill 4y ago
  Do you honestly think Odin is "C with an extra 10%"? Or any of the decent alternatives that are available (e.g. Zig, Jai, etc)? Because if you really think that is the case, you know nothing about these languages nor have ever used them. All of these languages provide a hell of a lot more than "10%". As for RAII, I do explain in another comments (https://news.ycombinator.com/item?id=32629951 https://news.ycombinator.com/item?id=32629951 & https://news.ycombinator.com/item?id=32631462 https://news.ycombinator.com/item?id=32631462) why RAII has alternatives and not necessary for every language. If you truly believe that RAII is necessary for you, then use a language that has it (e.g. C++, Rust, D).
- davedx 4y ago
  - jessermeyer 4y ago
    As someone who programs professionally in C but writes Odin as a hobby, Odin contributes more like 1000% ease of use, comparatively. And I bet that scales up even more on a team as compared to C. ASAN, complex build tools, undefined behavior, implicit type conversions, etc, each of these contribute substantial problems all on their own, and they basically don't ever arise in Odin from the start.
  - dxuh 4y ago
    You're right. I'm sorry. It got too heated below my initial comment and I got upset. I'm not in a good place currently and I should probably refrain from commenting at all. And yes, I am not fun at parties.

Kukumber 4y ago

How do you write your garbage collectors or RC without precise manual memory management? How do you render billions of vertices and maintain a gameplay loop under 8ms for AAA games without precise manual memory/layout management? Not everyone is writing websites in javascript

YuukiRey 4y ago
I guess they are referring to something like Rust which manages to "solve memory management" while still letting you write high performance code.
dxuh 4y ago
RAII is often optional automatic memory management, like in C++ or Rust. Both of these languages are used for AAA games and rarely used for websites. My point was that if you don't go as far as those two, there is just not much of a point to not using C instead.
- Kukumber 4y ago
  Rust is not used in the AAA industry, it was advertised by a company (Embark), but they ended up using Unreal Engine 5 for both of their new upcoming games
- godratio 4y ago
  NOT TRUE you would of course choose Odin over C unless you could not for some reason. Odin is 100x better environment to program in than C. C++ is used for AAA games. Rust is not really used if hardly at all because of the highly competitive and time critical nature and very much the need to change things fast.
pjmlp 4y ago
Here, a GC implemented in Oberon, a GC enabled systems programming language, https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kernel.Mod.txt https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne... For something more modern in D, also a GC enabled systems programming language, https://github.com/dlang/dmd/tree/master/druntime/src/core https://github.com/dlang/dmd/tree/master/druntime/src/core

samatman 4y ago

I don't think any feature should be a mandatory part of a programming language, provided its reasons for not including it make sense. I'm fuzzy on Odin, if you showed me some Odin and some Hare I bet I couldn't tell them apart, but it kinda looks like a nice C with syntax inspiration from Go and (hence) Pascal. A language like that, as long as the object code is correct, then hey, it's there for people who want it. I think Zig, which I understand better but don't use, has a good reason for not building in RAII. Zig has a "no allocation without an allocator" rule, and what's easiest to describe as native valgrind. It also has comptime, and RAII loses some conceptual simplicity when you start doing transformations between what-you-see and what-you-get. I think it's worth continuing to explore whether that's a sufficient approach to memory safety, rather than doing something which has already been done, prematurely. I happen to think it's a promising approach, favoring clarity and simplicity. We'll see. Zig can always add RAII later, and so can Odin. But at most once each, so it pays not to be hasty.

gingerBill 4y ago
Regarding Odin and Hare, I'd argue most people would easily be able to tell them apart from the syntax alone because the declaration syntaxes are quite different. And most people judge a syntax pretty much solely by the declaration syntax itself. Regarding RAII, I explain in another comment (https://news.ycombinator.com/item?id=32629951 https://news.ycombinator.com/item?id=32629951) the issues with RAII and what it requires to be useful. Odin has the similar rule of "no allocation without an allocator" but has the implicit `context` system which passes the current context's allocators around. Odin also has core library support for valgrind, callgrind, memcheck, and soon helgrind. Odin has features (which this article does showcase) which are akin to RAII but are not attached to the type system. And as I explained in the previous comment, RAII wouldn't even make much sense in Odin (or Zig for that matter) and would probably never a good idea to add it later. There are better alternatives to RAII for languages such as Odin and Zig.
- samatman 4y ago
  Hi Bill, wasn't intended as a criticism of either, or as an observation about the syntax choices, but rather as a way of saying how familiar I am with both: I could say some things about them which are accurate, but not tell code samples apart. RAII isn't something I happen to be looking for in a language, it kind of falls between Rust and your work in a way that I don't have a use for. It's an interesting domain, isn't it? You'll always have people reacting from the hip to the problems C has given us, but they'll be back a couple hours later to talk about the wonders of SQLite. SQLite got there by being careful and building tools to keep them out of trouble. I see an important role for languages which build those tools in, but don't try to replace a manual transmission with an automatic.

stjohnswarts 4y ago

I agree RAII at a minimum should be available, but why not just use c++ at that point? I'll just go to something like zig or rust that is established and has thousands of libraries available.

gingerBill 4y ago
I recommend reading my reply to another comment regarding RAII: https://news.ycombinator.com/item?id=32629951 https://news.ycombinator.com/item?id=32629951 Also the article itself demonstrates different approaches to achieve behaviour similar to RAII through the `defer` statement and `deferred_*` attributes.