I know it’s probably not the place for that post, but I’d like to see some more in depth discussions on various sections such as how Zig accomplishes some of it’s claims. For example, being faster than C; I see the discussion about UB allowing certain optimizations, but I’m curious about other areas that allow this performance. Or more safety discussion. I know Zig isn’t trying to be a safe language, but I believe safety is still a valid concern for all except maybe game-devs, so any thoughts on ways in which Zig could inch at being a safer C would be great.
Also the cross compiling appears almost magical (said in a good way!), I’d love to see more details on the implications of this. I.e. what are the trade-offs Zig is making if any to be able to support this. I assume there’s trade-offs, because otherwise other similar languages would probably be doing the same.
Quick feedback: you’re missing whitespace around your body content on my smartphone. Did you check how this feels on viewports smaller than your body’s max-width? Having the text come right up against the edge of the page feels wrong and unfinished.
Much more readable, good for a quick fix. You should try to scope the margin/padding just to the body content below the header, so the background can span the full width of the page.
@andrewrk Would it be a lot of work for you to add an android target to your awesome Zig cross-compilation machinery? Ideally, without requiring me to install the whole Android NDK? In my spare time, I’m working on a lean “toolchain” enabling building .apk files without having to install Android SDK nor NDK. Currently, I have working minimal prototypes of:
Now I need something that could build JNI .so files for Android, that I could embed in .apk files. Currently I’m generally targeting Nim, but it requires installing Android NDK, and I haven’t tested yet if the Android target is still working in Nim. If I could build Android .so JNI files with Zig, it could sway me its way… at least for this stage of the effort… and, once I get it to work, I would be more than happy to do a writeup for the Zig community on how to build Android APKs this way, kinda in return!… *nudge, nudge, wink, wink* also much tempting, no? ;P Also, maybe I could then make Nim use the Zig’s embedded C compiler instead of the Nim’s default GCC/MinGW, for some kind of an unholy marriage of Nim+Zig?
I’ll encourage you to check out DockCross. I was able to build Nim binaries for the android-arm64 target with minimal effort. Of course, it only has the r16 version of the NDK but maybe that’s a good thing? I don’t have any Android experience per se but maybe this helps.
Thanks! DockCross may be interesting, though rather as an intermediate step, as I’d prefer to avoid having to install docker as well. I’m aiming to minimize the size and dependencies. Did you manage to build a .so library usable in an .apk? That’s what I’m interested in for JNI.
This is definitely something I want to explore. I don’t have much experience with Android development so it would be a big time investment personally to look into this, but I would be happy to provide guidance to someone who wants to go down this path. If ability to cross compile for Android out-of-the-box added less than ~10MiB to the total download size of a given tarball on ziglang.org/download, I think that would definitely be worth it.
As for Nim they should just do exactly what Zig does and use clang/llvm libraries instead of depending on a system C compiler installation. I don’t see any advantages to the way they have it set up.
Hm; so, what would be the first steps I’d need to take, if I wanted to try exploring this path? Assuming I’m on Windows and have the Android NDK (or sources?) downloaded? I don’t have much experience with Android dev either, but willing to try and see how far I can get with some initial low hanging fruit(s).
The first step would be determining what is the ABI of those .so files. What functions do you need to export? What types do you need to know about? What are the files in the NDK and what are they used for?
What ABIs does native Android code have available to the system? Are they defined by the NDK? Are they stable? How often do they change?
In summary, the first step is figuring out, in low level details, how the whole thing works.
As to the ABI (and syscalls, etc.), I’d imagine that’s probably encoded in some patchset they maintain over Clang, no? Would you mean having to reimplement the whole diff, either by rev. eng., or by finding the sources of the actual patchset online and just grabbing them? Plus understanding them. I’ll try to look around if the patchset is somewhere to be found, hopefully it could shed some light.
edit: FYI & FTR, this seems to be a potentially good docs starting point for further reading and exploration. Though still a bit too high-level. A bit more is here. Anyway, the sources seem to be available. That said, given that I don’t have enough knowledge about clang, I don’t currently see clearly any low hanging fruits for me here, unfortunately. (Hmm, unless maybe cloning this and clang and running a diff? Hmm, but for this I’d need a Linux box…) So, for the time being, I think I’ll back off from this avenue. But I’ll keep it in mind, maybe it’ll grow on me enough to reevaluate it one day. Thanks for the heads up!
edit 3: There’s some more info how to retrieve toolchain sources; but it seems to use some repo tool, and I’m currently not able to understand how to dig up the actual eventual git repo & commits :( from it, I believe the clang sources are at: https://android.googlesource.com/platform/external/clang; IIUC the branch masterupstream-master might be “vanillla clang”, and dev or master might be with patches applied. Not confirmed yet.
I spent some time working through the 0.4 tutorial recently, and so far it looks really good!
One thing I couldn’t find though was documentation on importing external modules. Has there been any discussion on that topic already? Maybe any Github issue or something I could look at? Thanks!
Huh? That’s that the whole page is about. C doesn’t have: generic data structures and functions, compile-time reflection and code execution, order independent top-level declarations, non-nullable pointer types, allocator types, etc.
None of those things are “minor syntactic sugar”.
If you don’t understand what those things mean, then it would be better to frame your comment as an honest question. Otherwise, what you are asking is explained very well by the article.
Generics and non-nullable pointers are certainly not minor syntactic sugar, and to me they make Zig potentially more expressive and safer than C. Doesn’t hurt code re-usability either to have generic data structures.
the same features it already has, mostly, but with a self hosted compiler and better stdlib and tooling (like editor plugins). I’m not the person to ask. The biggest 1.0 feature is language stability, which is required for adoption.
More capabilities are planned. Clang does not support more than one sanitizer at once; if you want UBSAN and ASAN you’re out of luck. incorrect, see below
It also does not allow you to selectively disable checks in the bottlenecks of your code. also incorrect
UBSAN provides -fsanitize=unsigned-integer-overflow, which does catch unsigned integer overflow. I’m not sure what you exactly mean by invalid union field access, but UBSAN also provides -fsanitize=alignment which catches misaligned structure deferencing.
ASAN only catches memory errors, I don’t think it catches what you are referring to as invalid union field access, so still not sure what your point is about running ASAN and UBSAN simultaneous. As I said before, UBSAN is enough to replicate Zig’s features and much more.
Clang does not support more than one sanitizer at once; if you want UBSAN and ASAN you’re out of luck.
I stand corrected. I have corrected the misinformation in my posts, but you have not corrected the misinformation in yours.
UBSAN provides -fsanitize=unsigned-integer-overflow, which does catch unsigned integer overflow.
This is inherently flawed since unsigned integer arithmetic in C is defined to be twos complement wraparound. There will be false positives.
I don’t need to win this argument. I was misinformed on a couple points which make my position less of an open and shut case, fine. There are plenty of other talking points. See you in the thread for 0.5.0 release notes, I look forward to reading your comments then.
I stand corrected. I have corrected the misinformation in my posts, but you have not corrected the misinformation in yours.
What misinformation have I put forth?
This is inherently flawed since unsigned integer arithmetic in C is defined to be twos complement wraparound. There will be false positives.
Just because it’s defined doesn’t mean it’s intentional. In 80% of cases (read: pareto majority) unsigned integer overflow is not intended in C.
See you in the thread for 0.5.0 release notes, I look forward to reading your comments then.
Believe it or not, it’s not my mission in life to trash your language. I believe I gave fair feedback. Many of the people here may pretend to support you, but it doesn’t seem like many of them will actually use the language when asked directly. If you want to eventually appeal to the majority of real C programmers, and not a minority of hobbyist enthusiasts, it would be wise to not take negative feedback defensively.
To me it seems more like, for whatever reason/motivation, that you just came to this thread to do some trolling and to generally be combative with folks.
He just said in his opinion the features are not worth making the switch. That is just an opinion - an honest one at that. I don’t know if I would call it trolling…
Hmm trolling is defined as feigning a position in bad faith. I’m not feigning any position, I genuinely believe the feedback I am providing, and I’m providing this feedback in good faith. That’s actually the opposite of trolling. What statement specifically made it seem to you like I was trolling?
I somewhat agree that if you look from a big picture perspective, many of the features are just syntactic sugar. There are not significantly more things you can do with zig that you can’t do with C. I also think that the sum is greater than the parts, and all the ergonomic features will make a large difference in how pleasant it is to write code.
Things like defer statements and automatic error code types may be enough to push bug counts down for example.
Generics and a compelling dependency manager probably would be a fundamental shift in how people use the language vs C too.
Just try to imagine what kind of changes would be required for C compilers to implement this minor syntactic sugar. On top of all the things that were already mentioned, there’s some support for error handling and it seems to have some sort of type-interference.
It’s perfectly fine you don’t necessarily consider these features important enough to use Zig in favor of C but technically speaking, these differences are quite major.
Language processors, including compilers and static analyzers, often expand sugared constructs into more fundamental constructs before processing, a process sometimes called “desugaring”. […] This is, in fact, the usual mathematical practice of building up from primitives.
Transcompilation from Zig to C would be far beyond a simple expansion (assuming you don’t consider C to be a syntactic sugar for assembly in which case yes, it would).
C++ competed with C on the basis of having extra features like that. There’s a chance for Zig to as well, esp if maintaining simplicity.
Far as syntactic sugar, I think anything that increases productivity and maintainability is a net benefit. You might continue writing and rewriting more code in C for nothing to perform the same tasks. At same time, there might be other people who don’t want to work with 1970’s limitations if a language is available without them in 2019. They’ll gladly take a chance to reduce code required, make less breaking changes, and catch more errors at compile time.
The C standard isn’t simple. A subset of Rust might even be simpler than analyzing all that and the compiler behaviors. We’re talking a complicated language that looks simple vs another language that might be as or less complicated. Could be an advantage.
“and exclusively use Zig in all places you would have previously used C?”
You keep saying that but it’s nonsense. I always watch out for people saying a proposal should “always” or “never” be (property here). They’re often setting something up to fail rather than trying to understand real-world pro’s and con’s. The reason is that there’s a large variety of contexts that a solution might apply to… or not. There might be uses for C that a C replacement isn’t as appropriate for. Especially while the replacement is less mature without decades of ecosystem investment. More like there will be “some places” or “most places” to use Zig with others using C. Over time, some people might hit the “all places” point. Not a good starting point for evaluation, though.
Zig is an alpha language in development. C took some time to get where it is. You’re fine with that but Zig has to, in version 0.4, immediately replace a language with decades of development in all situations. You should ditch C, too, on that basis since people with high-level languages and efficient assembly were saying similar things about it early on. Alternatively, allow Zig a chance to develop and attempt to prove itself incrementally like C did.
Now be honest here, is Zig’s current language feature set compelling enough to reasonably consider it a replacement for C today?
Depends on the use case and compiler quality. I think one should assume answer is no by default until proven otherwise. It’s currently at a stage where hobbyists with an interest might apply it to various problems C is used for. That will produce the field data needed to evaluate what it can do now and how it might be improved.
You moved the conversation pretty far, though. You originally accused it of just being syntactic sugar vs C. That’s like saying C is just syntactic sugar for assembly knowing there’d be a lot of work making a compiler for that “syntactic sugar” to work vs doing all the same things as easily in assembly. Zig is doing a mix of syntax, semantics, and analysis to attempt to bring benefits over what C and its compilers do. The compile-time programming alone looks like a huge improvement over C’s preprocessor.
Depends on the use case and compiler quality. I think one should assume answer is no by default until proven otherwise.
Thanks for agreeing with me. By default I wouldn’t use Zig over C either. It might be useful if you let the creators know what it would take for you to generally default to using Zig over C.
That’s like saying C is just syntactic sugar for assembly
Nope, there is a specific definition of syntactic sugar, and C is most definitely not syntactic sugar for assembly. I would consider Zig’s small set of language features syntactic sugar for C.
If it is syntactic sugar, you should be able to throw it together in an afternoon or so integrating it with C. Nothing semantic or deep that poses challenges. Whereas, he’s been working on this full time for a language that already does things C cant without going far from the language.
with the exception of compile-time reflection, I can implement all of Zig’s language features in C using a combination of macros and a small support library
I don’t care about Zig one way or the other, but this is a gross misrepresentation. In Zig, quote, “A generic data structure is simply a function that returns a type”. You cannot implement that with a combination of macros. You could implement a set of predefined parameterised types (lists, sets, so on), but that is not the same thing as supporting declaration of generic types directly in the language, particularly with the flexibility that Zig does provide.
I know it’s probably not the place for that post, but I’d like to see some more in depth discussions on various sections such as how Zig accomplishes some of it’s claims. For example, being faster than C; I see the discussion about UB allowing certain optimizations, but I’m curious about other areas that allow this performance. Or more safety discussion. I know Zig isn’t trying to be a safe language, but I believe safety is still a valid concern for all except maybe game-devs, so any thoughts on ways in which Zig could inch at being a safer C would be great.
Also the cross compiling appears almost magical (said in a good way!), I’d love to see more details on the implications of this. I.e. what are the trade-offs Zig is making if any to be able to support this. I assume there’s trade-offs, because otherwise other similar languages would probably be doing the same.
Quick feedback: you’re missing whitespace around your body content on my smartphone. Did you check how this feels on viewports smaller than your body’s max-width? Having the text come right up against the edge of the page feels wrong and unfinished.
Thanks! I pushed an update. How’s that?
Much more readable, good for a quick fix. You should try to scope the margin/padding just to the body content below the header, so the background can span the full width of the page.
Oops, forgot a couple lines of CSS from the style editor. Fixed now, thanks again!
@andrewrk Would it be a lot of work for you to add an android target to your awesome Zig cross-compilation machinery? Ideally, without requiring me to install the whole Android NDK? In my spare time, I’m working on a lean “toolchain” enabling building .apk files without having to install Android SDK nor NDK. Currently, I have working minimal prototypes of:
Now I need something that could build JNI .so files for Android, that I could embed in .apk files. Currently I’m generally targeting Nim, but it requires installing Android NDK, and I haven’t tested yet if the Android target is still working in Nim. If I could build Android .so JNI files with Zig, it could sway me its way… at least for this stage of the effort… and, once I get it to work, I would be more than happy to do a writeup for the Zig community on how to build Android APKs this way, kinda in return!… *nudge, nudge, wink, wink* also much tempting, no? ;P Also, maybe I could then make Nim use the Zig’s embedded C compiler instead of the Nim’s default GCC/MinGW, for some kind of an unholy marriage of Nim+Zig?
I’ll encourage you to check out DockCross. I was able to build Nim binaries for the android-arm64 target with minimal effort. Of course, it only has the r16 version of the NDK but maybe that’s a good thing? I don’t have any Android experience per se but maybe this helps.
https://github.com/nim-lang/nightlies/blob/master/nightlies.sh#L136 https://github.com/nim-lang/nightlies/blob/master/dx.sh
Thanks! DockCross may be interesting, though rather as an intermediate step, as I’d prefer to avoid having to install docker as well. I’m aiming to minimize the size and dependencies. Did you manage to build a .so library usable in an .apk? That’s what I’m interested in for JNI.
This is definitely something I want to explore. I don’t have much experience with Android development so it would be a big time investment personally to look into this, but I would be happy to provide guidance to someone who wants to go down this path. If ability to cross compile for Android out-of-the-box added less than ~10MiB to the total download size of a given tarball on ziglang.org/download, I think that would definitely be worth it.
As for Nim they should just do exactly what Zig does and use clang/llvm libraries instead of depending on a system C compiler installation. I don’t see any advantages to the way they have it set up.
Hm; so, what would be the first steps I’d need to take, if I wanted to try exploring this path? Assuming I’m on Windows and have the Android NDK (or sources?) downloaded? I don’t have much experience with Android dev either, but willing to try and see how far I can get with some initial low hanging fruit(s).
The first step would be determining what is the ABI of those .so files. What functions do you need to export? What types do you need to know about? What are the files in the NDK and what are they used for?
What ABIs does native Android code have available to the system? Are they defined by the NDK? Are they stable? How often do they change?
In summary, the first step is figuring out, in low level details, how the whole thing works.
As to the ABI (and syscalls, etc.), I’d imagine that’s probably encoded in some patchset they maintain over Clang, no? Would you mean having to reimplement the whole diff, either by rev. eng., or by finding the sources of the actual patchset online and just grabbing them? Plus understanding them. I’ll try to look around if the patchset is somewhere to be found, hopefully it could shed some light.
edit: FYI & FTR, this seems to be a potentially good docs starting point for further reading and exploration. Though still a bit too high-level. A bit more is here. Anyway, the sources seem to be available. That said, given that I don’t have enough knowledge about clang, I don’t currently see clearly any low hanging fruits for me here, unfortunately. (Hmm, unless maybe cloning this and clang and running a diff? Hmm, but for this I’d need a Linux box…) So, for the time being, I think I’ll back off from this avenue. But I’ll keep it in mind, maybe it’ll grow on me enough to reevaluate it one day. Thanks for the heads up!
edit 2: As of Android 7.0: ”Clang has been updated to 3.8svn (r243773, build 2481030). Note that this is now a nearly pure upstream clang.”
edit 3: There’s some more info how to retrieve toolchain sources;
but it seems to use some repo tool, and I’m currently not able to understand how to dig up the actual eventual git repo & commits :(from it, I believe the clang sources are at: https://android.googlesource.com/platform/external/clang; IIUC the branchmasterupstream-mastermight be “vanillla clang”, anddevormastermight be with patches applied. Not confirmed yet.I spent some time working through the 0.4 tutorial recently, and so far it looks really good!
One thing I couldn’t find though was documentation on importing external modules. Has there been any discussion on that topic already? Maybe any Github issue or something I could look at? Thanks!
Zig Package Manager is one of the big goals of this release cycle. Until then it’s a bit of an unsolved problem.
Is there a Zig tutorial? Other than the big HTML doc page?
I’m not aware of any. I’ve just been following this page.
Language-wise, why would one use Zig over C? From this page, it doesn’t seem like Zig is different from C outside of minor syntactic sugar.
Toolchain-wise, it makes the case for why the
zigcommand is useful, which makes sense to me, since this is an area where C is deficient.Huh? That’s that the whole page is about. C doesn’t have: generic data structures and functions, compile-time reflection and code execution, order independent top-level declarations, non-nullable pointer types, allocator types, etc.
None of those things are “minor syntactic sugar”.
If you don’t understand what those things mean, then it would be better to frame your comment as an honest question. Otherwise, what you are asking is explained very well by the article.
[Comment removed by author]
Generics and non-nullable pointers are certainly not minor syntactic sugar, and to me they make Zig potentially more expressive and safer than C. Doesn’t hurt code re-usability either to have generic data structures.
[Comment removed by author]
When it reaches 1.0, yes, sure, anything to avoid C’s army of footguns.
What features in 1.0 are you anticipating?
the same features it already has, mostly, but with a self hosted compiler and better stdlib and tooling (like editor plugins). I’m not the person to ask. The biggest 1.0 feature is language stability, which is required for adoption.
What makes you think Zig is not stable enough today? For what have you used it?
Did you read this section? https://ziglang.org/#Performance-and-Safety-Choose-Two
Based on the fact that you’re saying “pet features” I think you either didn’t see this, or didn’t grasp the implications of this.
[Comment removed by author]
Have you ever tried to turn on multiple of the sanitizers at once?
[Comment removed by author]
Incorrect. UBSAN does not catch:
More capabilities are planned.
Clang does not support more than one sanitizer at once; if you want UBSAN and ASAN you’re out of luck.incorrect, see belowIt also does not allow you to selectively disable checks in the bottlenecks of your code.also incorrectUBSAN provides
-fsanitize=unsigned-integer-overflow, which does catch unsigned integer overflow. I’m not sure what you exactly mean by invalid union field access, but UBSAN also provides-fsanitize=alignmentwhich catches misaligned structure deferencing.ASAN only catches memory errors, I don’t think it catches what you are referring to as invalid union field access, so still not sure what your point is about running ASAN and UBSAN simultaneous. As I said before, UBSAN is enough to replicate Zig’s features and much more.
This claim is simply false, this works fine:
That’s also false, see
__attribute__((no_sanitize("undefined")))https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#id10I stand corrected. I have corrected the misinformation in my posts, but you have not corrected the misinformation in yours.
This is inherently flawed since unsigned integer arithmetic in C is defined to be twos complement wraparound. There will be false positives.
I don’t need to win this argument. I was misinformed on a couple points which make my position less of an open and shut case, fine. There are plenty of other talking points. See you in the thread for 0.5.0 release notes, I look forward to reading your comments then.
What misinformation have I put forth?
Just because it’s defined doesn’t mean it’s intentional. In 80% of cases (read: pareto majority) unsigned integer overflow is not intended in C.
Believe it or not, it’s not my mission in life to trash your language. I believe I gave fair feedback. Many of the people here may pretend to support you, but it doesn’t seem like many of them will actually use the language when asked directly. If you want to eventually appeal to the majority of real C programmers, and not a minority of hobbyist enthusiasts, it would be wise to not take negative feedback defensively.
To me it seems more like, for whatever reason/motivation, that you just came to this thread to do some trolling and to generally be combative with folks.
He just said in his opinion the features are not worth making the switch. That is just an opinion - an honest one at that. I don’t know if I would call it trolling…
Hmm trolling is defined as feigning a position in bad faith. I’m not feigning any position, I genuinely believe the feedback I am providing, and I’m providing this feedback in good faith. That’s actually the opposite of trolling. What statement specifically made it seem to you like I was trolling?
See sealioning
[Comment removed by author]
I somewhat agree that if you look from a big picture perspective, many of the features are just syntactic sugar. There are not significantly more things you can do with zig that you can’t do with C. I also think that the sum is greater than the parts, and all the ergonomic features will make a large difference in how pleasant it is to write code.
Things like defer statements and automatic error code types may be enough to push bug counts down for example.
Generics and a compelling dependency manager probably would be a fundamental shift in how people use the language vs C too.
Just try to imagine what kind of changes would be required for C compilers to implement this minor syntactic sugar. On top of all the things that were already mentioned, there’s some support for error handling and it seems to have some sort of type-interference.
It’s perfectly fine you don’t necessarily consider these features important enough to use Zig in favor of C but technically speaking, these differences are quite major.
From Wikipedia:
Transcompilation from Zig to C would be far beyond a simple expansion (assuming you don’t consider C to be a syntactic sugar for assembly in which case yes, it would).
C++ competed with C on the basis of having extra features like that. There’s a chance for Zig to as well, esp if maintaining simplicity.
Far as syntactic sugar, I think anything that increases productivity and maintainability is a net benefit. You might continue writing and rewriting more code in C for nothing to perform the same tasks. At same time, there might be other people who don’t want to work with 1970’s limitations if a language is available without them in 2019. They’ll gladly take a chance to reduce code required, make less breaking changes, and catch more errors at compile time.
[Comment removed by author]
The C standard isn’t simple. A subset of Rust might even be simpler than analyzing all that and the compiler behaviors. We’re talking a complicated language that looks simple vs another language that might be as or less complicated. Could be an advantage.
“and exclusively use Zig in all places you would have previously used C?”
You keep saying that but it’s nonsense. I always watch out for people saying a proposal should “always” or “never” be (property here). They’re often setting something up to fail rather than trying to understand real-world pro’s and con’s. The reason is that there’s a large variety of contexts that a solution might apply to… or not. There might be uses for C that a C replacement isn’t as appropriate for. Especially while the replacement is less mature without decades of ecosystem investment. More like there will be “some places” or “most places” to use Zig with others using C. Over time, some people might hit the “all places” point. Not a good starting point for evaluation, though.
[Comment removed by author]
Zig is an alpha language in development. C took some time to get where it is. You’re fine with that but Zig has to, in version 0.4, immediately replace a language with decades of development in all situations. You should ditch C, too, on that basis since people with high-level languages and efficient assembly were saying similar things about it early on. Alternatively, allow Zig a chance to develop and attempt to prove itself incrementally like C did.
[Comment removed by author]
Now be honest here, is Zig’s current language feature set compelling enough to reasonably consider it a replacement for C today?
Depends on the use case and compiler quality. I think one should assume answer is no by default until proven otherwise. It’s currently at a stage where hobbyists with an interest might apply it to various problems C is used for. That will produce the field data needed to evaluate what it can do now and how it might be improved.
You moved the conversation pretty far, though. You originally accused it of just being syntactic sugar vs C. That’s like saying C is just syntactic sugar for assembly knowing there’d be a lot of work making a compiler for that “syntactic sugar” to work vs doing all the same things as easily in assembly. Zig is doing a mix of syntax, semantics, and analysis to attempt to bring benefits over what C and its compilers do. The compile-time programming alone looks like a huge improvement over C’s preprocessor.
Thanks for agreeing with me. By default I wouldn’t use Zig over C either. It might be useful if you let the creators know what it would take for you to generally default to using Zig over C.
Nope, there is a specific definition of syntactic sugar, and C is most definitely not syntactic sugar for assembly. I would consider Zig’s small set of language features syntactic sugar for C.
If it is syntactic sugar, you should be able to throw it together in an afternoon or so integrating it with C. Nothing semantic or deep that poses challenges. Whereas, he’s been working on this full time for a language that already does things C cant without going far from the language.
[Comment removed by author]
I don’t care about Zig one way or the other, but this is a gross misrepresentation. In Zig, quote, “A generic data structure is simply a function that returns a type”. You cannot implement that with a combination of macros. You could implement a set of predefined parameterised types (lists, sets, so on), but that is not the same thing as supporting declaration of generic types directly in the language, particularly with the flexibility that Zig does provide.