With all the CVEs we see every month due to what can be only called design flaws in C, I have a hard time saying that C did fine for last 30 years.

For C+=1, I'd look at Zig; it unfortunately lacks the excellent corporate support that Go enjoys.

To me, Go looks much like early Java, only with a much better concurrency and saner "OOP". If anything, generics made Java better in many ways, without sacrificing performance or usability. It took 7 years for Java; it's going to take closer to 10 years for Go, bur better late than never.

> With all the CVEs we see every month due to what can be only called design flaws in C, I have a hard time saying that C did fine for last 30 years.

We can argue endlessly about which metrics of success are most important.

Zig looks cool. I've seen it mentioned a few times over the years. Looks like manual memory management is the default, yeah? That's important IMO if you're really trying to replace C. Rust is great but I just can't iterate fast enough (yet). Does Zig offer an optional GC?

EDIT: Also I never said Go is a good C replacement. But I'm finding it useful for some of those tasks and suspect it will be less useful for them down the road.

I think they're talking about the simplicity of C.

But yeah, I like to think of Go as a Java for the new millennium.

We're a Java shop and lots of people hate some of the newer changes to the language. And how OOP focused it is. I think Go would be a better fit because it seems to match the philosophy of our team more. But don't really think it's worth the switch for us.

I've used Java and Go. I find Go a far superior experience. Part of that is the standard library which seems to strike a perfect balance providing what you need but not too much.

I also think a lot of it has to do with the culture of the languages. Kotlin is a pretty nice language, but using it for Android still makes me want to hit my computer with a hammer because the over-abstraction of the Java ecosystem is maddening.

I was under the impression modern Java was becoming more functional than more OO (or at least de-emphasising inheritance).

That's definitely the path they're headed towards. @FunctionalInterface from Java 8 and type-inference from Java 11 and instanceof destructuring from Java 14 are the big changes. "Proper" modern Java is functional, at least at the surface level.

The big issue is that the ecosystem is kind of stuck; it's freaking 2021 and we're still targeting Java 8. Also the type system could be better, null references are everywhere even though there is Optional<T> (I wish it had optional strict null checks a la Typescript, but I'm not sure how realistic that is), and the fact that you can't have List<int> because generics won't work on primitives is just boneheaded.

But yeah, the language isn't the "Dog extends Animal" bullshit they teach you in school, at least not anymore.

It doesn't matter. Eventually you will need to use some library that's from the old days. You can't escape the abstraction. Not everything has been or can be updated to modern standards so just like C++ eventually every bit of the language ecosystem will come back to haunt you.

Go doesn't suffer from this yet because it's too new and the philosophy is different which keeps some of it at bay, but it's only a matter of time. Entropy always wins.

> The impulse to change things is just too strong these days.

FWIW, I don't think this impulse is there with the Go team. Go progresses quite slowly, from what I've seen as a user over the past 18 months. Generics have been in discussion for a long time with multiple implementations and no real rush to "just ship it".

I was referring to software culture in general, not Go specifically. Sorry I wasn't super clear.

Here are some news, we are already in C17, with ongoing work for C2X.