Mind your language

[lucasart]

C isn't a bad language.

It has been in development for almost 50 years. It can be optimized down to the last instruction nowadays. It does show some cracks however. Setting up a working build system that works across compilers across operating systems is much harder in C than it is modern languages. (That is not a language problem per se; it could be done, but no-one seems to be doing it for C.) Writing C that doesn't create undefined behavior is hard. Writing C that is memory safe is harder.

C is not an easy language to use right.

Although I prefer Rust nowadays for several reasons, if it hadn't existed, I would have probably written my engine in C. The only reason for not writing it in C, is because there are so many C engines already.

On the one hand, I love C for all of its power it gives you over the computer, the simplicity of the core language, and the speed.

On the other hand, I hate C because it'll blow your head off if you put an * or & in the wrong spot. Under water, Rust basically has the same memory management, but it handles all of the * (derefs) by itself, except in certain cases.

Let's say you have:

x = &y;

If you now print x in C, you get the memory address of y. If you wanted y, you'd need to print *x.
In C, this is correct, because x DOES contain the memory address of y.

In Rust:

x = &y

means "x is a reference to y", not "it contains the memory address of y". Under water, x DOES contain the memory address, obviously, but because of the different philosophy, if you print/use x, you will get y in Rust; because the language assumes you want to be using the thing x references to, not that things memory address. (You can use the memory address if you want to, but that is not the default.)

C gets complicated if you have pointers to pointers... in Rust, the compiler keeps track of that for you, and does all the de-referencing automatically, to give you the original struct/stuff you're pointing to. (If you don't tell it to do something else.)

This, and the semantic code analyzer built into the compiler, are the two main reasons for me to prefer Rust nowadays. I can do without, and I can use C, but... well... maybe I'll port my engine to C at some point after I finish it, just to have a C version, but I don't know yet.

Code talks. Talk walks. Where is your RUST chess engine ? Show me the code, and we'll see if RUST is really "simpler" than C.

A few years ago, D was supposed to be the C killer (instead of C++ which everyone agrees is an abortion). Now D is dead, and joining the ranks of COBOL (according to TIOBE for what it's worth). And before that, there were countless others. ADA and Erlang for example, probably many more. Who's to say RUST won't bite C's dust like everyone else, and be the COBOL of the 2030s ?

[zullil]

C isn't a bad language.

It has been in development for almost 50 years. It can be optimized down to the last instruction nowadays. It does show some cracks however. Setting up a working build system that works across compilers across operating systems is much harder in C than it is modern languages. (That is not a language problem per se; it could be done, but no-one seems to be doing it for C.) Writing C that doesn't create undefined behavior is hard. Writing C that is memory safe is harder.

C is not an easy language to use right.

Although I prefer Rust nowadays for several reasons, if it hadn't existed, I would have probably written my engine in C. The only reason for not writing it in C, is because there are so many C engines already.

On the one hand, I love C for all of its power it gives you over the computer, the simplicity of the core language, and the speed.

On the other hand, I hate C because it'll blow your head off if you put an * or & in the wrong spot. Under water, Rust basically has the same memory management, but it handles all of the * (derefs) by itself, except in certain cases.

Let's say you have:

x = &y;

If you now print x in C, you get the memory address of y. If you wanted y, you'd need to print *x.
In C, this is correct, because x DOES contain the memory address of y.

In Rust:

x = &y

means "x is a reference to y", not "it contains the memory address of y". Under water, x DOES contain the memory address, obviously, but because of the different philosophy, if you print/use x, you will get y in Rust; because the language assumes you want to be using the thing x references to, not that things memory address. (You can use the memory address if you want to, but that is not the default.)

C gets complicated if you have pointers to pointers... in Rust, the compiler keeps track of that for you, and does all the de-referencing automatically, to give you the original struct/stuff you're pointing to. (If you don't tell it to do something else.)

This, and the semantic code analyzer built into the compiler, are the two main reasons for me to prefer Rust nowadays. I can do without, and I can use C, but... well... maybe I'll port my engine to C at some point after I finish it, just to have a C version, but I don't know yet.

Code talks. Talk walks. Where is your RUST chess engine ? Show me the code, and we'll see if RUST is really "simpler" than C.

