Code Question

[mvanthoor]

Many things you might think to optimize in C are similarly pointless as they are optimized by the compilers - they are incredibly good at optimizing code.

I learned to program in the 90's (as a hobby) and later in university I studied computer science, down to processor architecture and how compilers behave in different architectures. Much of that knowledge is useless today, except if you're _writing_ a compiler. Most of the tricks and best practices I studied back then don't even apply anymore because the compilers optimize so much.

If you want to find something in a list in Rust, wouldn't Iterator::find be the way?

I wouldn't know. In my engine, I just type "go", and it finds a move for me. Somewhere

Without kidding: at some point, I'll have to go through the code and "un-C" it a bit. I wish I could use enums more, to differentiate between pieces and squares, but enums vs. ints and converting between them is a hairy and somewhat cumbersome topic in Rust. (Obviously, because in Rust, an enum isn't an int, so they don't mix like they do in C.)

[Terje]

Without kidding: at some point, I'll have to go through the code and "un-C" it a bit. I wish I could use enums more, to differentiate between pieces and squares, but enums vs. ints and converting between them is a hairy and somewhat cumbersome topic in Rust. (Obviously, because in Rust, an enum isn't an int, so they don't mix like they do in C.)

I found writing a chess engine in Rust very frustrating (enums not being ints as you say, usize required to index, traits can't be const (yet), etc). Kotlin, which I see as a Java equivalent to Rust, on the other hand, is an absolute pleasure to work with.

[mvanthoor]

I found writing a chess engine in Rust very frustrating (enums not being ints as you say, usize required to index, traits can't be const (yet), etc). Kotlin, which I see as a Java equivalent to Rust, on the other hand, is an absolute pleasure to work with.

I've had no problems with anything in Rust except for the fact that I'd love having enums as ints, and function overloading using traits. Maybe that will be possible at some point. I have no problems with either the type inference and having to use usize for indexing, though I think that, if you index using an integer, the "as usize" could be done automatically.

With regard to Kotlin... it runs on a VM / JVM. That alone is a reason for me to avoid it for personal projects. I'm already avoiding garbage collected languages. For me, it's either a non-garbage collected programming language or nothing. I've been toying with the thought of porting Rustic to C++, but it would be quite a bit of work just to have the same engine in a different language.