Using flex + bison (2 diff DSPs) PLUS ZIG to generate a build system for a 4th language (C)? Have you watched Jonathan Blows discussion with Casey Muratori on RU-vid about parsing. I don't agree with him a lot, but in this case he has a point.
Not letting people delete their code is evil! There are other ways of doing things, without sacrificing code author's freedom to delete, change thr code etc.
This would be soooo much better if I could hear the questions (or the speakers learn to repeat the question for the benefit of those watching the video).
We need at least one package manager. It must not be coupled into the compilation toolchain. It needs to be immutable. It needs to handle multiple targets.
I am more interested in system programming but i feel its difficult to enter this field and even where to start learning from. I am currently a junior android developer.
I feel very strongly in favor of either no package manager, or one that follows the no dependency tree philosophy suggestion in the talk. I love the current minimal dependency Zig code culture, and it would be very sad in the future if whenever I pull and build a Zig project, it starts pulling a massive list of packages.
I prefer a package manager to prevent the "works on my machine" thing in many cases. They had (or didn't have) something installed, and don't necessarily know what, that made their build succeed. If the author just has a short list of (optional) dependencies (2-3 packages) to make their dependency work how they intend, then the user knows exactly how to get to that point without building umpteen packages from various sources and filing bug reports for everything that didn't work in their particular case, because my version of some header from my distro package manager is slightly out of date. To simply have a standard way to fetch, build, cache, store, link dependencies will save a lot of headaches that few programmers want to deal with. You don't need to ask how someone installed something if it doesn't work, if they did it the standard way, you can continue the search to the real problem. From there you can replace the dependencies, if needed.
First: Speaker: Thanks for the interesting Talk. I really hope the Zig Package Manager Authors will not completely screw up the Official Implementation. Shame that the first initial Version in 0.11.0 is mostly unusable - not just for Windows users. Too many open Issues. IMHO the official Package Manager should not have been released in its current state. Very bad first impression - even for an Alpha Version. Second: For the Organization Team and Speakers: Audio is unnecessarily really annoying. Tip: The Microphone is your Friend. Get close to it - really close. Embrace it. Talk into the Microphone. Thank you and Good Luck for future Events with hopefully better Audio. :)
First: Thanks for the interesting Talk. Good to see that Zig will get complete Support for it in late 2026 or later (it is currently listed for 0.14.0 and therefore far far away in the future). Second: For the Organization Team: Audio is unnecessarily really annoying. Tip: Please tell the Speakers: The Microphone is your Friend. Get close to it - really close. Embrace it. Talk into the Microphone. Thank you and Good Luck for future Events with hopefully better Audio. :)
I've been a dev for years. For some reason the fact that the square root of any value can be represented in half the bit space was a revelation for me disgusts me. It's so obvious, but I must have missed it in all my years of bit twiddling and optimisations. I claim this viewing as a success!
I fully agree with you. I have written more than I should lines of code in C. I love C. Don't get me wrong. I was searching for a long time for replacement to it. I've tried Nim, Odin and Zig. Zig gives unprecedented control over memory and data. It's something between C and assembly and you can use whole Zig standard library no matter the platform. Plus you don't have to reimplement existing (excellent) C libraries, you can just use them without any additional effort. IMHO Zig will not only replace C as Lingua Franca but it will build upon it and in future we will see big (and pointless) fight between Rust and Zig. Pointless, because those languages adress completely diferrent problems.
It's clearer what is happening behind the scenes, like heap allocations, for example. It's this difference in clarity that made Linus not accept C++ in the Linux kernel.
I find that most people struggle to answer the question regarding "A good book to learn system programming". Zig would be great, as a programming language for a book regarding introducing people to systems programming in modern days and eventually more advanced topics. An open book could also be a good start to make it happen considering open contributions.
Wow. This presentation is so bad! The guy thinks he's in a bar explaining some tech stuff over a paper handkerchief after the 3rd or 4th pint of beer. He thinks his audience is there to laugh and to discuss some stupid subject over a beer. It's so annoying! I'm having a really hard time to finish it. 😆 Annoying voice, annoying accent, annoying overall attitude, incomprehensible most of the times (fortunately there are slides!), discuss with people in the audience (maybe he doesn't know he was being recorded), just terrible. He says: "'Parzing [parsing] is boring." Well, he gotta listen to his presentation to actually understand what's REALLY boring. 😆 Also, if it's so boring, why does he do it?
Macros are compiled as a binary and executed as part of the build process in rust. So you're running code during the build process that a dependency may have injected a crypto miner into that sends the coin to the author. Or worse, it installs a Trojan horse on your PC while you're compiling. And all that without even running the compiled application. It's just another entry for supply chain attacks.
@@nextlifeonearthit’s been a while and can’t remember the context but makes sense what you are saying. Now, since I can’t remember the talk much or this point if you don’t mind me asking what came to my mind now is, how is compile time any different? Thanks 🙏
@@kanji_nakamoto comptime in zig is not code execution at compile time but, but expression evaluation. So, it's not compiled into a separate binary, it's basicly simply interpreted. No injecting bitcoin miners into that :).
Thanks for the talk! Great video! 15:15 That is not correct. This would work in C. At least if the array is not in global space. But you would have (accidentally) created a Variable Length Array.
