What do you mean exactly?
916 karma · joined March 31, 2014
It's not trying to be memory safe, but rather try and catch many common mistakes that C does not catch easily.
As for use-after-free, I'd argue that is more of a problem with the memory allocation strategy in a language like C or Odin. And a change to something like an Arena like memory allocation strategy or something else reduces issues like that by a hell of a lot. `malloc`/`free` like approaches to memory allocation make use-after-free a lot more common because it making you micromanage allocations on a per-value level rather than on a per-shared-lifetime level. It's rare a single value has a unique lifetime, and I'd argue never in many projects.
For Odin native libraries, we usually for the convention of `snake_case` for variables and procedures and `Ada_Case` for types. However for anything that is third-party/foreign, we try to keep to the same convention as the original library to make it easier to people reference the original documentation, as well as not have any of the problems that certain naming conventions cannot be translated to another. So the raylib code uses the original raylib naming conventions because of the reasons I described.
My view is that the core of Pascal was actually the correct place to start rather than the core of C. C won out of Pascal purely because the original Pascal didn't fix its problems quick enough, and all of the successors also tried to focus on other fancier things like OOP or GC or whatever. C still remained "basic" and its preprocessor allowed for enough extensions for lacking language features, whilst not adding any of those fancier things.
For Odin, I tried to take the lessons of what I and others were emulating in C and just make them core constructs. Odin initially didn't have many of the constructs it has now such as parametric polymorphism or explicit procedure overloading, but all of them came about as a result of solving the problems people used the preprocessor for or other new features. For example, the explicit procedure overloading came about seeing how people use the (relatively new) C11 `_Generic` feature, and realizing that they were trying to emulate this aspect pretty much.
Odin also took a lot of the GNU C extensions and incorporated them directly (some of which are not in the latest version of C): `0b` literals, nested procedures (but not scope capturing), `type_of`, `case` ranges (`..<` and `..=` in Odin to be more explicit about the range bounds), array initializes with ranges, unnamed structs/unions, empty structs, and so much more.
Odin isn't a C++ alternative by any stretch, but I have seen a lot of C++ programmers really like it because it feels like it has just enough to make them feel at home whilst still have the control and more explicitness that C offers.
People who want CTTI is because they think it will produce better code because it is specialized for that type, and that is partially true, but also it will produce a hell of a lot more code. The canonical example of what I mean is the difference between doing something like `core:fmt` in Odin, which is a fixed cost at both compile-time and run-time, and then doing something closer to `std::format` in C++ (or other similar things in other languages) which will do a specialized procedure for each set of argument types. The former might be a huge initial cost if you only have a single type you want to print, but that cost is always the same regardless of many more types you add, it's also easier to debug. The latter is a small initial cost per type, and when the types get more and more complex, you also produce more and more code, which in turn increases the compiling time and binary/executable size.
As for the conditional imports, we did use to allow them but we found that what people were doing with them was kind of missing the point of the platform-specific features of the `package` system, and their code was always better if it actually utilized the package system correctly. There were some other quirks with the conditional imports which did confuse people because they didn't realize how things had to be executed (to allow for out-of-order type checking) and just disallowing it in the first place just solves that too (as a consequence, not as a goal).
Most open source projects are people who have dumped their unfinished project online, but it's hard to know whether or not it is finished until you use it, or worse, use it for a long time and find the gaping holes.
And without being paid, there is the issue that the maintainer doesn't work on the important things, since there is a lack of (price) signal to state what to work on.
But as I said to him, did he file an issue and when was this? Because it was probably fixed by now, and if not, we'll try to fix it straightaway.
The decision, which is not design per se, is to not have an OFFICIAL package manager, nor even endorse a third party one.
Odin isn't trying to be "impressive", it's trying to be productive as an alternative for C on modern systems.
Odin isn't my "First Language" and closer to my 20th.
Odin is just not for you. Your complaint about the lack of methods means you don't want a C alternative, and that is absolutely fine. I have nothing inherently against methods but I believe that if you are to add them, you cannot just have _mere methods_ but also have something to take advantage of them. But by the time you need such a feature (like typeclasses/traits), it becomes far from being a C alternative now and being something closer in the realm of Rust.
And what about the core library is muddled?
What lessons from Go did I not learn?—I'll take "fewer features" as a compliment too.
> I got an ICE while compiling once and it reported something like `TODO(bill) support this`. Not a good look.
Did you make an issue for this? And how long ago was this? Because this most likely fixed/implement now, and was probably fixed very quickly too.
Odin could trivially have a package manager and even one of the best support for it at the language level too because of how I designed what a package is in the language itself. I choose to not officially support a package manager because I don't want to encourage the path to hell.
This is one thing that really annoys me about Go, I am a competent programmer and I don't want be treated like an incompetent one. If I want vetting tools, I'll enable then when it suits me.
I do not personally use an LSP for my own personal reasons (I found I PERSONALLY was less productive with such tools). I am not against the concept of autocompletion tools like an LSP. If you are more productive using one, that is great!!! OLS exists but OLS is just not "official"—even if it is very good from what many people have told me. The only reason it is not official is that none of the core team worked on it, including myself.
As for QoL tools? Of course we want these but our philosophy is make sure the foundations are brilliant first before half-arsing the tool built on top of the foundations.
They talk about what makes a programming system suited to the native computing layer, interfaces for constructing software, visual programming vs visualizations of data, alternative input devices for programming, mapping programs down to the existing C-like tool chains, places to get started with compiler construction, and more.
Podcast Link: https://conversations.mr4th.com/2204443/15117568-boundaries-...
The `core:crypto` packages match that of the Botan ones (of which we support in `vendor:botan`). It's not about whether or it's a good algorithm or not, but that it exists.
Using your logic, Botan should remove most of its stuff too, but that would stupid to do.
Odin is fundamentally about simple as-in _intuitive_ to use, and intuition are anything but simple as-in _simplex_. Intuitions are extremely complex and complicated things, even if they seem "easy" to use.
Designing for people's intuitions about what feels right and feels "intuitive", is a lot more complicated than you realize. The entire constant value system requires a big-number implementation to get right.
Looking at the compiler for more than 10 minutes would you should that it is anything but trivial (I will refrain from using the term simple here since it is overloaded). Odin is more complicated than C, but less complicated than C++. That is both in terms of the language and the compiler itself. You can write a C compiler is <8KLOC (in C). It would probably take <50KLOC to write a _minimal_ Odin compiler (in C), if not more.
Trust me, as this is not as good of an idea as you think. You will just wrap it regardless unless it is absolutely trivial, which in those cases, you could have manually written the code to call the foreign code. And even if it was not as trivial, the types will be mostly wrong too, which means you'd need to correct them.
> Just recently I had a project that uses WebGPU
WebGPU is a mess regardless. Automatic bindings would still not work as you'd expect. For this specific API, we will add it to the `vendor` library collection along with all of the other graphics APIs. No one has gotten around to adding it yet, that is all.
To be clear, I am talking about a tool that will generate the Odin bindings for the specified C header(s). A magical "import c code", is what I am arguing against. It rare, if ever, that you need to regenerate the headers every single time you compile your Odin code, and that you don't even have wrap the code. Wrapping the code is effectively equivalent to just writing it yourself.
I am talking from experience from other languages. Pretty much every time those languages have the automagical C header importer, they either:
* The code had to be wrapped any way
* The types need corrected (thus wrapping)
* Rarely work correctly
* Missed code
* It didn't include everything you needed (e.g. preprocessor values as named constants, macros that were effectively normal wrappers, etc)
Another problem is that Odin does not support C's way of doing bit fields either, so some concepts will not map directly either. This means that Odin would have to completely embed the entire C type system as part of its language, rather than have those types be _compatible_ and _transformable_ with Odin types.
e.g. https://pkg.odin-lang.org/vendor/directx/d3d12/#ICommandQueu...
* command_queue^.id3d12commandqueue_vtable^.BeginEvent(command_queue, MetaData, pData, Size)
* command_queue.id3d12commandqueue_vtable.BeginEvent(command_queue, MetaData, pData, Size) // no need for the explicit dereferencing with ^
* command_queue.BeginEvent(command_queue, MetaData, pData, Size) // the vtable has `using` on it
* command_queue->BeginEvent(MetaData, pData, Size) // the -> operator will pass the value into the first argument
The `->` operator was added specifically for COM API stuff, and has been useful for the Objective-C stuff too.
As for TGA images, that is an image format that people still use, along with many others Odin supports. We want to be able to load an image regardless of its format, be it PNG, TGA, JPEG, etc.
As for a package manager, see my reply on another comment: https://news.ycombinator.com/item?id=38840407
TL;DR it does not make V, the community, nor the creator look good.
Not everyone wants nor desired to use a functional language. They might want or even need an imperative (and procedural) language. Odin is an imperative procedural language, and has no "functional programming" aspects to it. Odin is not of that tradition.
If you love functional programming languages and they are useful for solving your problems, then Odin is not the language for you, and that is absolutely great! Odin is for people who wanted a C alternative for systems-level programming, and thus an imperative procedural language is what they desire. And as such, Odin is not a mixed-paradigm language either, since it does not make sense for it (e.g. explicit manual memory management, imperative style, etc).
---
Isn't it great that there is choice now between programming languages?---in the domains people work in.
I have well over a decade of C++ experience, and the Odin compiler is written in C++. I agree having 1 de facto (not de jure) package manager is the best option. Making it official (de jure) does reduce the chances of de facto package managers from arising.
A lot of "core" isn't "Stuff Bill wanted". There are loads of things in there that I never use, but I feel is necessary for a "core" library. I didn't even write half of the core library, loads of other contributors did.
> But I'm not an Odin user, so there's no particular reason you should care what I think.
So why comment? :P
> What is the history of the project?
> The project started one evening in late July 2016 when Ginger Bill was annoyed with programming in C++. The language began as a Pascal clone (with begin and end and more) but changed quite quickly to become something else.
> Bill originally tried to create a preprocessor for C to augment and add new capabilities to the language. However, he found this endeavour a dead-end. That evening was the point at which Bill decided to create an entirely new language from scratch instead of trying to augment C
---
> What use cases are the language best suited for?
> Odin is a general-purpose programming language with distinct typing built for high performance, modern systems and data-oriented programming.
> Odin is the C alternative for the Joy of Programming.
Even though Odin is a "general purpose" language, in the same vein as C, many people have been using Odin for:
* Game Development
* Application Development
* 3D Graphics
* Physics
* etc