I'm not particularly impressed by Odin but maybe i'm not the audience. If you like strictly procedural languages (or a die hard C fan) it's probably fine but it feels like a 'My First Language™' kind of project.
What I really miss are methods on structs a'la Go. Just simple receivers would be a great addition imho. Because of this choice, it's affected the entire stdlib and boy does it look old. Creating a typed variable to pass it to a stdlib init function (for allocation, etc) is terrible decision and it's everywhere. The stdlib looks muddled too.
Odin is obviously heavily inspired by Go (among others) but it's learned nothing of the lessons of the Go authors. For example, Odin is a larger language and has fewer features.
I got an ICE while compiling once and it reported something like `TODO(bill) support this`. Not a good look.
i think you probably just aren't the audience. most of the things you miss are things i either am neutral on or actually enjoy (having written about ~20K lines of odin).
the creating a variable and passing to the `init` procedure is something i actually like since it allows me to decouple my allocations and initializations in most cases (barring things that are backed by dynamic arrays like `core:container/queue`). it also ensures that the memory allocated by `init` procedures can outlive the structure that it was tied to, which is especially useful in the case of something like the string builder.
if you simply want "method-style" autocomplete (i'm neutral on that), ols also does support that with `fake_method_completion` where you type `<variable>.<whatever>` and all procedures that take a `T` or `^T` as the first parameter show up as options.
as far as having fewer features, i think it just depends on which ones you're talking about. imo, the odin generic system is much nicer to work with and the presence of real enums, bit_sets, enumerated arrays, `or_return` + friends, and a proper scoped-based defer (instead of go's function based) make it really nice to program in compared to go for me. that being said, the `core:thread` `Thread_Pool` is not a complete replacement for goroutines and i will say that the concurrency model of go works really well for a garbage-collected language. of course, the garbage-collected part there shows why something like goroutines don't really fit well in odin.
on internal compiler errors, unfortunately, in a pre-1.0 language, those are bound to happen. fortunately, the time to fix can often be measured in a matter of hours rather than days/weeks.
What I really miss are methods on structs a'la Go. Just simple receivers would be a great addition imho. Because of this choice, it's affected the entire stdlib and boy does it look old. Creating a typed variable to pass it to a stdlib init function (for allocation, etc) is terrible decision and it's everywhere. The stdlib looks muddled too.
Odin is obviously heavily inspired by Go (among others) but it's learned nothing of the lessons of the Go authors. For example, Odin is a larger language and has fewer features.
I got an ICE while compiling once and it reported something like `TODO(bill) support this`. Not a good look.
the creating a variable and passing to the `init` procedure is something i actually like since it allows me to decouple my allocations and initializations in most cases (barring things that are backed by dynamic arrays like `core:container/queue`). it also ensures that the memory allocated by `init` procedures can outlive the structure that it was tied to, which is especially useful in the case of something like the string builder.
if you simply want "method-style" autocomplete (i'm neutral on that), ols also does support that with `fake_method_completion` where you type `<variable>.<whatever>` and all procedures that take a `T` or `^T` as the first parameter show up as options.
as far as having fewer features, i think it just depends on which ones you're talking about. imo, the odin generic system is much nicer to work with and the presence of real enums, bit_sets, enumerated arrays, `or_return` + friends, and a proper scoped-based defer (instead of go's function based) make it really nice to program in compared to go for me. that being said, the `core:thread` `Thread_Pool` is not a complete replacement for goroutines and i will say that the concurrency model of go works really well for a garbage-collected language. of course, the garbage-collected part there shows why something like goroutines don't really fit well in odin.
on internal compiler errors, unfortunately, in a pre-1.0 language, those are bound to happen. fortunately, the time to fix can often be measured in a matter of hours rather than days/weeks.