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.