if you go back to the times, where C compilers didn’t even had a warning for truncation, you’d know the pain of chasing missing bits in your bitmask just to realize that an unsigned long long got passed through a function which took an unsigned int, throwing away all the top bits resulting in a week of furious debugging whether the hardware is borked or not. 
All hail explicit casting… and even more love for explicit endianness. 
I do not need a time machine, I am normally programming in languages that do not require explicit casting, and so are most people. I do not think it is a good argument to bring up an anecdote about a bug, because you can do that with anything, including obviously manual memory management. These things are tradeoffs, and I think it should be justified an argument of net benefit, rather than potential benefit in some (possibly rare) cases.
True, but it’s also a misconclusion to say that “most people used to not having type conversions so it’s fine”, unfortunately majority of software today is either python or javascript, which doesn’t even have types (on the surface at least). And now they both have variants with types because of all the mess untyped programming languages come with… which if you think about it, is the extreme of “auto casting”.
And other than anecdotes, there’re an entire class of CVEs called “type confusion”. It’s not entirely number casting, but in a lot of cases CVEs triggered by truncation, mismatch in signed/unsigned value assignment, etc.
It’s a common enough issue in C/C++ that if you want to have a language in the same niche you add explicit casting to at least partially guard against it.
not a lanuage feature, however I dislike that printf like format string literals are not validated by the compiler
As I personally find I screw them up often enough that I’ve started hacking on the compiler to try add it
Part of the reason they are not validated is because as a user, you can even override that behaviour at runtime. We could add some intrinsics which give warnings for such things, but it’s not going to be perfect.
Also, try to prefer %v by default if you need to, if you even need to do printf style printing.
Well it’s not really a feature cause it ain’t there…
But I really dislike that Odin does not have a build system.
I can hear Bill’s voice in my head saying “Turns out you don’t really need a build system…”. I just disagree on that.
Even the example repository has .bat and .sh files so now that is your build system.
This makes me often write batch files hoping they will work cause I’m currently not on windows or the other way around.
Also I just compiled and I got something like ld: open() failed, errno=2 for .... because a folder in my build folder didn’t exists. Now I need to look up on how to make sure folders exists and so on.
This is a line from the example repository for example:
for /f "delims=" %%i in ('odin.exe root') do set "ODIN_ROOT=%%i".
bah…
I’m not against build systems, but rather Odin is trying to solve the 99% case.
And I have no issue with people needing an external build system if it is necessary. But is the argument that you want the “Build system” language to be Odin too rather than batch/shell/python/lua/etc? If so, sure, but what do you actually need to do that even in Odin? You probably have all the tools you need already.
And the for /f "delims=" %%i in ('odin.exe root') do set "ODIN_ROOT=%%i" example is more to do with batch being a crap language than “Odin needing a build system”.
da: [dynamic]string
append(&da, "This works!")
hm: map[string]int
hm["This also works!"] = 1
I realize Odin tries to make the zero-value useful, but this behavior is so unexpected (to me) that I’d rather it be an exception to the rule. Building up one of these structures in one spot of the code, then “moving” them to another place (assign to new struct, then nilling the original) is a pattern that will come naturally for people working in other languages; they will get bitten by this.
Personally, I don’t see any benefit to using these things without explicit initialization. I’d bet if this behavior toggled with the dynamic-literals flag you’d have fewer surprised people (but at that point the flag isn’t well-named etc.)
fair. I have to say I haven’t put any time in it to see how I can tailor it to my needs cause it’s hardly worth time spending on it. I am wokring on a project where at some point it might be worth spending a bit more time on it. Python might be indeed be a good candidate.
I mean, you could just take the nob.h approach and compile Odin with Odin. That’s what I do in my project whose building needs outgrew simple shell scripts because I needed to create a meta program that uses “core:odin/ast” package. The added bonus was that engine, game library, and editor library are now also built in parallel which sped up the whole process. Here’s the repo. I’m only posting this to give you an idea/inspiration. You shouldn’t use this in your own project because the library isn’t battle-tested (for one, I make an assumption that the user of this library won’t free the temporary allocator in their build “script”; I mean, why would anyone?).