Hacker News Reader

Comment by oconnore | Hacker News Reader

I think the two main ones are Rust and Zig. This may be controversial (but it seems very obvious to me) that:

Rust is created in the same spirit that created and evolved C++: create a complex and featureful language that enables compiling your solution from a high level representation in an expressive/safe/performant way.

Zig is created in the same spirit that created and evolved C: create a simple language that allows you to directly and transparently represent and reason about what you want to have happen.

You'll probably think that one of these statements is more biased than the other, and that probably reflects your own preferences :)

View on HN

There's something to be said about philosophy of simplicity in C. However, C pretty clearly evolved into the opposite direction. This is nearly all due to compiler developers, and the fact that C has to cater to so many different hardware requirements.

Unlike C++, ISO C is nothing more than culmination of features that more than 1 compiler has implemented (and doesn't interrupt the compilation process of a micro-controller firmware that was released literally 40+ years ago). Anything else, is GNU C. And it is so incredibly complex and obtuse at times that clang still can't compile glibc after years of work.

Zig was not created with the same spirit that created and evolved C. Zig was created with the idea of a simple C, one that does not match reality, and frankly leans more on Go rather than C. Zig, Odin, V, nearly all these better-C languages are more inspired by Go itself, than what C actually is. What they want from C is just the performance; that's why they're so focused on manual memory management one way or another.

Zig borrows some ideas from go. Probably defer is the big one, but if you watch "the road to zig 1.0" you will understand that zig is not really a go derivate. Most things in zig are directly addressing issues in c.

If you squint zig's error return fusion looks a bit like go's tuple error return but it actually is more "first-classing certain c conventions" than "adopting a go pattern". Same goes for slices.

Most of C's issues were directly addressed in Go as well. Only, Go did away with manual memory management.

C never had the philosophy of keeping things simple through the years. If it did, we would not have time traveling UBs to begin with. The lauded simplicity and explicitness comes directly from Go, where the philosophy was crystalized and preserved very early on.

You might say it is semantics, to call improving upon C being a derivative of Go (with manual memory management). You would be partially correct, it is semantics, but one that holds up very well if you look at how languages developed over the decades.

> The lauded simplicity and explicitness comes directly from Go

I have two words for you: json marshalling

Go's defer is incredibly flawed:

1. It only allows function calls instead of any expression.

2. It allocates memory dynamically and attaches the function call expression to the function, rather than the current scope exit. This has surprising and harmful consequences if you use it inside a loop.

So, I wouldn't say that zig's defer is borrowed from Go.

Not in implementation but surely in spirit. Didn't you mention in road 1.0 that the idea came from go?

Edit: ok rewatched it and I didn't see that come up, i was just misremembering

I think a stronger statement is that zig is explicitly created to out-C c. Even the high level comptime stuff evolved out of simplification and explicit-ification of some opaque things that c (and especially c++) compilers might do.

Reply on news.ycombinator.com