The Odin Programming Language
odin-lang.org
odin-lang.org
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.
> 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.
* 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 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.
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.
[1] https://www.research-collection.ethz.ch/bitstream/handle/20....
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.
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 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'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...
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.
The Odin Programming Language (143 comments )
https://news.ycombinator.com/item?id=22199942
Looking into Odin and Zig ( 27 comments )
Is doing `import "core:fmt"` or something else too much to ask for?
import "core:fmt"
print :: fmt.println
// you can use print("test") now
Definitely interested in taking it for a spin now.
I love the IDE-style debugging.
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.
"It is designed with the intent of replacing C with the following goals:.."
Anyway, this looks really cool!
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!