A few years ago, D was supposed to be the C killer (instead of C++ which everyone agrees is an abortion). Now D is dead, and joining the ranks of COBOL (according to TIOBE for what it's worth). And before that, there were countless others. ADA and Erlang for example, probably many more. Who's to say RUST won't bite C's dust like everyone else, and be the COBOL of the 2030s ?

https://github.com/syzygy1/Rustfish

[lucasart]

C isn't a bad language.

It has been in development for almost 50 years. It can be optimized down to the last instruction nowadays. It does show some cracks however. Setting up a working build system that works across compilers across operating systems is much harder in C than it is modern languages. (That is not a language problem per se; it could be done, but no-one seems to be doing it for C.) Writing C that doesn't create undefined behavior is hard. Writing C that is memory safe is harder.

C is not an easy language to use right.

Although I prefer Rust nowadays for several reasons, if it hadn't existed, I would have probably written my engine in C. The only reason for not writing it in C, is because there are so many C engines already.

On the one hand, I love C for all of its power it gives you over the computer, the simplicity of the core language, and the speed.

On the other hand, I hate C because it'll blow your head off if you put an * or & in the wrong spot. Under water, Rust basically has the same memory management, but it handles all of the * (derefs) by itself, except in certain cases.

Let's say you have:

x = &y;

If you now print x in C, you get the memory address of y. If you wanted y, you'd need to print *x.
In C, this is correct, because x DOES contain the memory address of y.

In Rust:

x = &y

means "x is a reference to y", not "it contains the memory address of y". Under water, x DOES contain the memory address, obviously, but because of the different philosophy, if you print/use x, you will get y in Rust; because the language assumes you want to be using the thing x references to, not that things memory address. (You can use the memory address if you want to, but that is not the default.)

C gets complicated if you have pointers to pointers... in Rust, the compiler keeps track of that for you, and does all the de-referencing automatically, to give you the original struct/stuff you're pointing to. (If you don't tell it to do something else.)

This, and the semantic code analyzer built into the compiler, are the two main reasons for me to prefer Rust nowadays. I can do without, and I can use C, but... well... maybe I'll port my engine to C at some point after I finish it, just to have a C version, but I don't know yet.

Code talks. Talk walks. Where is your RUST chess engine ? Show me the code, and we'll see if RUST is really "simpler" than C.

