I just love how Andrew presented Zig: It's this thing that works🤣Not obsessed with terminology and trying to be elite. Open and welcome just as the community is. Can't wait for zig to reach maturity!
I'm a C++ programmer and basically youtube forces me to watch Rust videos again and again. Though I don't really like Rust at all. When youtube started feeding me Zig videos I actually find myself being interested in that simple not bloated language which is still modern. Will be checking on that language from time to time as it looks very promissing!
@@kissinger2867 , operator overload, inheritance and other object-oriented features. Which also rust doesn't fully have. While not everyone enjoys ducktyping simplicity, comptime is more attractive than consteval (not to be confused with constexpr) and the metaprogramming is softer.
I have only played a little bit with Zig, but I like it so far. It reduces complexity by providing everything in Zig: - No macros, instead you run ordinary Zig code at compile time which massages your code in the desired form with some sweet reflection at compilation time. Because types are values too, you can dictate with plain Zig code how your types should behave. - No 'makefile', but build.zig => that' s right also the build process is described by Zig code. - Even the documentation is pure Zig, just browse the standard library and the code is surprisingly concise and readable (OK, just kidding, there are already some useful 'standard patterns' available online, but if you happen to need something more in depth, the standard library source has helped me to clarify some concepts rather fast).
@@codingsafari As I understand it right now, both Go and Zig share the same philosophy of keeping their language small and simple and both aim to be an improved C. It makes only sense to prefer Zig over Go if you need to handle memory yourself, and if you need the added flexibility of compile time computation. Although experimental for now, Go has introduced arena allocation to its language, so it should be possible to benefit both from garbage collection and manual memory management at the same time, which makes it even more compelling to use Go.
@@jonathandero848Go was originally intended to be a C replacement but it's goals have changed over time. In its current state, Go is more of a replacement for Java than C. Some things off the top of my head that make Go a very poor C alternative. - Garbage collection and no fine-grained control over memory. Absolutely necessary for systems programming. - No way to call C/C++ code without ffi overhead (Foreign function calls were around 200x slower than Go function calls last I checked). - Go prioritizes compile times over runtime performance so Go compiler leaves a lot of code optimizations on the table. - No macros
how zig compares to odin language? i read a critic that the odin creator did on zig, and I finish reading confused. Im from oop world in java. But i wanted to learn C but then problem was that C is hard, and i wanted similar but easier and then found videos about zig, but now odin appears to claim to be simple too.
@@razorblade413 I have not played with Odin yet, but whenever in doubt: try to implement something simple that you are familiar with in both Zig & Odin. This will clarify a lot of frustrations/preferences from the beginning: acceptable compilation speed, language support in popular IDEs, package ecosystem + convenient package manager, online tutorials and good documentation, type system , standard library with batteries included?
Move the video to the bottom right corner. It would hide way less content. Or even better, make the slide a bit smaller, so the video does not overlap it. Thanks!
"Writing an Interpreter in Go" and "Writing a compiler in Go" by Thorsten Ball are really good, modern books on the topic. The compiler targets a custom bytecode. A 'true' backend might target x86 or arm64.
Andrew: On pronunciation of Vexu's name: Veikka Tuominen. This is a Finnish name so you actually say every letter (phonetic spelling!). It's like this: _vay - kuh_ . "Vay" rhymes with "bay" and "kuh" rhymes with "uh". And there's a somewhat noticeable pause between the two syllables, in order to emphasize the double k.
So, self-hosted refers to the zig compiler that's build using zig ? EDIT: found this info: Zig uses multiple compiler stages for bootstrapping the compiler: zig0: is just the c++ compiler as a static library only implements the backend for build-exe/obj etc stage1: is the current compiler, written in C++, compiled with Clang uses zig0 library to build pieces of stage2 in (subcommands like translate-c etc) stage2: is the current project, written in Zig, compiled with stage1 stage3: is the fully self-hosted, stage2 code compiled with stage2 stage1 doesn't implement full optimizations so stage2 binary is not optimized stage3 binary is optimized b/c stage2 implements optimizations/much better codegen
i enjoy using zig, but have stopped using it due to lack of documentation with std library.. i find it very frustrating.. i need to hop on to discord just to ask about basic thing about something that i dont understand in the std lib documentation.. hope they can improve that
Extensively documenting the standard library right now would be a bit premature. That will be done once the APIs are stable. In the meantime, the code of the standard library is very easy to read and understand. And also a great way to learn Zig and its idioms.
@@wobsoriano I find Rust community pretty toxic when you start asking questions they don't like, unless you join the hype train and also worship the language.
Allocating/Reallocating/Freeing things in lists of size of increasing/decreasing powers of two? Buddy memory allocator from The Art of Computer Programming, Knuth is your homeboy here.
Why do you have to clean up generated C code? Shouldn't it do the same thing as the clean Zig from which it was compiled? I probably don't understand the problem but aren't there already tons of tools that should enable you to compile Zig code to C (or to assembly which is then converted to C, or to DynAsm or something)?
Zig can already compile to C, no other tools needed. The point was to make that generated C code "human readable" so it can be maintained going forward and instead of the existing C++ codebase.
2 роки тому+4
@@jmc88dc Wouldn't it be a bit of a chore to always maintain two code bases for the compiler? I did not really get the point. Once you have a C back-end working it would be enough to have access to one zig compiler with this functionality running somewhere to be able to generate the C code to enable boot strapping for systems with only a C compiler. This could be done as part of the release process.
@ I think the idea is twofold: 1) the C code should map almost 1:1 to the original Zig code so that future maintenance is expected to be trivial, and 2) some software distributions may disallow software built from generated sources, so a hand-curated codebase might stay (at least for now, I'm also hoping that can be removed one day).
"Shouldn't it do the same thing as the clean Zig from which it was compiled? " The issue isn't what it does, it's what it looks like. "aren't there already tons of tools that should enable you to compile Zig code to C" Um, there's one such tool: the Zig compiler. "assembly which is then converted to C" Er, wut?
@@jmc88dc "the C code should map almost 1:1 to the original Zig code so that future maintenance is expected to be trivial" That's the idea, but it's cockamamie nonsense. Hopefully Andrew will realize that sooner rather than later. "some software distributions may disallow software built from generated sources" I can't imagine a distribution with such an absurd rule, or how "cleaned up" generated code wouldn't still violate it.
Idea for how to write the FuzzTester: take a random git project in Zig and start replaying commits from a random old commit. Some projects will be more suitable for this, those that have high commit-level granularity.
@@kibibu Yeah. The main branch could be used for that matter, as it is usually more or less stable. That's why I wrote that some projects would be more suitable than others.
I was really enjoying the talk until "lock-free data structures are bullshit" killed the whole thing. I mean, let's be serious: locking a mutex requiring you to context-switch to the OS will never be as fast as doing atomic operations. Unless you've been using it wrong the whole time, that's nonsense. It may hold some truth in specific use-cases, especially in kernel code but that's that. Or maybe everyone in the industry's been doing it and benchmarking it wrong for years. It all depends on the workloads and the access patterns (and how good your algorithm is :)
Andrew is a great speaker. What a joy to listen to him.
I completely agree.
I totally agree!
I just love how Andrew presented Zig: It's this thing that works🤣Not obsessed with terminology and trying to be elite. Open and welcome just as the community is. Can't wait for zig to reach maturity!
I'm a C++ programmer and basically youtube forces me to watch Rust videos again and again. Though I don't really like Rust at all.
When youtube started feeding me Zig videos I actually find myself being interested in that simple not bloated language which is still modern.
Will be checking on that language from time to time as it looks very promissing!
What features in C++ that you miss in Zig?
i love both zig and rust, what do you like about zig that’s different in rust?
@@kissinger2867 , operator overload, inheritance and other object-oriented features. Which also rust doesn't fully have.
While not everyone enjoys ducktyping simplicity, comptime is more attractive than consteval (not to be confused with constexpr) and the metaprogramming is softer.
@@MatheusCatarino Rust has operator overload and purposely avoids inheritance in favor of traits...
Danke!
Awesome. Been missing zig showtime lately, good to see this upload :)
Hi to all the zig fans tuning into Milan from around the world 🌎🌍
Thanks for uploading this. Good to watch it even if I cannot attend. Some other time, for sure!
Can't wait to meet you in person someday!
i love the vibes in that room! hopefully we can keep them as the community grows
As an aspiring language developer watching things like this is really inspirational, great talk
I have only played a little bit with Zig, but I like it so far. It reduces complexity by providing everything in Zig:
- No macros, instead you run ordinary Zig code at compile time which massages your code in the desired form with some sweet reflection at compilation time. Because types are values too, you can dictate with plain Zig code how your types should behave.
- No 'makefile', but build.zig => that' s right also the build process is described by Zig code.
- Even the documentation is pure Zig, just browse the standard library and the code is surprisingly concise and readable (OK, just kidding, there are already some useful 'standard patterns' available online, but if you happen to need something more in depth, the standard library source has helped me to clarify some concepts rather fast).
@@codingsafari As I understand it right now, both Go and Zig share the same philosophy of keeping their language small and simple and both aim to be an improved C. It makes only sense to prefer Zig over Go if you need to handle memory yourself, and if you need the added flexibility of compile time computation. Although experimental for now, Go has introduced arena allocation to its language, so it should be possible to benefit both from garbage collection and manual memory management at the same time, which makes it even more compelling to use Go.
@@jonathandero848Go was originally intended to be a C replacement but it's goals have changed over time. In its current state, Go is more of a replacement for Java than C. Some things off the top of my head that make Go a very poor C alternative.
- Garbage collection and no fine-grained control over memory. Absolutely necessary for systems programming.
- No way to call C/C++ code without ffi overhead (Foreign function calls were around 200x slower than Go function calls last I checked).
- Go prioritizes compile times over runtime performance so Go compiler leaves a lot of code optimizations on the table.
- No macros
how zig compares to odin language? i read a critic that the odin creator did on zig, and I finish reading confused. Im from oop world in java. But i wanted to learn C but then problem was that C is hard, and i wanted similar but easier and then found videos about zig, but now odin appears to claim to be simple too.
@@razorblade413 I have not played with Odin yet, but whenever in doubt: try to implement something simple that you are familiar with in both Zig & Odin. This will clarify a lot of frustrations/preferences from the beginning:
acceptable compilation speed, language support in popular IDEs, package ecosystem + convenient package manager, online tutorials and good documentation, type system , standard library with batteries included?
Move the video to the bottom right corner. It would hide way less content. Or even better, make the slide a bit smaller, so the video does not overlap it. Thanks!
C backend passing 69% percent of tests.
Nice
nice
Noice
nice
Nice
where can i learn about backend/frontend compiler stuff? it looks really interesting!
any compiler book
"Crafting Interpreters" by Robert Nystrom is a fun one to get started
“Engineering a Compiler” if you want a theoretical approach, programming language agnostic.
Interesting! Thanks for the recommendations !
"Writing an Interpreter in Go" and "Writing a compiler in Go" by Thorsten Ball are really good, modern books on the topic.
The compiler targets a custom bytecode. A 'true' backend might target x86 or arm64.
What can we do to help its maturity? I cannot wait to use it in more projects. Looking forward v1.0
Start using it for projects, join discord community.
This is going to take about next 5 years for v1. 0
looks like the data-oriented stuff is becoming Zig's flag ship secret sauce
This is basically the opposite of Rust Foundation... No drama... no arrogance... no shit talk...
there is C/C++ and everything else is shit
@@raulguerreroflores1460 can't disagree
All you need is C/C++ and sometimes some assembly is required
Andrew: On pronunciation of Vexu's name: Veikka Tuominen. This is a Finnish name so you actually say every letter (phonetic spelling!). It's like this: _vay - kuh_ . "Vay" rhymes with "bay" and "kuh" rhymes with "uh". And there's a somewhat noticeable pause between the two syllables, in order to emphasize the double k.
Thank you!
pls link the DOD video in the description
Done! Thanks for pointing that out.
Memory usage reduction, I had heard for 20 years that I was an “old boomer” pleading for that 😂
Is there a simple comparison of C, rust and Zig somewhere ?
So, self-hosted refers to the zig compiler that's build using zig ? EDIT: found this info:
Zig uses multiple compiler stages for bootstrapping the compiler:
zig0: is just the c++ compiler as a static library
only implements the backend for build-exe/obj etc
stage1: is the current compiler, written in C++, compiled with Clang
uses zig0 library to build pieces of stage2 in (subcommands like translate-c etc)
stage2: is the current project, written in Zig, compiled with stage1
stage3: is the fully self-hosted, stage2 code compiled with stage2
stage1 doesn't implement full optimizations so stage2 binary is not optimized
stage3 binary is optimized b/c stage2 implements optimizations/much better codegen
Does that mean the zig is not production ready till 2025 ???
It's got the self-hosted compiler now.
Please tell what time the asujc io will be available ?
Congrats!
Very cool! Seems very promising!
i enjoy using zig, but have stopped using it due to lack of documentation with std library.. i find it very frustrating.. i need to hop on to discord just to ask about basic thing about something that i dont understand in the std lib documentation.. hope they can improve that
Jump to definition and reading up code of the standard library is (not) surprisingly just as good.
we have a guy working on that but he's not producing results, he's like too busy partying or something
@@kristoff-it LOL
Extensively documenting the standard library right now would be a bit premature. That will be done once the APIs are stable. In the meantime, the code of the standard library is very easy to read and understand. And also a great way to learn Zig and its idioms.
Zig needs Risc-V target.
Saving the world from rust, one language feature at a time.
I started learning rust and now stumbled upon zig. What do you find better than rust?
@@SandwichMitGurke community... that's about it
@@wobsoriano I find Rust community pretty toxic when you start asking questions they don't like, unless you join the hype train and also worship the language.
@@vladyslav007 Zig is headed in the same direction.
They both have their space. One will not replace the other
Fun stuff!
Hyped
2025, can't wait
Oh Italy! Finally! But why?
Has Zig basically made no progress on the spec yet? Didn't you use to have a "spec guy" on the core team for many years who was getting paid?
Allocating/Reallocating/Freeing things in lists of size of increasing/decreasing powers of two? Buddy memory allocator from The Art of Computer Programming, Knuth is your homeboy here.
Why do you have to clean up generated C code? Shouldn't it do the same thing as the clean Zig from which it was compiled? I probably don't understand the problem but aren't there already tons of tools that should enable you to compile Zig code to C (or to assembly which is then converted to C, or to DynAsm or something)?
Zig can already compile to C, no other tools needed. The point was to make that generated C code "human readable" so it can be maintained going forward and instead of the existing C++ codebase.
@@jmc88dc Wouldn't it be a bit of a chore to always maintain two code bases for the compiler? I did not really get the point. Once you have a C back-end working it would be enough to have access to one zig compiler with this functionality running somewhere to be able to generate the C code to enable boot strapping for systems with only a C compiler. This could be done as part of the release process.
@ I think the idea is twofold: 1) the C code should map almost 1:1 to the original Zig code so that future maintenance is expected to be trivial, and 2) some software distributions may disallow software built from generated sources, so a hand-curated codebase might stay (at least for now, I'm also hoping that can be removed one day).
"Shouldn't it do the same thing as the clean Zig from which it was compiled? "
The issue isn't what it does, it's what it looks like.
"aren't there already tons of tools that should enable you to compile Zig code to C"
Um, there's one such tool: the Zig compiler.
"assembly which is then converted to C"
Er, wut?
@@jmc88dc "the C code should map almost 1:1 to the original Zig code so that future maintenance is expected to be trivial"
That's the idea, but it's cockamamie nonsense. Hopefully Andrew will realize that sooner rather than later.
"some software distributions may disallow software built from generated sources"
I can't imagine a distribution with such an absurd rule, or how "cleaned up" generated code wouldn't still violate it.
he looks and sorta talks like hank green, haha
Idea for how to write the FuzzTester: take a random git project in Zig and start replaying commits from a random old commit. Some projects will be more suitable for this, those that have high commit-level granularity.
This assumes people only check in working code
@@kibibu Yeah. The main branch could be used for that matter, as it is usually more or less stable. That's why I wrote that some projects would be more suitable than others.
32:44 maybe read the lmdb source code to get some inspiration on avoiding contention.
2025, here we are. Andrew Kelly, you are still alive (&t=2436). So we get a nice fat version? Congrats!
Can someone explain to me what 69% behavior tests passing is and whats the goal of it?
how about making a website that doesn't look like from 1995?
I'd rather have a website from 1995 than a website from after 2018. ;)
I read the strange syntax and thought Rust will take a similar amount of effort.
real men use C/C++ & assembly not (java,zig,rust,c#(microsoft's java),js,go,etc etc) bullshit
No real men code in flipping transistor switches.
I was really enjoying the talk until "lock-free data structures are bullshit" killed the whole thing. I mean, let's be serious: locking a mutex requiring you to context-switch to the OS will never be as fast as doing atomic operations. Unless you've been using it wrong the whole time, that's nonsense. It may hold some truth in specific use-cases, especially in kernel code but that's that. Or maybe everyone in the industry's been doing it and benchmarking it wrong for years. It all depends on the workloads and the access patterns (and how good your algorithm is :)
LMAO the pandemic brainwashed
why milan? who gives a fuc* travelling to italy? why not UK or similar countries? they're better i suppose to arrange meetings...
alias hugs 'bugs'
i'm shipping my code with a lot of hugs.