Rust, Zig, C and why it is hard choosing a programming language.
I have been struggling to choose which language to use for my projects for a
while.

Technical Background
I started with C, 8 years ago, before quickly switching to Java instead.
Pointers and weird string formatting incantations were not for me at the time.

Eventually, I moved to Scala, which was a "Better Java with Functional
Programming". It delivered that. Less boilerplate, more concise code, less
mistakes. At the time, I was working on a game engine. I was not that far into
the project, only a couple months in. (ok, I guess I was pretty far >.>)

What Scala didn't give was speed. The engine was pressuring the garbage
collector and causing freezes. At the time, that was using the Java 1.7's
virtual machine. I assume it's better now, but a garbage collector won't be
faster than non garbage collected memory in almost all cases.

Following that, I moved to Rust after learning about the Amethyst Engine
which was still just starting out. I learned the language by reading the code
and quickly skimming through the official documentation.

I used that for a few years and it was mostly an improvement.
The code was running faster. However, writing code became slower.
After all, it is logical that having more control over what happens requires
more work on the programmer's part specify what should happen. The exception to
this is when there are defaults which you can override.

Anyway, eventually, during school, I did a couple hours of C for some homeworks.
Learned Zig in my free time by reading the short (nice!) and incomplete
(less nice!) documentation and by porting some Rust projects to Zig.

Eventually, the failure of getting donations to continue making FOSS programs
and working on Amethyst led me to job hunt. Beenox was the first serious
reply I got. The issue was that they use c++.

So I did what every sane person would do: I learned c++ in two days, did the
coding interview and passed easily. I still find this hilarious. :D

Even funnier is that I actually spend all my days writing C code in .cpp files.
So I'm actually a C programmer 8 hours per weekday.

I think all that background makes me somewhat well positioned to give my
thoughts on the ups and downs of the different languages from a "technical"
perspective.

Philosophical Background
This part is way more weird than the last.

I started, 8 years ago, wanting to make my own games because I didn't like
design decisions of... basically all the games I played.

My goal was to copy game general ideas and do it my own way.

Later, I became more ambitious and wanted to do a "Simulate as much as possible
of the world while being super duper hyper realistic" type of game.
If you know anything about me, you'd instantly know that I won't work on it more
than a week before giving up.

But, this does give an example of the mindset I was in: big dreams and big
complex projects.

Finally, I slowly "progressed" to my current phase: simplicity.
I try to take the core essence of games I like, create them in constrained
environments (like the terminal) and build an enjoyable experience.

Now, I care (and waste time thinking) about if using ncurses is worth the extra
lines of codes instead of using ansi codes directly.

That's weird, and a waste of time, and I know it. Please send help.

Comparison, finally.
ANYWAY, now the part you actually wanted to read!

Here are my thoughts:

C compilers are a must have on any linux or bsd system used for development.
There's a lot of C compilers and having diversity and standards is nice.
That's it for the upsides of C.

As for the downsides, it's annoying to crosscompile, extremely error prone and
verbose as hell. Don't get me started on weak typing, error handling or the
complexity of making simple macros not explode at the usage point.

Now for Rust, it's a really good improvement over C.
No need to manage memory but also no garbage compiler slowing everything down.
No need for header files. Strong typing. "Dangerous" operations gated behind
the unsafe keyword. An awesome pakag manager. A ton of community libraries.
Abstractions that don't slow (or just a tiiiiny bit) the program.

As for the bad, my main complaint is the complexity and verbosity.
Also, it has only one very complex compiler and I doubt anyone will try to
write a new Rust compiler before a while considering the complexity of the
task.
I won't actually complain about the fact I hit 75 compiler errors per hour on
average. I prefer to be warned that I do dumb code before I actually run it.

The verbosity, however, really wastes my time. I understand the design
decisions they had to take, but I'm not sure I agree with them.
For example, look at the following piece of code:
```
#[derive(Clone, Default, Hash, Eq, PartialEq, Debug)]
pub struct MyStruct<T> {
    pub a: T,
}
impl<T> MyStruct<T> {
    // Yes, I know derive-new exists. ;)
    pub fn new(a: T) -> Self {
        Self {
            a
        }
    }
}
```