A few years ago, D was supposed to be the C killer (instead of C++ which everyone agrees is an abortion). Now D is dead, and joining the ranks of COBOL (according to TIOBE for what it's worth). And before that, there were countless others. ADA and Erlang for example, probably many more. Who's to say RUST won't bite C's dust like everyone else, and be the COBOL of the 2030s ?

https://github.com/syzygy1/Rustfish

isnt't that's Ronald's code?

[lauriet]

I know it may not be a popular opinion but I think they should have had
Pascal 1
Pascal 2
Pascal 3
Pascal 4
etc etc.

But each to their own.............

[abulmo2]

Code talks. Talk walks. Where is your RUST chess engine ? Show me the code, and we'll see if RUST is really "simpler" than C.

A few years ago, D was supposed to be the C killer (instead of C++ which everyone agrees is an abortion). Now D is dead, and joining the ranks of COBOL (according to TIOBE for what it's worth). And before that, there were countless others. ADA and Erlang for example, probably many more. Who's to say RUST won't bite C's dust like everyone else, and be the COBOL of the 2030s ?

I wonder how D was a C killer yesterday and is dead now. D has never been as popular as now, although in the COBOL ranks of TIOBE index, or otherwise said as never been popular. D language is part of GCC since version 10 (the current version), and LDC 1.0 (the first "stable" LLVM based version) was released in 2016. So, although dmd has been in development for 20 years, it is easily available and working correctly on modern compiler for a few years only. So it just starts to be available on a large scale. Nevertheless, the popularity of a language should not be a factor in choosing it, at least not for a chess program, otherwise many chess programs will be written in Python (the most popular language on IEEE, PYPL, redmonk, etc. rankings).
Personnaly I miss the following from the D language in the C language:
- no header, no forward declaration
- no macro
- UFC (universal function call)
- array (real one with a known size, not a syntactic way to reference a pointer with an offset)
- multiple arguments function (varargs in C) done right
- no -> operator (the . is enough).
- CTFE (compile time function evaluation)
- string (much easier to manipulate than in C).
- etc.

[zullil]

C isn't a bad language.

It has been in development for almost 50 years. It can be optimized down to the last instruction nowadays. It does show some cracks however. Setting up a working build system that works across compilers across operating systems is much harder in C than it is modern languages. (That is not a language problem per se; it could be done, but no-one seems to be doing it for C.) Writing C that doesn't create undefined behavior is hard. Writing C that is memory safe is harder.

C is not an easy language to use right.

Although I prefer Rust nowadays for several reasons, if it hadn't existed, I would have probably written my engine in C. The only reason for not writing it in C, is because there are so many C engines already.

On the one hand, I love C for all of its power it gives you over the computer, the simplicity of the core language, and the speed.

On the other hand, I hate C because it'll blow your head off if you put an * or & in the wrong spot. Under water, Rust basically has the same memory management, but it handles all of the * (derefs) by itself, except in certain cases.

Let's say you have:

x = &y;

If you now print x in C, you get the memory address of y. If you wanted y, you'd need to print *x.
In C, this is correct, because x DOES contain the memory address of y.

In Rust:

x = &y

means "x is a reference to y", not "it contains the memory address of y". Under water, x DOES contain the memory address, obviously, but because of the different philosophy, if you print/use x, you will get y in Rust; because the language assumes you want to be using the thing x references to, not that things memory address. (You can use the memory address if you want to, but that is not the default.)

C gets complicated if you have pointers to pointers... in Rust, the compiler keeps track of that for you, and does all the de-referencing automatically, to give you the original struct/stuff you're pointing to. (If you don't tell it to do something else.)

This, and the semantic code analyzer built into the compiler, are the two main reasons for me to prefer Rust nowadays. I can do without, and I can use C, but... well... maybe I'll port my engine to C at some point after I finish it, just to have a C version, but I don't know yet.

Code talks. Talk walks. Where is your RUST chess engine ? Show me the code, and we'll see if RUST is really "simpler" than C.

A few years ago, D was supposed to be the C killer (instead of C++ which everyone agrees is an abortion). Now D is dead, and joining the ranks of COBOL (according to TIOBE for what it's worth). And before that, there were countless others. ADA and Erlang for example, probably many more. Who's to say RUST won't bite C's dust like everyone else, and be the COBOL of the 2030s ?

https://github.com/syzygy1/Rustfish

isnt't that's Ronald's code?

Sure. I thought you just wanted to compare Rust code to C code for a known engine.

[mvanthoor]

Code talks. Talk walks. Where is your RUST chess engine ? Show me the code, and we'll see if RUST is really "simpler" than C.

A few years ago, D was supposed to be the C killer (instead of C++ which everyone agrees is an abortion). Now D is dead, and joining the ranks of COBOL (according to TIOBE for what it's worth). And before that, there were countless others. ADA and Erlang for example, probably many more. Who's to say RUST won't bite C's dust like everyone else, and be the COBOL of the 2030s ?

You'll see the engine when it's done, somewhere at the end of the year. Development has been on hold because of vision problems and an upcoming cataract surgery. Development should resume somewhere in October.

Rust is not an easy language to start with. Actually, "being difficult" is one of the criticisms leveled most often against it. The language seems to be particularly difficult for people coming from (scripting) languages such as Python, JavaScript and PHP... and Rust is the polar opposite.

The main difference between C and Rust is that C lets you do everything you want, including blowing your own head off with regard to memory (mis)management. (Been there, done that... too many times to count.) In Rust, you HAVE to get it right and be memory safe, race condition safe, and thread safe. If not, the program won't even compile... and for people just starting out in programming, that makes Rust very hard to start with.

If one is a programmer who can write sane and safe C code (and thus really _understands_ memory management and computers), then Rust won't pose any problems; it will feel just like C with a different syntax and some extra stuff tacked on top. (Traits, methods in structs, etc...)

With regard to Rust surviving... I don't know. It seems most people go for the languages that are easy to start with, such as Javascript, PHP, Python, Kotlin, etc. I don't mind. Those languages are too slow for the programs I want to write. For me to consider a language, it has to be:

- Just as fast as C.
- Safer than C.

At this point, Rust is the only language that meets those criteria, it seems reasonably popular and in development, so I use it. If Mozilla stops to exist and Rust goes down the drain, I'll just port my code to C and then develop from there.