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.
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!
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?
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
"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.
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.
@@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.
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.
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 года назад
@@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.
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.
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 :)