For comparison, the equivalent piece of code in Scala looks like this
(probably wrong, but close enough. I have not touched Scala in years):
```
public case class MyClass<T>(a: T)
```

That's what I mean by verbose. In the rust version, I had to specify:
- MyStruct + Self 4x
- T generic 5x
- a field 3x
- a long derive which you really want to be using in libraries on most structs.

I'm really good at designing data structures from use cases I have, so
the main limiting factor here is typing speed.
Alternatively, the limiting factor is the amount of time I want to spend
writing neovim/kakoune macros and trying to remember them.

Also, maintenance time goes through the roof when you want to do something
as simple as adding a field or a generic. It scales really fast.

Specifying generic traits is also a big source of verbosity.
There's this thing called "trait bound propagation".
The basic idea is that if you have a generic struct or function requiring
a generic implementing one or more trait, everything depending or using that
struct or function has to also specify those traits.
```
pub struct World<T: Send+Sync+'static> {
    pub resources: HashMap<TypeId, T>,
}
impl<T: Send+Sync+'static> World {...}

// ...

fn add_resource_to_world<T: Send+Sync+'static>(resource: T, 
    world: &mut World<T>) {...}
```

That example is pretty dumb and doesn't make sense, but it shows the syntax.
If you want a better example, look at the amethyst_rhusics crate which makes
extensive use of generics and traits.

As for complexity, I mostly have issue with the two macro systems:
macro-by-example and procedural macros.

I won't go into details. In short, macro-by-example makes it really hard
to do loops over tokens, require advanced concepts like a "tt muncher".
Also it doesn't support inspecting the types of parameters passed to it, which
heavily limit how useful it is.

Procedural macros, on the other hand, sometimes allow inspecting types.
But that requires actually using a derive on every type you care about, which
is once again super verbose and not even possible in all cases.
Also, writing procedural macros is verbose to start with.

Don't let my complaints discourage you from using Rust, it's a great language.
I just happen to have used it a lot, so I have a lot to say compared to the
two other languages I talk about here, which I used much less.

Now, let's talk about Zig. I consider it to be in the middle between C and
Rust.

It has more safety than C through stronger types, but not as much as Rust's
memory safety features. It's community is much smaller than both languages,
but considering this is a younger language trying to fit in a place already
occupied by other languages, it is to be expected.

Types are more enjoyable to work with, but also somewhat less reliable than
Rust's. Types are just values that exist strictly at compile time, the
same way that a integer exists at runtime and can be interacted with.

There's no special syntax for types, so interacting with them is done the
same way as you would interact with regular run time code.

However, that also means that types are "duct-taped". You cannot specify
traits that you want the generic to have on the function signature.
However, you can create a compile time assertion verifying if the type
provided does implement the function that you need.

That's not ideal since two types can implement functions with the same
name that actually have different meanings. I guess that's more of a designer
issue however.

There's also the annoyance that instead of the following Rust code:
```
fn add<A: Add<B>, B>(a: A, b: B) -> A {
    a + b
}
```
You have to write code like this in Zig:
```
fn add(a: anytype, b: anytype) {
    if (std.meta.is_numeric_type(@TypeOf(a))) {
        return a + b; // will complain when you compile if it can't be done
    } else {
        // will complain when you compile if a doesn't have the .add function
        // or if it cannot be applied to b.
        return a.add(b);
    }
}
```

That's both nice and not nice. Nice because it's easy to use for things
other than + and .add. Not nice because when you have + and .add, you need
extra checks. Also not nice because the errors quickly get confusing as the
complexity and number of functions you require grows.

Another thing that is nice with Zig is the cross-compilation.
I have played with it a bit and hit less issues that I thought I would.

Conclusion..?
I don't have one.
Sorry. :D

I know I want to avoid C when possible, but I have not decided between Rust,
Zig, or another of the upcoming languages.

I'm conflicted between having more things already done for me, or having a
harder time using a language that is nicer (because it lacks documentation and 
community).

Until we meet again, baiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii.