flysand7

My thoughts on this: only the database cares that an ID is an integer. Outside systems typically don't mind IDs as strings, so why not use strings? It's not like we're doing math on IDs

Not gonna lie, undoing bullets sounds like a fun gameplay mechanic

Can relate to this one though, when you push the code in production, pushing more changes just comes with so much more additional worries: Will it interrupt user's work on a live system, what about refactoring, changing API's that can break things. There's a fear that whatever you push next could break things really hard so you end up giving up the code cleanliness in exchange for mental rest.

I found the relevant research: https://www.pnas.org/doi/pdf/10.1073/pnas.0803650105

> Furthermore, there was no correlation between the position of roe deer and the time of day when the observation took place, meaning that the position of the sun had no influence on deer orientation.

Although I'm not sure how credible this information is given that they studied google images where who knows what time of day they are taking images at. Maybe there was a correlation.

I'm getting a timeout :)

That reminds me, emacs was truly the best Operating System.

I'll reply to this comment, just in case anyone else is curious.

The origin of the language: gingerBill got drunk one night and wrote a compiler. Seriously though, it was an attempt to create a language that would be a reasonable C alternative - simple semantics, usable for performance-critical applications (mainly games and engines), good support for tooling. I would also describe it close to something with underlying mechanics of C combined with the niceness of Go. Odin does improve on Go in a lot of places.

The use cases would be similar to C or C++. There's not much different in the way of memory management / the way objects are stored in memory etc. There is a concept of an allocator which could make Odin a better candidate for good performance when you allocate memory (i.e. putting everything on heap can be slower than bump allocators)

Some of the coolest features I've found using the language - bitsets (make a set of flags out of an enum), slices, which C didn't have but are so nice to use, the or_return, or_continue and or_break operator (hello, Go programmers, tired of writing if err != nil yet?).

Language comparisons:

unlike C: Has simpler syntax, easy to parse, has slices, bitsets, sized enums, templates.

unlike C++: doesn't have operator overloading, has simpler semantics, the standard library is readable.

unlike Rust: no borrow checker, limited lifetime checking (can detect using stack values that have dieded), no lifetime annotations, limited support for typeclasses, no pattern matching, no traits. I wouldn't compare it to Rust, honestly, it's a different kind of language.

unlike Go: I haven't used Go in a while so forgot a few details, don't quote me on these: it doesn't have var syntax for declaring values, you can not shadow tuple declarations at all, support for or_return syntax, tuple returns can be used to saturate arguments of another function, doesn't have garbage collection. Doesn't have a package manager.

> What matters much more are idioms, matching interfaces and descriptive names

Once you get over that as well, it's also quite liberating to not be bound by rules. This does go into unlawful-chaotic territory for some people though