I've decided on a new content strategy for RUclips and it's to stop second-guessing myself and just have fun. You might not like it but this is what peak fun looks like. Thanks for understanding: I want it that way. edit: I screwed up the audio export and "audio swap" is no longer (/ never was?) a thing on RUclips so this video will be quiet forever. Except at the end.
In the same not second-guessing much vein, he accepted my suggested shitpost of a thumbnail 4 hours after the fact. I could conceive of someone finding it (~being in reference to a meme built ultimately on people laughing at poor i18n) in poor taste - so a) if you do, I should take more of your ire than Amos b) on the flipside, while I was writing that, I realized that in a way it also is more apropos than the mere word association I was going for, since the LLVM divorce is kinda an issue of shoddy localization 🙃 take off every zig!!
It's important to note that even though the zig command won't be using Clang's C/C++ compiler anymore, the zig command will *still* compile C. So it isn't like C compilation support will be dropped or anything.
Fun! But also seriously it does seem nice to have an alternate to LLVM around. I hear worst case they are making their codegen swappable, so you can still fall back to LLVM if you have a specific target their solution doesnt handle. Thats what i heard anyway, could be wrong.
DMD (dlang) has its own backend. That said it literally only supports x64, and is definitely not something you'd want to try to build a new LLVM competitor on, but hey. It is only ~700k LOC for the entire compiler, backend, documentation, and compiler tests, and is considerably more readable and approachable than the LLVM source code, or clang. Also worth noting since D basically invented (or at least pioneered + demonstrated) most of zig's feature set about a decade or so before zig showed up. Incl compile-time everything, conditional + looping CTFE, reflection, and codegen; and, generally, trying to replace C / C++ with (at the time) a much cleaner, easier to use, well defined, and (in at least D's case) a much more readable, concise, and 'sane' language. And builtin (and first class) unittests, and half a dozen other commonalities between the two languages. Overall a massive win for readability, expressiveness, and compression of program complexity into CTFE algorithms + templates, not verbose 'programming patterns' (or go-esque external codegen), much as zig is doing now. D also deserves a shoutout for having by far one of the nicest, and most readable! standard library implementations (ie phobos) out there. And for having better documentation and uhh actually useful compilation errors than zig does half of the time, lmao (zig's error model + lack of contextual information is a general problem when running into many kinds of library / usage errors, whereas D generally excels at this, but I digress) The D language at this point feels admittedly a bit dated. It was bleeding edge and great to use in ~2012, iirc, but presently suffers from having mostly missed the ML / FP language bandwagon, in syntax if not in semantics (the latter at least D more than makes up for in phobos), but painfully w/out 1st-class algebraic types and destructuring et al. But it nevertheless is a fairly mature and nice / fun to use language. That is, um, considerably more mature than zig, faster to write (albeit not necessarily test + validate) than rust, and which will (unfortunately) make the experience of writing c# utterly miserable / painful due to the sheer overlap in capabilities (and dozens of missing features, general clunkiness, and sometimes horribly slow performance - particularly for things like string operations + string formatting) of c# compared to d. Though on the +/- side D is / can be a full on C replacement and will happily segfault (though hey, so does zig) github.com/dlang/dmd dlang.org dlang.org/spec/betterc.html dlang.org/blog/2017/08/23/d-as-a-better-c TLDR; D has its own (excellent!) compiler backend, and that back-end exists for two, interesting reasons: 1) D was written and designed by a retired c/c++ compiler writer, and 2) the original DMD compiler backend predates all other LLVM-based languages, and in fact predates the LLVM project itself. The DMD backend is, ofc, inferior codegen vs LLVM or GCC, but is notable for being (afaik) one of the fastest compiler implementations out there, certainly for compiled languages with a similar-ish featureset + capabilities (c++, rust, swift, zig), and even for languages that aren't (go, and, iirc, even the c# AOT / JIT compiler). Much of that, iirc, has to do with extremely fast memory allocations (and basically cheating by never deallocating memory unless it needs to), very efficient string / parsing operations, and no dependencies on LLVM - all of which ofc zig could also achieve w/ a fair bit of work.
Worth to mention, although D has dmd (independent) reference compiler (with really fast compilation time), it also has LDC and GDC options with LLVM and GCC backends for optimised and release ready solutions. And moreover there is SDC - new independent compiler - which is a try to create more clear and simple structure of the code (than dmd) and test some new ideas of implementations.
Oh man, it's been a while since I last did D. I loved D back in the days, and vibe.d was a pretty impressive web framework. The whole async without actually needing separate async functions was so cool. Too bad it never really took off. I had built a few projects using it, but the lack of an ecosystem around it made it hard to keep using especially as a team.
I'm using D and I get 2x faster results with the LLVM backend than the DMD backend (which is nice since it also builds 2x faster). So the hope that Zig backend would beat LLVM seems optimistic to me.
he's clarified a lot of things in the thread for the issue. after those clarifications, the idea of "RIP Zig Gamedev" is no longer applicable. no use cases are going away. it seems they're planning to just package-ize llvm rather than making it a required dependency. you'll still be able to C/C++ with zig as the build tool, and fully integrate with them. and also (slowly) invest in building an LLVM alternative.
I'm not. I'm on of these who uses non x86, non arm and non Linux. So all I have is a custom gcc/llvm based toolchain. And I want multiplatform programs
Wasn't cranelift the streaming compiler build in rust for WASM (neither gcc nor llvm based) which people also want to add as a rust backend to get faster debug build at the cost of a bit less optimizations (and only modern "desktop/server" x86/ARM support)? I think the fully alternative rust gcc implementation was gccrs and another which just replaces the backend was gcc_codegen_rust or somthing like this.
What are the benefits of using a backend that is not LLVM? Isn't the whole point of a backend being language agnostic? For Zig to build their own backend would mean building a new backend for any other language, right?
I might be wrong but I think it might be that existing backends are not as agnostic as they once claimed they'd be and that they're much too tied to C++ style frontends.
LLVM is a toolchain, the main use cases of LLVM is the LLVM IR (aka Intermediate Representation) So basically you have a language let's say C, When C get compiled, LLVM compiles it to an Intermediate Representation which is both platform agnostic and language agnostic (think of it like a proxy language like Assembly but agnostic to any platform so it's very basic instructions that encapsulate the logic/behaviour of your code). The main point of LLVM IR is that instead of having every compiler people optimising code generation on a given platform and having to reimplement those complex optimisation for every other platform, you hand the task to the LLVM toolchain which will provide all of the platform/language independent optimisation (loop unrolling, dead code optimisation, boolean operation, pointer aliasing, etc etc) so it's a lot more easier to have a good compiler accros platforms.
I hope they don't and some other language does it because I enjoy zig and I like to use it for real, and as you mention cranelift has been worked on for like...4 years and is nowhere production ready and zig has nowhere the manpower to re-implement decent codegen fast. Like ideally is fire and I agree with your point, but realistically please don;t
The Odin programming language team is working on the Tilde Backend, which is also being used by a someone to make a C11 compiler, so that seems pretty interesting, and it is trying to compete with LLVM as well, in terms of optimizations at least, and I don't know about platform support.
What's the reason that you want an alternative to LLVM now? I want one too, but the reasons are that it's a pile of C++ and a C/C++ compiler without the frontend? What is that supposed to mean?
He uses Zig in one of his recent-ish articles and it definitely seems that way! Lots of shade lol, but at the same time a lot of echoing of what I felt when trying the language for a bit
Why? shouldn't we get ZIG LLVM to LLVM and merge it, so we have much better code optimizations for all Languages? Why the LLVM selfishness? Don't we all lose with such approach, a lot more than we gain, making all languages fast and optimized?
would this cause zig to loose it's ability to compile c code? not a compiler developer. but Odin is doing the same thing. so what is so bad about LLVM?
Nothing, but having more then one implementation can be really helpful. Currently rust has a semi-standard in form of it's RFCs but in practice it's more like "whatever the rust compiler does as long as people don't agree it's a bug". With gccrs being a fully alternative implementation it will be much easier to make sure what is implemented and what should be implemented do match. It's also more likely to find bugs in either compiler by comparing what the compilers produce or suboptimal too llvm specific design and similar stuff. Then there is stuff gcc is better at and stuff llvm is better at, targets only supported by gcc and such only supported by llvm. Potential better cross linking with C/C++ projects which use GCC/LLVM specific non standard features. Then the policitcal aspect of not being dependent on llvm. Or your code currently hitting a compilation bug with llvm, so you compile it with gcc and the other way around. And cranlift which AFIK is neither gcc nor llvm based might have way less optimizations and supported platform targets but compiles fast, which is grate for debug builds and some kinds tests which can speed up development workflows.
I've decided on a new content strategy for RUclips and it's to stop second-guessing myself and just have fun. You might not like it but this is what peak fun looks like. Thanks for understanding: I want it that way.
edit: I screwed up the audio export and "audio swap" is no longer (/ never was?) a thing on RUclips so this video will be quiet forever. Except at the end.
this goes hard please make more
i like this, feels a little short personally, but be free from the shackles of youtube!!
RUclips isn't for fun! Get back in the content mines!
👍
In the same not second-guessing much vein, he accepted my suggested shitpost of a thumbnail 4 hours after the fact.
I could conceive of someone finding it (~being in reference to a meme built ultimately on people laughing at poor i18n) in poor taste - so
a) if you do, I should take more of your ire than Amos
b) on the flipside, while I was writing that, I realized that in a way it also is more apropos than the mere word association I was going for, since the LLVM divorce is kinda an issue of shoddy localization 🙃
take off every zig!!
Suggestion: a series of how compilers and languages work in its core.
That would be incredible.
Yes, please!
I would watch a series by ftl on building an interpreter / compiler for a random language
it's not a video, but I'll highly recommend reading Crafting Interpreters, beautiful book.
@@sadhlife +1 to crafting interpreters. I'm a student and found the material very interesting and not too hard to grasp
It's important to note that even though the zig command won't be using Clang's C/C++ compiler anymore, the zig command will *still* compile C. So it isn't like C compilation support will be dropped or anything.
Amos I love your energy here. It seems like you are feeling good and I hope you really are.
Fun!
But also seriously it does seem nice to have an alternate to LLVM around. I hear worst case they are making their codegen swappable, so you can still fall back to LLVM if you have a specific target their solution doesnt handle. Thats what i heard anyway, could be wrong.
DMD (dlang) has its own backend. That said it literally only supports x64, and is definitely not something you'd want to try to build a new LLVM competitor on, but hey.
It is only ~700k LOC for the entire compiler, backend, documentation, and compiler tests, and is considerably more readable and approachable than the LLVM source code, or clang.
Also worth noting since D basically invented (or at least pioneered + demonstrated) most of zig's feature set about a decade or so before zig showed up. Incl compile-time everything, conditional + looping CTFE, reflection, and codegen; and, generally, trying to replace C / C++ with (at the time) a much cleaner, easier to use, well defined, and (in at least D's case) a much more readable, concise, and 'sane' language. And builtin (and first class) unittests, and half a dozen other commonalities between the two languages.
Overall a massive win for readability, expressiveness, and compression of program complexity into CTFE algorithms + templates, not verbose 'programming patterns' (or go-esque external codegen), much as zig is doing now. D also deserves a shoutout for having by far one of the nicest, and most readable! standard library implementations (ie phobos) out there. And for having better documentation and uhh actually useful compilation errors than zig does half of the time, lmao (zig's error model + lack of contextual information is a general problem when running into many kinds of library / usage errors, whereas D generally excels at this, but I digress)
The D language at this point feels admittedly a bit dated. It was bleeding edge and great to use in ~2012, iirc, but presently suffers from having mostly missed the ML / FP language bandwagon, in syntax if not in semantics (the latter at least D more than makes up for in phobos), but painfully w/out 1st-class algebraic types and destructuring et al. But it nevertheless is a fairly mature and nice / fun to use language. That is, um, considerably more mature than zig, faster to write (albeit not necessarily test + validate) than rust, and which will (unfortunately) make the experience of writing c# utterly miserable / painful due to the sheer overlap in capabilities (and dozens of missing features, general clunkiness, and sometimes horribly slow performance - particularly for things like string operations + string formatting) of c# compared to d. Though on the +/- side D is / can be a full on C replacement and will happily segfault (though hey, so does zig)
github.com/dlang/dmd
dlang.org
dlang.org/spec/betterc.html
dlang.org/blog/2017/08/23/d-as-a-better-c
TLDR; D has its own (excellent!) compiler backend, and that back-end exists for two, interesting reasons: 1) D was written and designed by a retired c/c++ compiler writer, and 2) the original DMD compiler backend predates all other LLVM-based languages, and in fact predates the LLVM project itself.
The DMD backend is, ofc, inferior codegen vs LLVM or GCC, but is notable for being (afaik) one of the fastest compiler implementations out there, certainly for compiled languages with a similar-ish featureset + capabilities (c++, rust, swift, zig), and even for languages that aren't (go, and, iirc, even the c# AOT / JIT compiler). Much of that, iirc, has to do with extremely fast memory allocations (and basically cheating by never deallocating memory unless it needs to), very efficient string / parsing operations, and no dependencies on LLVM - all of which ofc zig could also achieve w/ a fair bit of work.
Worth to mention, although D has dmd (independent) reference compiler (with really fast compilation time), it also has LDC and GDC options with LLVM and GCC backends for optimised and release ready solutions. And moreover there is SDC - new independent compiler - which is a try to create more clear and simple structure of the code (than dmd) and test some new ideas of implementations.
Oh man, it's been a while since I last did D. I loved D back in the days, and vibe.d was a pretty impressive web framework. The whole async without actually needing separate async functions was so cool.
Too bad it never really took off. I had built a few projects using it, but the lack of an ecosystem around it made it hard to keep using especially as a team.
I'm using D and I get 2x faster results with the LLVM backend than the DMD backend (which is nice since it also builds 2x faster). So the hope that Zig backend would beat LLVM seems optimistic to me.
big fan of this genre of videos where it's just guy being dude
Is the audio a little quiet on this one or is it just me 🤔
It's not just you. I forgot to re-enable some plug-ins in the final export and I'm working on swapping the audio 🙃
Turns out you can't!
he's clarified a lot of things in the thread for the issue. after those clarifications, the idea of "RIP Zig Gamedev" is no longer applicable.
no use cases are going away. it seems they're planning to just package-ize llvm rather than making it a required dependency. you'll still be able to C/C++ with zig as the build tool, and fully integrate with them.
and also (slowly) invest in building an LLVM alternative.
I'm not. I'm on of these who uses non x86, non arm and non Linux. So all I have is a custom gcc/llvm based toolchain. And I want multiplatform programs
Wasn't cranelift the streaming compiler build in rust for WASM (neither gcc nor llvm based) which people also want to add as a rust backend to get faster debug build at the cost of a bit less optimizations (and only modern "desktop/server" x86/ARM support)?
I think the fully alternative rust gcc implementation was gccrs and another which just replaces the backend was gcc_codegen_rust or somthing like this.
You’re correct! The editing is muddy but the GCC backends are the only thing I can think of while trying to recall cranelift!
What are the benefits of using a backend that is not LLVM? Isn't the whole point of a backend being language agnostic? For Zig to build their own backend would mean building a new backend for any other language, right?
I might be wrong but I think it might be that existing backends are not as agnostic as they once claimed they'd be and that they're much too tied to C++ style frontends.
LLVM is a toolchain, the main use cases of LLVM is the LLVM IR (aka Intermediate Representation) So basically you have a language let's say C, When C get compiled, LLVM compiles it to an Intermediate Representation which is both platform agnostic and language agnostic (think of it like a proxy language like Assembly but agnostic to any platform so it's very basic instructions that encapsulate the logic/behaviour of your code). The main point of LLVM IR is that instead of having every compiler people optimising code generation on a given platform and having to reimplement those complex optimisation for every other platform, you hand the task to the LLVM toolchain which will provide all of the platform/language independent optimisation (loop unrolling, dead code optimisation, boolean operation, pointer aliasing, etc etc) so it's a lot more easier to have a good compiler accros platforms.
More songs at the end of the video please. That was hilarious!
I hope they don't and some other language does it because I enjoy zig and I like to use it for real, and as you mention cranelift has been worked on for like...4 years and is nowhere production ready and zig has nowhere the manpower to re-implement decent codegen fast. Like ideally is fire and I agree with your point, but realistically please don;t
maybe in 5+ year ??? lmao
The Odin programming language team is working on the Tilde Backend, which is also being used by a someone to make a C11 compiler, so that seems pretty interesting, and it is trying to compete with LLVM as well, in terms of optimizations at least, and I don't know about platform support.
Idk anything about zig and llvm but this is a great video and I've never even played Zerowing either! Also good singing, that was premium! 😂 ❤
What's the reason that you want an alternative to LLVM now? I want one too, but the reasons are that it's a pile of C++ and a C/C++ compiler without the frontend? What is that supposed to mean?
Competition is the way to go, competing ideas
Andrew put out an answer that Zig the tool will still work with C++ if you read the issue.
The myth, the legend is back
Woo
Wowee
Hot dang
people should be more willing to build everything things from scratch
Incredibly based
This Rustacean wants to ruin our beloved Zig on purpose! 😜🤪
He uses Zig in one of his recent-ish articles and it definitely seems that way! Lots of shade lol, but at the same time a lot of echoing of what I felt when trying the language for a bit
Why? shouldn't we get ZIG LLVM to LLVM and merge it, so we have much better code optimizations for all Languages? Why the LLVM selfishness? Don't we all lose with such approach, a lot more than we gain, making all languages fast and optimized?
What did you mean at 0:55 where you didn't have a lot of respect for zig before this?
I'm guessing the emphasis is more on interest than respect, considering he said both
win-win-win scenario
Le chapitrage est la partie la plus drôle 🤣
I don't get why killing C++ in zig should stop gamedev in zig, but than again all the little gamedev I ever did was using C or zig+pure C libraries
Go look at the top 3d engines (Unreal, Unity, Godot). They are all built in C++ and a lot of libraries only have C++ abis
would this cause zig to loose it's ability to compile c code?
not a compiler developer. but Odin is doing the same thing. so what is so bad about LLVM?
its heavy.
reinvent all the wheels
Sometimes it's better to reinvent the wheel if that means you are no longer going to be constrained by the old solutions and their shortcomings.
@@maksymiliank5135 but spending all your time reinventing wheels?
"The breakings will continue until morale improves." - andrewrk, #14498
Sorry why is LLVM bad?
it's extremely slow
@@jalalle1995what?
@@DBGabriele Compiling LLVM is slow. But runtime performance is amazing.
So many things to be implemented in the language and they are wasting time on this... what a disappointment.
And what's wrong with LLVM?
Nothing, but having more then one implementation can be really helpful.
Currently rust has a semi-standard in form of it's RFCs but in practice it's more like "whatever the rust compiler does as long as people don't agree it's a bug".
With gccrs being a fully alternative implementation it will be much easier to make sure what is implemented and what should be implemented do match. It's also more likely to find bugs in either compiler by comparing what the compilers produce or suboptimal too llvm specific design and similar stuff.
Then there is stuff gcc is better at and stuff llvm is better at, targets only supported by gcc and such only supported by llvm. Potential better cross linking with C/C++ projects which use GCC/LLVM specific non standard features.
Then the policitcal aspect of not being dependent on llvm.
Or your code currently hitting a compilation bug with llvm, so you compile it with gcc and the other way around.
And cranlift which AFIK is neither gcc nor llvm based might have way less optimizations and supported platform targets but compiles fast, which is grate for debug builds and some kinds tests which can speed up development workflows.
Hm if Zig loses game dev i would be disapointed
Cool thing, but will probably kill adoption
Wish he still made videos.
This can make Zig a lot funnier, I use arch btw