That works for me. The only downside I see with this is for others reading the package. If you see “append” being called somewhere, normally you would assume it’s the builtin one but in this case it’s the package defined one which is slightly less intuitive but honestly it doesn’t make enough of a difference to justify adding a new feature.
I think by “better alternative”, they mean for IDEs like vscode, neovim and helix which rely on an lsp to provide basic functionality like go to definition, symbol rename, and autocomplete.
It’s great if you use sublime text and get those for free but others have to rely on ols to get those features. Not everyone will want to use sublime to write odin so if ols didn’t exist they would probably be using a different language, and there are probably many who don’t use odin because ols is too buggy.
I know language adoption isn’t a primary goal for odin but a good lsp would go a long way.
noob here
So what’s wrong with ‘pattern matching’ that nearly every systems programming language designer seems to have a visceral reaction to it? This is like the third language where I’ve seen the designer react that way.
2 Likes
So “pattern matching” in itself isn’t necessarily bad whatsoever. Odin doesn’t have it because it doesn’t really make sense with the current language semantics.
But one aspect of pattern matching that some might dislike is that it does hide control-flow, or at least not make it obvious.
For it to make sense to have pattern matching in Odin, Odin would have to be a very different language in terms of how it feels.
3 Likes
Everything being public by default. Most things in your projects aren’t required to be public anyways.
1 Like
Well you can put a private what’s it called at top of all files 
I don’t like that I cannot reuse err like in Go.
Or more specifically, the := operator can only be all new variables instead of something like Go that is fine to have one of them being new.
It’s two operators: type and assignment operator respectively.
The := - that is combining the two, leaving out the type - is used for inferred type declarations → Overview | Odin Programming Language
1 Like
This was done on purpose to a certain extent. := is Go is a mess because it will secretly shadow a lot of the time. Which means I prefer doing var x, y = ... in Go rather than :=. But in some cases you have to use := because of the grammar.
In Odin := isn’t anything like Go’s :=. Odin’s := is actually two operators: : and =.
5 Likes
I dislike that, when I hit odin build or odin run, I get a blank prompt where nothing seems to be going on. Not for long, but - on my machine at least (15 year old ThinkPad) - long enough to ponder the meaning of life and everything . . . 
I am aware that it probably is not feasible with the current LLVM situation, and that the compiler shouldn’t be doing expensive IO, but a few dots printed to standard out once in a while would be nice! 
Addendum:
To continue the Hitchhiker’s Guide theme, it feels a bit like having to wait for Big Thought to come up with the Ultimate Answer . . .
Well, that’s a truly minor issue; the only one I can find with Odin so far!
1 Like
I know, I just don’t underatand why isn’t it default
1 Like
A bit late to the party, but probably the only thing I actively dislike is how case uses :
switch my_enum {
case .One:
// stuff
case .Two:
// stuff
}
Not a fan of how this looks, would prefer {} instead:
switch my_enum {
case .One {
// stuff
}
case .Two {
// stuff
}
}
The only time I can think of where this is somewhat less aesthetically pleasing is when using fallthrough.
To almost make your wish come true, you just need to add a colon per case. This is completely valid:
switch my_enum {
case .One: {
// stuff
}
case .Two: {
// stuff
}
}
I hadn’t thought about that. Fantastic, thank you!
1 Like
I think that the package declaration feels redundant.
I like how packages work, but I think that 99% of the time I want the folder and the import name to be the same, and aliasing is easy enough if I want to change the imported name.
And I think that mismatch between the package name and the folder creates confusion.
1 Like
Aren’t the import name and the folder name identical by defintion? I think the package name is not used for imports at all. I didn’t verify this though so I might be wrong.
No, the dir used for the import path, but the namespace is the package name.
1 Like
Oh! I see how that could cause confusion then. Thanks 
I will say the same I said about Zig: I do not enjoy explicit number casting. In practice I think it brings more “pain than gain”. That’s it I think :).
I am curious to hear other people’s experiences with the explicit casting, especially considering “autoboxing”/implicit conversion is so common in programming languages, that we should now have plenty of experience with both.
I have been using Odin for a year now, and I can’t think of anything I dislike. I do however have a pretty long list of gripes with C++, Rust and Python.
In the beginning of using Odin I did have a bit of friction with lack of methods & interfaces/typeclasses, since one has to learn/discover related procedures throughout the standard library. However now I prefer to not have them. The mess that comes with OOP is just not worth the price of limited convenience in the early stage of the learning curve. Odin thought me that I actually prefer simplicity of modules and generic procs.
3 Likes