I found the module system for C interop, quite innovative and was surprised to see that Rust didn't even have such a thing. If you compare bindgen to this approach, bindgen just seems like double work and harder to maintain autogenerated bindings.

I have seen both Zig and Swift use the module system very well despite several devs strangely saying its somewhat complicated, but when used for low-level development this makes Zig an interesting language to use for language bindings.

I wrote a library for ffi (nifs) in elixir using zig, and a long term goal is for it to be easier to use zig as an intermediary for c library ffi than it is to use c.

Already importing blas into elixir with it is crazy easy.

That sounds interesting. Do you have a link to a hex package or repo?

May I ask why people invent new languages rather than trying to extend or improve existing ones, like C?

You could argue that it's what these languages do, the C heritage is very strong in every one of them.

The problem is: do you want to maintain full backcompat or are you willing to break things to do it cleanly? If you do the former you end up with something like C++ which retains almost complete compatibility with C (but they you have a lot of baggage to carry around, which may get in the way at times) or you're willing to break things and then why not take the opportunity to improve the syntax and get rid of the cruft?

C is ancient now, its type system and its many quirks are quite far from the state of the art or language design, a modern language wouldn't have to mess with the nonsense that are, for instance, C arrays (including C++ which can't outright remove them but does everything it can to render them obsolete with std::vector and std::array).

An other big problem with C interop for newer languages is that while C itself is relatively small and easy the C preprocessor isn't. That's usually where the friction is, because if you want to maintain compatibility with C macros you have to choice but to implement the language syntax wholesale.

C was already ancient when it came to be.

In retrospective, the aversion of Go designers to current practices in other programming languages is quite similar to the aversion of them back when designing C, versus the other system programming languages that were being developed since 1961, like ESPOL, NEWP, PL/I, PL/S, BLISS.

C had a standard published in 2018. It's "ancient" in that it's not new, but not ancient in that it's abandoned or unused.

> If you do the former you end up with something like C++

That's a pretty awesome place to be, as C++ is one of the most successful programming languages in history.

Perhaps there are lessons there.

> or you're willing to break things and then why not take the opportunity to improve the syntax and get rid of the cruft?

Break things just for the hell of it is not much of a tech argument.

C is already pretty light, and already gave origin to successful programming languages such as C++ and Objective C. Unless you find a compelling reason to break backward compatibility in a very specific way, I don't see how that argument makes any sense.

> An other big problem with C interop for newer languages is that while C itself is relatively small and easy the C preprocessor isn't.

Arguably, the preprocessor is orthogonal to the programming language itself. I fail to see how that's relevant.

C++ is hugely successful, that's true, but is there a need for an other C++-style language? C++ already feels like 10 languages under a trenchcoat anyway, whatever your style you'll probably find a subset of it you'll like. I think it showed how powerful "C-with-classes-and-the-kitchensink" can be, and also the limits of the concept.

C is light but it does have some things worth breaking IMO. Type inference is something I dearly miss when I write C these days (and I do that a lot). C didn't have any generic programing for a long time (if you don't count macro soup, that is), now it has some very limited support but it still looks like banging rocks together compared to more modern languages.

C's unsafety is legendary, and segfaults a common problem even for experienced programmers. Rust's lifetimes makes them impossible by design for safe code.

You may not like that of course, but those are all good reasons for experimenting with other paradigms.

>Arguably, the preprocessor is orthogonal to the programming language itself. I fail to see how that's relevant.

Arguably it is, practically it very much isn't.

Multiple attempts have been done to fixing C security issues, but the community at large tends to refuse to adopt them, so the only way forward is to create other languages for the same domain.

Note that Objective-C and C++ are extensions to the C language, and both started as pre-processors that would generate C code.

Also C wasn't the first on its domain, just got lucky that UNIX got widespread adoption and then found its way outside UNIX, just like JavaScript eventually found a way outside the browser.

> May I ask why people invent new languages rather than trying to extend or improve existing ones, like C?

Because extending or improving a language nearly always means breaking compatibility. Nearly every language is "stuck in a local optimum". To get out of it, you have to kill assumptions of the language that lead to this local optimum.

Also it takes a lot more work to convince other people to adapt my changes than to write an implementation of a language. Add to this the fact that being a good programmer and being a good politician are rather independent skills.

Finally, there do exist issues that cannot be fixed, for example that the official ISO standard of the C language is not freely available (I am aware that there exist drafts in the internet).

A great feature I find with Rust not being superset of an unsafe language, is that the only option for you is to write safe code (unless you explicitly opt for `unsafe`).

Compare this to merely extending a language e.g adding smart pointers - you could always (mistakenly) implicitly fall back onto bad coding practices.

Existing languages can't be meaningfully improved without breaking compatibility with all existing software. Python 3 is a better language in every way but it took many years before it saw significant adoption.

Here is a talk I gave that directly addresses this question:

https://www.youtube.com/watch?v=Gv2I7qTux7g

(the title & abstract in the youtube description is the one I gave for the RFP; I ended up going in a slightly different direction than it once I actually made the talk)

Many of the features of new languages are their restrictions. How would you restrict C in a new version to e.g. remove null pointers in favor of optional types?

Yeah, why did people not fix ALGOL instead of writing new ones like C?

C can't break backwards compatibility and remain C. So... how would you make language changes without resulting in the entire C++ mess new languages are trying to get away from?