Odin seems like a bunch of features copied from a bunch of different languages without making sure they're (a) good and (b) consistent. Things like ranges being `1..5` in one context but `1:5` in another, or having range-based iteration but still having classic for loops which ranges almost completely obsolete, or functions that may or may not allocate without having automatic deallocation. `or_return` is a significant improvement on Go's error system, but why not add an actual error system while you're adding other higher-level-than-C function properties like `context`? `cast(type)value` is a significant improvement on C's `type(value)`, but why add the latter syntax to the language anyway, then tell people not to use it? Allocator-aware new/free functions are great, so why use the different functions make/delete for some language-defined data structures? Etc. There's a lot to like here, but it's a patchwork with bad seams.
Every "feature" in Odin was added because it has been shown to be good and consistent with the rest of the language.
Slice expressions and range expressions being different was on purpose, as they are very different operations semantically and I wanted to make this clear with the syntax. You can try to unify them but then you lose the abilities to other things which make them distinct which the current syntax offers. It's allow about trade-offs.
Odin does allow you have custom iterators, and C-like for loops do have their uses at times.
`new` returns pointer. `free` takes a pointer. `make` returns a non-pointer data structure which contains internal pointers. `delete` will `free` the internal pointers for specific data structures.
As for the other criticisms, I recommend trying the language itself first to see why they are made. It is not always possible to just do a quick read of a language to understand its decisions.
>You can try to unify them but then you lose the abilities to other things which make them distinct which the current syntax offers. It's allow about trade-offs.
Can you give an example of such an ability and the kind of tradeoffs we are talking about here?
>It is not always possible to just do a quick read of a language to understand its decisions.
A successful programming language to me seems to be much more about being able to communicate the design clearly.
How is it data oriented in a way languages that don't call themselves data oriented are not? Which constructs do you have they are lacking? Concrete example of an algorithm that is now better/easier to implement?
I agree that some people are not very good at communication and might in theory or perhaps accidentally still be able to design a language with interesting choices, but the world will never know about it.
I don't feel you answered the questions fully. Telling someone to learn the language to get the rest of the answers isn't right and would put me off it because it suggests there aren't satisfactory reasons for the design.
I'm sure that's not the case but still.
I, on the other hand, am not in any way put off by someone not trying to answer every single part of a comment, when it starts out with "Odin seems like a bunch of features copied from a bunch of different languages without making sure they're (a) good and (b) consistent"!
> Things like ranges being `1..5` in one context but `1:5` in another
Is this true? Perhaps illustrate why "Slice expressions and range expressions [are] different was on purpose, as they are very different operations semantically". You should be able to clear that up easily by pointing to the language overview or something.
> but still having classic for loops which ranges almost completely obsolete
Is this unreasonable? And
> but why add the latter syntax to the language anyway, then tell people not to use it?
Same. If there are good reasons there should be good (and simple) explanations.
Questions like these should be an opportunity to clarify the whys of the language. Ignoring them is discouraging.
For slice expressions, the reason for the syntax was done on purpose for the following reasons:
* It's the same syntax as Go and Python, making it familiar to others who have used those languages
* It allows for partial ranges e.g. `x[:]`, `x[:n]`, `x[i:]`
* Partial ranges with the _two_ range expressions (a..<b and a..=b) look awful and are inconsistent: `x[..<]` `x[..=]`, `x[..<n]` `x[..=n]`, `x[i..<]` `x[i..=]`
* You effectively only ever want Python/Go like semantics with slicing because Odin is a 0-index language
* Ranges in Odin are only allowed in two contexts: `cases` and `for in` loops.
As for C-style for loops, they are not obsolete by any stretch and any one who thinks so in think that the compiler can easily optimize a magical complex iterator without any problem. In languages without C-style for loops, you'll see people try to emulate them regardless with variables and a while loop, not just an iterator.
As for syntax, where does it say "don't use it"? I really don't understand why people state things without evidence.
>As for C-style for loops, they are not obsolete by any stretch and any one who thinks so in think that the compiler can easily optimize a magical complex iterator without any problem.
In Nim, non-closure iterators are guaranteed to be inlined, so `for i in 0..<16` always compiles to what you'd write in C.
>In languages without C-style for loops, you'll see people try to emulate them regardless with variables and a while loop, not just an iterator.
There's no “emulation” going on. A C-style for loop is literally just different syntax for a while loop.
Interesting (funny) side note:
Niklaus Wirth did return the very same token named colon for ".." as well as for ":" in his Pascal compiler (page 24 and 25 in [1]). So back then you could have chosen whatever you prefer… :-)
Now that's pretty good. May I suggest if it's not there already to add it to the language FAQ?
> As for syntax, where does it say "don't use it"?
I was quoting the questioner in good faith. If I re-quoted something untrue, sorry. As for why people do things like that, yeah, seen that before and I can't explain it.
> As for C-style for loops, they are not obsolete by any stretch and any one who thinks so in think that the compiler can easily optimize a magical complex iterator without any problem. In languages without C-style for loops, you'll see people try to emulate them regardless with variables and a while loop, not just an iterator.
C-style for loops are used for three things:
- worse syntax for `for x in y..z`
- worse syntax for `for x in iterator` (although only C++ does this to my knowledge)
- being Clever, and the resulting code being unreadable
There's nothing to 'emulate'. C-style for loops are the ones doing the emulating, of range loops. It's just syntax for a particular kind of loop. There's nothing whatsoever different between a while loop and an infinite loop with a break condition, and there's nothing whatsoever different between a for loop and a while loop with a particular final operation.
But a while loop represents a construct that is useful more often than not, because you very frequently do want a break condition, while a for loop does not, because the condition-affecting operation is rarely at the end of the loop. It's precisely what I was talking about - adding it because C has it, and not because it is useful. Show me a use of a for loop that isn't an iterator and isn't a range, and I'll show you something that'd be far more readable as a while loop.
Oh, and Rust has conclusively proven that yes, you can in fact optimize ridiculously complicated iterators to tiny loops
> As for syntax, where does it say "don't use it"? I really don't understand why people state things without evidence.
You're right, I had it confused with a different feature: "The expression {} can be used for all types to act as a zero type. This is not recommended as it is not clear and if a type has a specific zero value shown above, please prefer that." Pretty much the exact same question, though.
> * Partial ranges with the _two_ range expressions (a..<b and a..=b) look awful and are inconsistent: `x[..<]` `x[..=]`, `x[..<n]` `x[..=n]`, `x[i..<]` `x[i..=]`
> * You effectively only ever want Python/Go like semantics with slicing because Odin is a 0-index language
It seems very odd to compare Odin's syntax with syntax that doesn't exist in any language, as proof that Odin's syntax is better. Why would you not compare it with the actual range syntax of a common language? Say, Rust. `x[a..=b]`, `x[a..b]`, `x[a..]`, `x[..a]`, `x[..]`, `for x in a..b`, `for x in a..=b`. I see no awful looking or inconsistent syntax there. The point is that no, there is no semantic difference between the two; a range of values between two endpoints is a universal construct, and iterating it means to scan across it, and slicing with it means to produce all the indices contained within it. And you say 'you effectively only ever want Python/Go like semantics with slicing' as though this wouldn't be true for range loops as well.
> Things like ranges being `1..5` in one context but `1:5` in another
I very briefly pondered this reading through, but from a different angle: Odin’s range value syntax is helpfully clear about inclusivity in a way I don’t generally expect, and felt that may be nice in an index access position as well. But I quickly winced at the notion of overloading that syntax for different semantic meanings.
I'm intruiged by the vendor libraries [1] and EmberGen is definitely a nice showcase they have [2]. It's a nicer C with similarities to Zig.
I'll definitely take a look. But I'm hesitant to fully dive in. I'm a bit overwhelmed by all the new "niche" languages coming out lately. Usually they have very valid use cases but mostly fall flat regarding tooling (debugging..), available libraries and documentation.
It takes so much time to really grok a new language and then the next new shiny thing comes out...
Not a criticism, but a general observation: it’s increasingly surprising to me, when looking into an unfamiliar low-level/systems language, to find that the language has WASM support but doesn’t shout it from their website. I’m sure that isn’t the most important thing to be preoccupied by, but it feels like a common enough ask at this point that I’d expect languages with a WASM story to make that fact easily discoverable.
All that aside, at first blush Odin feels quite approachable from mostly high level experience. I am (and probably at this point will forever be) intimidated by manual memory management, but otherwise I read the overview on my phone and… nothing feels hard to grasp, everything easily maps to concepts I already recognize, and the prose explanations are written well for an audience of me. And I want to emphasize: I read this on my phone and found it valuable, that’s an unexpectedly good walk up experience.
Exactly! I don't understand why modern languages can't make "print" simpler. Is it too much to ask to expose a print function in the default namespace?
It is too much to ask for because Odin is not trying to optimize for beginners nor is it trying to pollute the global namespace with things that require a large runtime. Odin is a systems level programming language and you may not want to use such a feature that uses RTTI in the first place.
Is doing `import "core:fmt"` or something else too much to ask for?
I just want a language to meet me half way. Very little is “too much to ask for,” but why not eliminate boilerplate? If it’s a special case, I will sacrifice a goat to the gods of engineering purity and hope they forgive me.
Oh nice, there are API docs now. I had seen the language before but was put off by lack of stdlib docs at the time (a complaint I also brought up about zig some years ago)
Definitely interested in taking it for a spin now.
> Odin is the C alternative for the Joy of Programming.
It is not intent on replacing C since that is not a feasible goal for any language. But making an alternative to C in the high performance modern systems is very much a feasible goal and Odin is such a language.
Go is an Garbage Collected language with object oriented features and CSP like concurrency semantics. Odin has none of these built into the language and never will. Go was designed to be a language for web server backends, not general systems level programming such as game development, graphics programming, kernel development, etc.
Odin has numerous features tailored for high performance, modern systems, along with numerous data-oriented things such as SOA data types, array programming, high control over memory layout and memory allocation, custom memory allocators, and much more!
