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.
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.
* 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.
So your constructors don't do any construction?---defeating the entire point of a constructor.
> Yes, originally. Move-semantics are part of the language since C++11. Enough time has passed.
First, move-semantics solve a lot of the issues with copy-constructors in C++, as I previously stated. Secondly, what has time got to do with this? It's a solution in C++'s RAII with copy-constructors. Not the only possible solution but the one that the C++ committee settled on.
> 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.
I'm also assuming that your code base uses constructors and destructors all over the place and is absolutely fine with the added costs of constructors and destructors. And that's fine. But they are implicit and when reading the code, you don't necessarily know if a constructor is being called from just reading it. That is just a statement of fact and not really a criticism.
> 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.
Firstly, is the argument here to make constructors only do trivial things in?---(which rarely ever happens in practice, especially if you use anything from the STL). Secondly, many game devs usually have have an explicit `init` method too for the exact reason you can separate allocation and initialization, and have the ability to handle failure cases with `init`, usually with a return value indicating this failure state. You can have static methods, yes, but then you are literally getting around the construct of an implicit constructor and having an EXPLICIT construction call.
RAII itself is actually very simple, but to make it useful is complicated and complex. The issue with RAII is not necessarily the scope-exit semantics but rather coupling this within the type system itself as a way to have scope-hierarchical-based management of resources.
No one is expecting you to rewrite your entire project in Odin but those that are starting new projects have a high value choice with Odin and others.
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.
As for RAII, I do explain in another comments (https://news.ycombinator.com/item?id=32629951 & 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).
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.
I agree with OP, that Odin doesn’t go far enough toward safety in this regard. We do all require and desire security.
Memory safety and memory management are not equivalent concepts. As I state in another reply (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.
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).
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.