Das Better C: https://dlang.org/spec/betterc.html
It's essentially D without the garbage collector or D runtime library. Just the C runtime library.
Das Better C has C syntax and semantics, but leaves behind the C preprocessor. It adds modules, metaprogramming and memory safety (has bounds checked arrays, for example). C compatibility is arranged with ImportC.
Book by Alexandrescu was like a fantasy novel for young programmers in company where I worked.
One of us discovered this book and tell others. A bit later everybody was "infected".
Mostly javers and dotnetters and it was constant "Wow! It's possible to do such way? Why we don't do that?"
So, you influenced a lot of my friends in a right way.
Thank you!
To the best of my knowledge this is what Zig is trying to do.
[1]: https://go.dev/blog/5years
[2]: https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
I had to change my born name from Walter Dummkopf.
I don't really know what is missing on that front in DasBetterC. D can call any C code directly, D even has a built in assembler. D can import C code. And you can program free of the depredations of the C preprocessor.
When my dad was in the Air Force, the commander assigned Major Smart to be his office mate, for the sole purpose of putting "Bright & Smart" on the door. He figured nothing could go wrong in that department.
Zig is still in beta and has to reach 1.0, to even realistically enter such discussions (like you can with Rust), and it appears to be years away from achieving even that. C is at the top of the ladder, and Zig is around the bottom, trying to climb up. Zig is not even on many language rankings or at the bottom of them. It's not even anywhere near the top on just GitHub rankings, even when adjusted for year creation date.
The odds of making it to the top 5 languages used and widespread acceptance are very slim, no matter how much forced hype, zealotry, or evangelism.
But you're not the "nobody on GitHub" person I'm describing so I guess we need more people talking about and promoting Zig.
I suppose these things just take time.
In particular:
> So I wanted templates from C++. And atomics from C++11. But that's about it. Other than that, I want to code like I'm in C. The beauty of C-style coding is that the control flow is so simple, it's impossible to not know what code is doing. Contrast that with fancy C++ stuff and you never know what's going to happen or what each line of code is going to do.
> I figured out how to have my cake and eat it too. I discovered that you can compile with g++ and link with gcc, like so:
g++ -nodefaultlibs -fno-exceptions -fno-rtti -std=c++11 -c main.cpp -o main.o
gcc -o main main.o
> With clang it's even easier, just don't put -lstdc++ on the linker line.
As someone who cares about FFIs, I really hate C in that it is just so limiting in its ability to express FFI. C can't support things like multiple return values, unwind, or vector types (and this is before we get to higher-level language concepts!), and since most languages don't attempt to support an FFI interface that isn't based on C, you're stuck not being able to support these in your own interface. And worse, that we're largely stuck with the POSIX interface to the OS, we're forced to use unholy abominations like errno or POSIX signals that really should have died thirty years ago.
They're just not very popular.
(And well, I would like to add.)
Yeah because it would be a bad idea.
I think Zig is the best at pretending to operate with C, but it's still pretend. You need to do special stuff to interoperate with C.
Disclaimer: I'm biased because I'm trying make a C killer even better than Zig is.
It's called Yao. The main repo is https://git.yzena.com/Yzena/Yc , which is a monorepo that has other stuff as well.
Yao defines two types of files.
A "package" file defines stuff that a package can export. A package file looks like this: https://git.yzena.com/Yzena/Yc/src/commit/c0ade4cc5b/build.p... .
A "script" file is straight code, like a script. For a package, it is equivalent to `init()` functions for packages in Go. For a program, the main script file is the `main()`. A script file looks like this: https://git.yzena.com/Yzena/Yc/src/commit/c0ade4cc5b/build.r... .
Note: once the compiler/interpreter is at MVP, those two files will be working code. They will be the build scripts of the repo.
Speaking of the build scripts, the language has a way to allow users to define keywords. The build system already uses that to define its own keywords, turning Yao into a build system DSL.
(Yes, the first program written in Yao will be used to build Yao. It's a great test of the language.)
An example file, with explanation comments, is at https://git.yzena.com/Yzena/Yc/src/commit/c0ade4cc5b/src/yao... . All of the docs are at https://git.yzena.com/Yzena/Yc/src/commit/c0ade4cc5b/docs/ya... , but they are mostly design docs.
I think that should be enough links to get you started.
Pay particular attention to the example.y file w.r.t. C interoperability. The basic points are:
* Every function and type is associated with a C symbol, even if overloaded.
* Structs are laid out exactly like C. (There will be another compound type that won't have that guarantee, but it won't be default, and it, too, will have a C ABI.)
* It will have unions and enums like C.
* It will always use the C ABI, defining extensions to it for things like methods, and those definitions will be defined in the spec that every Yao compiler has to adhere to.
* It will always have the option to compile to C. C will be its bootstrap language.
That said, I still think there are many weaknesses in Yao compared to C. I don't have much confidence it will actually be a C killer, mostly because I'm not sure anymore that it is possible to add to C and kill it.
There is almost certainly SOMEONE out there, a random nobody on GitHub or elsewhere actually trying to write something that is as close to C in terms of philosophy and execution but utilizes some modern niceties, but I don't know who they are.
If you want to replace C, though, you actually have to get in C's skin, and undulate and move like C does.
But here's the kicker: absolutely no major language seems to want to do this, so they're all dead on arrival.
No other language has the same ability to interop with other languages. No other language gets nearly as close to writing something that you can have an idea of what the underlying assembly looks like when you write it. No other language seems to care about the surrounding ecosystems C operates in or think about topics like ELF/Portable Executable/Mach-O.
Why? Because all of them operate in their own little bubble. No other language wants to expose those details to you. They want you to operate in the world of MyWorldLang. What's "name mangling?" What are "shared libraries?"
But you can't displace C if you don't care at all about POSIX or FFIs or assembly output or the host OS, and none of them do.
If you operate in the world of VegetableLang, they want you to work with "CarrotLib" and "Tomato constructs," and "VegThreads." And all of this other nonsense that has nothing to do with hardware. And then we end up with all of this garbage software and fewer and fewer opportunities for people to learn how to utilize their hardware, because guess what, there is no abstraction layer that will automagically help you get your records into cache lines. You HAVE to count those bytes yourself somewhere, sometime.
C is so powerful and long lasting because people who want to displace C and related languages aren't even in the same ballpark. They're on another planet. In another universe. Apparently working with a CPU or RAM to them is like asking how relevant it is for someone to be able to throw a golf ball into a basketball hoop from the three-pointer line in the fourth quarter of a football game.