You need to first eat coffee beans, then you can write assembly. With that, you can write a simple code for a basic coffee machine, then make coffee. From that point, you can write C code.
It's like how gcc is written in C. Originally we had assembly compile C, then used that to compile C. So first they made a coffee machine using assembly, then C
7:25 this is why I chose zig after escaping the Ivory Tower, simply due to the fact of how much stuff is already written in C, so being able to trivially use any C-library from zig without having to rely on some janky, possibly outdated bindings is invaluable… xlib, xcb, libgl, raylib.. the list goes on.
This is what I genuinely think will give Zig its space. First it comes in as a build tool and then slowly the codebase can add zig code. And there’s no marshalling.
@@twujstary1129 the direct header based interop is still a WIP for sure. has some bugs with circular dependencies for translated C headers that are (partial) blockers for my first C to Zig porting project. I have faith this stuff will become a priority in the next few years, and will get solved.
Also just a note on how zig errors work, Zig's `try errorResult` is the same as `errorResult catch |err| { return err; }`. All it does is say "if this is an error, return it so that the parent function can handle it"
@@imorvit they're almost error codes: errors are int-backed enums. Meaning they're not unions, meaning they can't have a payload. There's a feature request on github, but it seems they have trouble implementing them as proper unions.
@@chris-pee like calling every enum ever a code. when someone says error code, i immediately default to errno or something painful like that. again, I've never felt restricted by not having an error payload
@@imorvit Seems like you know a fair bit about Zig. A question that came up for me, and I've seen at least one person in chat also ask it (unnoticed): What's the difference between Zigs ``` const f = openFile(path) catch |e| switch(e) { ... } ``` and rusts ``` let f = match std::fs::open(path) { ... } ``` ? Other than that rust also matches on the success case, whereas Zig only on the error case, I can't see anything. And, the more I think about, that's some nice convenience. I guess. Would make the pattern matching a bit more flat. If Zig had any pattern matching/destructuring like Rust has I'd see this as a considerable upside.
Now I want a short with a girl that start explaining the clitoris and it cut outs to a programmer saying "wrong, it's pronounced Cliteral" and then goes to give a brief explanation.
... is something that's only true until you realize that you just now need to learn the specific pattern matched by whatever macro is implementing what would be surface syntax in another language. Is it worse? Better? Who knows. But it's not really *usefully* true to say Lisp has simple syntax.
@@atijohn8135 and various atomic literal types including identifiers *and* symbols, cons, quoting, unquoting, quasiquoting, whatever other stuff the specific implementation dumped in.... Go look at the Racket reference section 1.3 for the reader and tell me thats less syntax than, say, lua or python. Other Lisps are even "worse". And *then* you have to learn all the standard macros that implement matching, classes, modules, etc that basically are just syntax. Lisps are great, but not because they have a simple syntax.
Most of the criticisms boil down to three things: 1. Unused variable errors (only complained about by people that don't use Zig) 2. Memory safety (overrated - people get *hysterical* about this one) 3. "Zig is UNUSABLE because it doesn't have inheritance/traits/closures/interfaces/macros/pattern matching/RAII/smart pointers/operator overloading/error payloads/function overloading/built in dynamic dispatch/async" (the worst complaint, if Zig had everyones favourite feature it would just be C++) It reminds me of a lot of the criticism that Go would get.
@@IamPyu-v No it won't, be limited at all LLVM is the backend and will still be accessible and maintained, they just want to also offer their own back-end for faster compilation speed. And because LLVM doesn't handle async well
@earx23 that is my experience. The Zig build system is now my goto for C and C++ compilation. The Zig build system is also getting a decent minority of all C and C++ programmers to use it since it is a simple system for managing dependencies. Once they add in the package manager like Anaconda for Python, it will take off even harder.
To follow up, the Zig build system uses Zig Object Notation (.zon) files where the objects are just Zig structs. The builder object is just a Zig object that you use to call a Zig function. The Zig build system is just like a Zig library that can build and compile Zig, C and C++. There is no second language to learn as it is all just Zig. Imagine if C and C++ macros were just the language itself, it would be amazing.
andrew kelly said they're changing the syntax after 0.12. can't wait to see what type of optimizations they can get with a different syntax. pretty exciting language, just has a lot more work to be done on it.
@@Dewd98 from the 2024 zig roadmap. 0.12 is gonna be heavily supported and many companies are going to pin that version for support from official zig people too.
29:08 comptime is so powerful that i made a joke program where I read a json file (file stored on disk) at compile time and converted it into a struct and used that struct as a regular struct in the code.
A use case I've used this for is using comptime to automatically create structs for glsl uniform buffers, so they're always in sync. Can save some headaches in the long run!
You can do the same in Rust with proc macros, but it's probably a lot more of a pain. (Though you don't actually have to use syn unless you need to parse arbitrary Rust source, emit is much simpler)
As someone who really likes Go I have to admit I like Zig. I’ve been looking into it and there are a couple of things that Go could actually adopt from Zig.
Used Go before switching to Zig. There are so many niceties that using Zig for lower-level tasks (like bitfields, C-integration, etc) is much easier than Go
I wish Go had opt-in manual memory management. (You can using unsafe and C FFI, but it’s an extreme option) They could have done this, but decided that half-baked generics was a better move, as the Go user base got flooded with new Java converts or something.
@bluzytrix For me its a few things 1. Optionals 2. ArrayList in the standard library (I do not like the implicit backing array behavior of Go slices) 3. The "try" syntax as a shorthand for "if err != nil" (There's been discussion about Go adding this) 4. String literals being automatically compatible with C 5. Defaulting pointers to nil needs to be explicit with an `undefined` instead of being tied to Go's zero-ing behavior. Some of those are realistic for Go to implement, others are not. ArrayList is a big one for me though.
same for me, Go should adopt Zig error handling (I hate those error handling every line of Go), optional, enum(yes, real enum), and union.... So, Go will be Zig with auto GC and Go has huge library to ready.
@@TopOtheMorntoya Uhhh, you're saying _I_ don't think very much because I'm not easily entertained by his mindless waffling like yourself? That's some heavy projection there, buddy.
@@lodgin how easily you are entertained is not a sign of low intelligence or thinking, actually quite the opposite based on several studies but that is besides the point. Perhaps you should take a second and reflect on who the target audience is before you judge. He gives advice, you say he does nothing, meanwhile everyone else following his advice is living a better life than you. Stay sad, stay mad broke boy.
and its unstable ABI and impossibility to ship pre compiled libs that dont go over C ffi make it a really bad language for game dev. zig is an interesting language and i have met andrew kelley before but it has some deep inherent and unresolvable flaws.
@@gideonunger7284 I'm braindead, but what is an example of a precompiled lib that doesn't go over c ffi, and what language is that? I'm just thinking maybe C# DLLs or something? Does C++ allow for a more advanced ffi or something?
@@gideonunger7284 You won't miss it as much once they have the incremental compilation, because than you can basically recompile your code really fast, and make the change you need.
@@gideonunger7284 "impossibility to ship pre compiled libs that dont go over C ffi make it a really bad language for game dev" with that criteria in mind, what languages do you think isn't a "really bad language for game dev"? C#? when you say "for game dev", are you talking about tools, middleware, engines, games, or development platforms? are you talking about open source, or a B2B use case? cause they all have different solutions to this problem.
I think zig has the best philosophy for it to be adopted. The fact that it essentially can be used as an all-in-one replacement for cmake and clang/gcc and integrates well with C code is fantastic. Rust was created to be it's own entity, which is the biggest turnoff for people learning it imo
@@infastin3795 libasan literally originated in clang... so that sounds more like a skill issue but here's a small gotcha between these two: - gcc's -fsanitize=address is equivalent to clang's -fsanitize=address -shared-libasan - clang's -fsanitize=address is equivalent to gcc's -fsanitize=address -static-libasan so, maybe that was your problem btw, thank gcc developers for that difference
@@egorsozonov7425 traits on structs are indeed one of the easier parts of rust. it's not a feature of zig, and there are much more difficult parts of rust.
I have been dabbling in Zig when I get the time, and it is indeed a a super interesting language that I definitely want to deep-dive into as my next "go-to" language. It is definitely my own skill issues, but I find Rust to be too restrictive to do the things I want to do (mainly game-dev stuff), and I too often find myself fighting against the language instead of just getting stuff done.
Yo prime, nice to see you on more zig. Regarding the try syntax: postfix operators are not a big thing in zig in order to promote explicit intermediate values. Zig is a hardcore imperative language, so chaining is intentionally kept to a min.
@@TehKarmalizersquirrels eat nuts. He may give everything attention, it doesn’t mean he comes around in everything. He likes zig. He doesn’t like every single project.
Hey dudes! Glad to see Zig being explored and curiosity growing day-by-day. I've got a couple of playlists for learning Zig. Zig Master covers the latest version: th-cam.com/play/PLtB7CL7EG7pDKdSBA_AlNYrEsISOHBOQL.html&si=rylNoBpDV14kfjIh ; and Zig in Depth covers version 0.11: th-cam.com/play/PLtB7CL7EG7pCw7Xy1SQC53Gl8pI7aDg9t.html&si=-py8hirleVyyKpHj . For Spanish-speakers there's also Zig Master en Español: th-cam.com/play/PLtB7CL7EG7pC960XOA5vymEyTfQ3M_QhL.html&si=vcTfQf5TEwwwRURk
A big difference with Zig/Odin/Nim/etc … vs The Others, is independence. They are run by programmers, for programmers. Development costs are funded by genuine enthusiasts, with money flowing back to hiring qualified contributors. There is no committee of highly paid political lobbyists who suck up the funding, telling the pleb volunteer programmers what to do next and how to do it. Proper Freedom isn’t always the most efficient way to get anything done .. but damn, it’s the most fun by a long shot.
You don't understand. We just approved the C++45 standard with 4748292 new features. We expect the people behind gcc, llvm, etc to start programming at once.
sure. we can agree that staying home forever is a nonstarter. but we can also agree that riding a JATO rocket everywhere also isn't safe. and we can also optimize the safety of the car itself, the training of drivers, the road construction and city planning, and the rules of the road. it needs to turn into a series of conversations and agreements for someone, somewhere. and it can be valuable for us to at least understand those conversations, and possibly for us to be involved in those conversations in some cases.
@@blarghblargh Sure, what I'm trying to say is that no matter how much we improve languages, generate patterns, tools, etc. Problems will be latent. As such, we must try to not avoid them, but tend to them. And I feel the better language is the one that does just that, in a simple and elegant way.
@@keymatch-clovis I don't think simple and elegant are necessarily always the right tools. sometimes what you need is for bugs to stick out like a sore thumb. this is especially true in languages focused on performance, where you actually need to do some "risky" things for purposes of efficiency, and need a useful way to thoroughly audit them. But yeah I think I generally agree with you. I just think a lot of people (not necessarily you, here) choose to use blanket statements to cover up things they don't want to deal with, when really the whole ecosystem could benefit from more expertise across the board. We will get to significantly better places through hard work done by lots of people, not (just) with savior languages or magic bullet features. Those can help too, for sure, but they're not going to save us.
@@jamad-y7m if your Tesla has the portable extra dimensional wormhole installed, maybe. Studies show that Tesla drivers are very accident prone. They also don't magically save you from tractor-trailers or vehicles that are significantly taller, like SUVs
18:02 A similar mechanism to defer exist in Dlang: scope(exit) 29:28 Compile time function execution (CFTE) like this could be done with Dlang already ages ago.
8:02 Agreed, but that's also because computer science has based its curriculum off of C (and C-like languages) for half a century. It's like saying a piano naturally represents music theory, where in reality the standard 12-tone scale is largely built around the piano. Not to say C or the piano are bad or holding back either field, just that their ability to feel natural isn't unique to them nor an accident.
You normally make an enum with all the possible errors, makes it possible to fully handle all errors (not having some default which mostly is panicking). Also it's a little bit faster (no box, no vtable)
@41:59 Matheoux7 posted "zig reverted async"! That is so important. Zig was about to go down the C++ route of including all the latest 'cool' gimmicks, but in the process introducing all sorts of footguns (footgun mentioned). Thank god they reverted it. Well done Zig team. The devil is in the details though.
@@ITSecNEO I've used Go's channels and they seemed to be nice; but it would be better still to have a thread orchestration primitive, and then the compiler could do static analysis on it.
I had the same opinion about “what should I learn next?” questions. But then I spent 4 months learning Rust for game dev. It isn't very good for that. Looking back, if I asked and read more opinions, I would spent that time on something more useful, like making my peace with Cpp.
@@leeroyjenkins0Well one word describes it pretty good: Lifetimes. Game Dev is also all about performance, so you need to handle GPUs very good and also need to support multithreading and other performance stuff. Rust is definitely not the language where you want to do all that, trust me. There are a lot of game engines for Rust, but literally not a single game (with bigger impact) made with one of them 😅 so yeah, try Rust for Game Dev, but you will not be happy
My favorite way to do error handling in Rust is by returning a `Result`. When an error occurs, you simply eprintln!() it and return Err(()). So if all of your functions do this, it's very easy to use the `?` operator and not worry about converting between error types. Of course, this might not be the most versatile approach, but for application code it's fine 99% of the time (Library code is different)
Funnily enough, this makes it work closer to how it works in Go. And I often hear people say Go should adopt something similar to Rust's error handling.
when i'm prototyping i tend to make a "generic" result type that can catch anything that implements the Error trait, it works well: type GenericResult = Result
LLL/Ed was one my childhood best friends (12-16), we wrote game maker language code/built 2006-2010 style websites (that I often had to "fix" because I had 1 or 2 years more experience than him). We'd stay up all night programming and studying and drinking energy drinks (vault gang/mr coffee gang). We woke up so many days at his parents house at 2-4pm because we stayed up til they made us coffee and breakfast when they woke up, my parents would always let me stay over because they knew I was working on stuff/learning, super funny hahaha. It's crazy to see him on your channel! Long live the joveproject and long live mario fan games.
I just like Zig's compiler. I can write my code, in C or Zig, and compile it for all of my supported platforms with a single command. Right now, I'm working on a library similar to GLFW or SDL, and being able to use C to talk to libraries like Xlib in a more reasonable fashion while using Zig to do the "hard" stuff, all using a single build file is just so nice.
Compilation for all platforms is half LLVM and half a licensing issue for the SDK. IIRC, Zig is doing some heavy lifting there to package up the platform SDK for you without hitting licensing issues, but Rust should get it "soon" (raw-dylib feature), in a way that arbitrary packages can define the linkage across targets without external libraries (and it's already supported by the windows package).
14:40 I sort of think there's more common space on this between you and Uncle Bob than you admit; IIRC his advice in his talks is boils down to "babysitting" the try/catch in to a function of its own, and then return a "normal" value. (I'm not sure, though, I need to re-watch your interview with him.)
For me the most confusing thing with Zig is its allowance of . to dereference a pointer and access a struct’s members. In C++ it’s super clear that I’m dealing with a pointer when I use ->. While that may make it easier to write it makes it a lot harder to read; am I operating on a copy of the data or the original data?
@@kuhluhOG shadow stack isn't supported everwhere either, you can still use checked versions like snprintf, or use something like safeclib, was just mentioning that there are safer ways to use c when those things are available.
True on the first part. With a bit of preproccessor magic I can have most of the niceties of zig, many of which done better. IMHO, zig has made some really stupid choices. But shadow stacks suck too. I'll rather have security through clean and/or statically verified code than have my assembly littered with that codebloating endbr64 nonsense. -fcf-protection=none and nice dense assembly outputs for me please.
@@pskocik tbf, the endbr64 (and other assembly weirdness) comes from the fact that LLVM can sometimes produce weird code when it gets input it doesn't expect (which is something a lot of projects using LLVM but aren't part of the LLVM project like clang have a problem with actually) but well, we will see how long term Zig's self-made backend will end up but there is one thing I disagree with you: the C preprocessor sucks; and to this day I haven't seen one preprocessor thing where I would be like "yeah, that's better than what you can get in Zig or even C++99 templates" (and the latter is quite frankly a really low bar)
I'm curious why his allocator is the page allocator. Won't each allocation will give an entire page of memory regardless of how small the allocation is?
You're right. I think it would've been better if he used page_allocator as described under the "Choosing an Allocator" section of Zig's official documentation, where it is shown how you can wrap the page_allocator in an ArenaAllocator to get something more similar to a dynamic array/vector. I can say from a year of experience with Zig that arenas are awesome, since you don't have to worry about freeing ptr1 nor ptr2 individually, as it all happens at the .deinit(): var arena = std.heap.ArenaAllocator.init(std.heap.page_allocator); defer arena.deinit(); const allocator = arena.allocator(); const ptr1 = try allocator.create(i32); const ptr2 = try allocator.create(i32);
And yeah ghost allocations is the reason that when I worked in medical systems we weren’t allowed to use libc. We wrote all we needed ourselves, as to be damn sure that if libc changed or the platform changed the code was still tested and working. Last thing you want with an insulin pump (and that was the junior/medior development because insulin is forgiving) is that you had a OOM and in an embedded device you don’t see that, and it will not deliver that insulin when needed.
Odin is more like C than Zig is even though it's also quite Pascal-like. Zig has the momentum from Bun. I like both, and Rust. Go doesn't bring back the joy of coding C that Zig, Odin, Rust, and Swift do.
Go is boring, but it gets the work done. Zig, Odin, Rust and Swift are more interesting, but also have a higher learning curve. They're all good languages, for different reasons. If I had 2 days to write a prototype, I'd pick Go. If I had a year to write a solid program, I'd probably choose Rust. And if I also needed interaction with C, I'd go for Zig.
@silas-bv1ql That's not what I've found. I had some outliers when I was experimenting with all these languages at with some of them there was a slowdown caused by array/slice bounds checking which, in Odin and Zig at least can be turned off. Some were also affected by their dynamic array or map/dictionary implementation. The one that surprised me by its slowness was Swift, but unlike Odin and Zig I didn't go to their Discord to ask for advice so maybe it could've been better.
But doesn't go essentially have try/catch with panic/recover and rust with panic/catch_unwind? try/catch can have it's usefulness. It can be much easier to escape multiple levels of functions with a simple try/catch then multiple levels of returns and if/match statements. But if you don't like try/catch then you can just think of throw as panic and just don't catch it. Nothing is stopping anyone in any that has functions from returning an error rather than using try/catch.
Came for information about Zig, instead got inspired to learn every day and live life as it comes to me and use my best judgment rather than worry about what perfect is all the time.
It depend on the user and which area targeting. For this it is portable and small. But depend on the size as it need cross platform tool compiler to handle those stuff. To able to export to different platform is easy and hard. vs those toolchain has big file depend which toolchain is it and packages. zig is about 300mb last checked for exe size is 150mb. While other is +400mb. It depend on application and packages. It all one package or crazy different config builds.
I am not sure, what you are saying here, but just to clarify: Zig can cross-compile to a lot of different architectures and operating systems out of the box.
Something that looks important to me about Zig is it seems less opinionated, and I think a language that simply 'allows for' but not built around assumptions, that is what I look for ... (I take the same view with social and economic systems. lol) I don't know because I haven't really spent time with Zig yet, but it looks appealing.
I think defer is a bad design...this code demonstrates one of the reasons, where is the close for the file? The defer was missed. There are many other issues with defer like scoping, slow, etc. EDIT: Just spotted fBuf clean-up was missing
26:30 "You should learn," and the round of applause. Great, Primeagean! Very good. Now tell that to an employer who prefers 100+ years of experience in every effing damn framework for ONE language (otherwise, if your interests are broad -- you're considered mediocre at everything, at best, from the get go) as deep as possible for the "new grad" position for 16/hr
Wise words from ThePrimeagen: "If you can just keep on having something you can do again, that's better than the thing you'll do once." Or equivocally: smoke weed everyday.
In terms of safety, medium-core C++ is straight up safer than zig. As long as you're using smart pointers, as long as you never use new/delete/malloc/free manually, you're already never going to get memory leaks in C++. In zig, absolutely nothing stops you.
21:51 It seems Ziggs has a sort of like a global "std enum" for errors. I think the reason Rust isn't using this `catch |e| switch (e)` is the fact that Rust's Errors are not something special of the language, but a sort of neat byproduct of the design choices done, aka Enums. so far, the only thing that makes Error special is the fact that it is implemented by std, and everyone is following std. So far, no specialized syntax to catching errors. Even the "?" used to early return errors are being converted into a Trait call, which is for now, a step closer to make Rust's std more like a library instead of Compiler's Magic doing background work for you.
The biggest problem about Zig is that the language is still very unstable ATM. I'm actually working on a game using Zig and Raylib and things get broken every major update. Aside from that the language is a joy to work with as long as you're prepared to potentially adjust your code due to breaking changes every now and then. Also LLM assistants have yet to adjust to the latest version of the language. That said I can see it being my favorite language once the language itself is stable enough.
people tend to search for a more optimal path when they want to do less work which ithink many programmers now adays because alot of people go into programming for money (happens in all careers that balloon up)
yeah life also gets pretty busy when you're not a CS student/beginning of your career dev. Happens in most areas as you get older. The fluff falls to the wayside.
The answer to "should I LEARN X or Y" is always "you should learn X AND Y". Obviously you don't have to master both things, but you gain so much more insight when the time comes to answer the question "which language should I USE (for a particular problem)". Unless you're jumping between Functional, Procedural or Asynchronous language families, all languages are similar enough that there is no reason you can't dip your toes into all of them enough to be able to answer the question "which language should I MASTER and/or USE" when the time comes. And since there is no such thing as a "single best language for all problems", you're gonna need to be learning as many languages as you possibly can anyways (and trust me, once you've learned at least just 1 of each of the major language classes [functional, Procedural, asynchronous, etc] it's 10x easier to hop to other flavors of the same general class of language). So always do your best to answer these questions yourself. When you no longer need to ask these sorts of questions because you've experiencially answered them yourself, you've leveled up as a developer
Is there anything that Zig adds that couldn't just be added to Rust? Like the build logic/comptime feels like it should be able to expanded on further in Rust's proc macro system. I say this because Go's greenthreads were so popular they just got adopted everywhere.
A lot of Zig's appeal comes from features it doesn't have. Zig has enough functionality without being overwhelming, so Rust can't do that without becoming even more complex. Zig is also willing to break to achieve the fastest possible performance, Rust can't really do that either since it's past 1.0. And Zig has had an absolute shitton of time put into hot reloading and compilation speed. While these aren't yet ready, they'll be other killer features that simply aren't possible in Rust due to its complexity and reliance on LLVM.
zig is pretty much the modern C but when I tried it there were a few annoyances specially there is pretty much no support in the language for any sort of interface/trait(or either I have massive skill issues) to share functionality which could lead to repetitive code but the language is elegant though and I am excited for 1.0 release and hoping they polish the tooling specially the LSP because it takes up a lot of resource and kinda buggy.
“anytype” params sort of do that - the compiler ensures the param matches the required interface, without having to define & maintain contracts. A different approach, yes, but it solves a similar problem
I was thinking about the Linux kernel including Rust. I think that since Zig isn't 1.0, it won't be considered, yet. Zig may be closer to what we would want in the kernel, since it doesn't have hidden control flow. I could be wrong here, and I'm to busy to put in the time to figure out if I am. The main problem is thread safety, but when you're in the kernel, the Rust compiler doesn't have information about everything, so the thread safety is only for what's made in Rust. I'd like to do some Actor Oriented code in Zig to see how safe that pattern could make things without needing a borrow checker, which seems to be what blocks many people from using Rust.
Oh and learning Zig, like I have showed in my first video, is to open it stdlib source code and read the tests and code. Because documentation is currently lacking and the language is changing a lot.
the problem of go is actually not GC for most perforamce use cases but its green threads. the problem is the slowest ffi in the world. i dont know how its not but a go callback called from c could have up to 1ms call overhead due to the green thread stuff go is doing. writing a game engine under those condition where you simply need to talk a lot to the OS is just unfeasable regardless of any other features of the language
I agree! Rust gets very hard and unfriendly in embedded systems. And when I did Zig (I have a couple of videos) it all is so simple in comparison. It’s a bit verbose here and there although Rust is that too, but you don’t need to do lifetimes; which is a terrible syntax imo, looks like a hindsight implementation. I choose Zig for any project I’d normally would use C now.
Pretty simple really - different programmers think in different ways. Languages are a tool to express a thought process about how to build a thing. Zig is not for everyone, but it’s great for programmers that mostly think in terms of assembly and system calls when they are coding a solution. (Just like C programmers do) There aren’t many programming languages left that target this direct mode of thinking.. so it’s nice that Zig exists in this space. The stdlib is a bit of an evolving mess, but that’s fine, as it’s more a collection of suggestions at this stage rather than a hard reliance. Doesn’t get in the way at least, and isn’t needed for a lot of jobs. If you are in this camp, then unused vars (for example) is a bug, and deserves to be a compiler error. Likewise - formatting code is not a concern, and syntax quirks are what they are.
I learned assembly before I learned C and for me Zig still feels more abstract than C. Odin feels more like C as in allowing the direct mode of thinking that I don't have in Zig yet. When trying to feel out new code, debug, iterate, refactor, the unused vars thing has not stopped irritating the hell out of me yet. Maybe if I mainly used Zig that would stop?
@@andrewdunbar828 just turn the option on in the language server to format on save - it should inject lines of code to stub out decl for unused vars And use underscore for the name of unused params It’s similar to the way Go does it
You asked about async in Zig. Worth noting that async has been removed from Zig for a couple of major releases now. They deemed their first implementation flawed and scraped it 🤨
I was interested into trying zig for embedded, but their repo about it seems to be abandon from a few years... while Rust embedded team made miracles to give safe and generic interface to pretty much any LLVM supported chip
Idk why I’m so obsessed with Zig atm. Currently studying for 3 exams so I don’t have time to code in it, but I can’t wait to get my hands on the language. Something about it just appeals to me
Saw a comment about C++ modules. Get cmake nightly and clang 19 (may have to build from source tho, or ask your linux distro community) Both `import std` and custom modules work Have fun!
The primes take is different to mine. Rust does focus on giving you a language which feels like a high level one but is really low, this is what most people interact with. Rust also has 'unsafe' as i'm sure we all know, but it is nothing like C or Zig. A simple way to explain this is with C and Zig (pointer based languages), it is made very easy to read and write from pointers. Rust makes it safer; you can still write Rust byte by byte, but the verbosity is enormous compared with C or Zig. Again Rust has an interface in 'unsafe' Rust with methods on say a `*mut u8` has methodscalled write() write_bytes() which make reading to a writing to a bit different. The point is trying to write unsafe like C or Rust can be don't but it's difficult, even in 'unsafe' there is still methods to help ensure lengths are taken in a the very least, or they can be fail. I get the appeal of Zig, and i'm hoping my son picks it up. But i'm settled on Rust, i learned it, i know it and i'm good with it
2024 is the year of "X is the year of ..." articles
linux desktop
@@angelcaru every year is the year of the linux desktop
That's literally every year
2024 is the year of current year and I'm tired of pretending it's not
@@VojtěchJavora But this year its different
"coffee machines are written in C". But to write C code, one needs coffee. How does that work?
Shut up you'll break the matrix if you repeat paradoxes which show our universe is built on false tenets
Bootstrapping from lower level or older high level languages compiled for the target architecture 🤓
You need to first eat coffee beans, then you can write assembly. With that, you can write a simple code for a basic coffee machine, then make coffee. From that point, you can write C code.
It's like how gcc is written in C. Originally we had assembly compile C, then used that to compile C.
So first they made a coffee machine using assembly, then C
The same way they made first compilers: by manually rearranging atoms to take shape of coffee
7:25 this is why I chose zig after escaping the Ivory Tower, simply due to the fact of how much stuff is already written in C, so being able to trivially use any C-library from zig without having to rely on some janky, possibly outdated bindings is invaluable… xlib, xcb, libgl, raylib.. the list goes on.
Why raylib? Sadge
Completely agree.
Zig's C interoperability is such a killer feature. Love it.
This is what I genuinely think will give Zig its space. First it comes in as a build tool and then slowly the codebase can add zig code. And there’s no marshalling.
problem with the interoperability is that it doesn't support C's bitfields, but when it is resolved, zig is gonna be lit
@@twujstary1129 the direct header based interop is still a WIP for sure. has some bugs with circular dependencies for translated C headers that are (partial) blockers for my first C to Zig porting project. I have faith this stuff will become a priority in the next few years, and will get solved.
@@twujstary1129 packed structs with different u1, u2, u3, and so on variable types?
@@twujstary1129 I just don't think the Zig project is serious about systems shit. No ABI? You fucking kidding me?
Also just a note on how zig errors work, Zig's `try errorResult` is the same as `errorResult catch |err| { return err; }`. All it does is say "if this is an error, return it so that the parent function can handle it"
Yeah except that it can't return errors, just mostly useless error codes.
@@i-am-the-slime they aren't error codes, they are switchable types, so that doesn't make sense. I've never felt held back by zig's type system
@@imorvit they're almost error codes: errors are int-backed enums. Meaning they're not unions, meaning they can't have a payload.
There's a feature request on github, but it seems they have trouble implementing them as proper unions.
@@chris-pee like calling every enum ever a code. when someone says error code, i immediately default to errno or something painful like that. again, I've never felt restricted by not having an error payload
@@imorvit Seems like you know a fair bit about Zig. A question that came up for me, and I've seen at least one person in chat also ask it (unnoticed):
What's the difference between Zigs
```
const f = openFile(path) catch |e| switch(e) { ... }
```
and rusts
```
let f = match std::fs::open(path) { ... }
```
?
Other than that rust also matches on the success case, whereas Zig only on the error case, I can't see anything. And, the more I think about, that's some nice convenience. I guess. Would make the pattern matching a bit more flat. If Zig had any pattern matching/destructuring like Rust has I'd see this as a considerable upside.
4:56 “Learning something is better than trying to figure out the best thing to learn ever.” Never have I related to something so hard.
we have ears too
@@FlanPoirot except we also have common sense, I'm not so sure about you
"I don't know what CLIT is... never found one"
💀
Now I want a short with a girl that start explaining the clitoris and it cut outs to a programmer saying "wrong, it's pronounced Cliteral" and then goes to give a brief explanation.
3:01 LISP has less syntax than GoLang because LISP is just words and values composed in a bunch of parentheses
... is something that's only true until you realize that you just now need to learn the specific pattern matched by whatever macro is implementing what would be surface syntax in another language.
Is it worse? Better? Who knows. But it's not really *usefully* true to say Lisp has simple syntax.
And Brainfuck has less syntax than than LISP.
How much syntax a language has is not a good indicative of it's usefulness and is a pointless benchmark.
@@crimsonbit brainfuck actually has more syntax
lisp is just two syntax rules, one for lists and the other for function application
@@atijohn8135 and various atomic literal types including identifiers *and* symbols, cons, quoting, unquoting, quasiquoting, whatever other stuff the specific implementation dumped in....
Go look at the Racket reference section 1.3 for the reader and tell me thats less syntax than, say, lua or python. Other Lisps are even "worse".
And *then* you have to learn all the standard macros that implement matching, classes, modules, etc that basically are just syntax.
Lisps are great, but not because they have a simple syntax.
@@SimonBuchanNz Try Clojure. You won't be using that many macros or writing them yourself.
Zig is an awesome language. All of its bad PR is from people comparing it to Rust. Apples and oranges everyone!
If it wasnt still a developing language with long way to go and possible breaking changes, I wouldnt have quit learning it
I am waiting for more maturre zig.
Most of the criticisms boil down to three things:
1. Unused variable errors (only complained about by people that don't use Zig)
2. Memory safety (overrated - people get *hysterical* about this one)
3. "Zig is UNUSABLE because it doesn't have inheritance/traits/closures/interfaces/macros/pattern matching/RAII/smart pointers/operator overloading/error payloads/function overloading/built in dynamic dispatch/async" (the worst complaint, if Zig had everyones favourite feature it would just be C++)
It reminds me of a lot of the criticism that Go would get.
the cultaceans bashing everything that isnt their holy language? no way!
@@enzocalzone5298This year, Zig will reach 0.12, which will hammer down what the language is a lot. There will be much fewer breaking changes.
Zig competes with rust in the same way c competes with c++.
They have different philosophies
I absolutely agree with this take.
So what you are saying is that Zig competes with Go?
@@sidma6488Only if you dont want gc
@@sidma6488i mean, isnt interoperability with C as feature a dead giveaway about that?
I choose C over C++ and I choose Rust over C++ and I choose Zig over C++.
Your interview content is always so good. More please.
Zig's C Interoperability is interesting to mix it with older C code.
Sadly Zig's C interoperability would be limited after the LLVM divorce.
@@IamPyu-v No it won't, be limited at all LLVM is the backend and will still be accessible and maintained, they just want to also offer their own back-end for faster compilation speed. And because LLVM doesn't handle async well
They say the build system is much better than cmake, for instance. It supposedly makes building C code a breeze?
@earx23 that is my experience. The Zig build system is now my goto for C and C++ compilation. The Zig build system is also getting a decent minority of all C and C++ programmers to use it since it is a simple system for managing dependencies. Once they add in the package manager like Anaconda for Python, it will take off even harder.
To follow up, the Zig build system uses Zig Object Notation (.zon) files where the objects are just Zig structs. The builder object is just a Zig object that you use to call a Zig function. The Zig build system is just like a Zig library that can build and compile Zig, C and C++. There is no second language to learn as it is all just Zig. Imagine if C and C++ macros were just the language itself, it would be amazing.
andrew kelly said they're changing the syntax after 0.12. can't wait to see what type of optimizations they can get with a different syntax. pretty exciting language, just has a lot more work to be done on it.
ahh man seriously?? lol. I just finished with ziglings lol. Oh well I'll take another look later. Hopefully they reach 1.0 soon
Where did you read this? I'm curious, but struggling to find any mention of it
@@Dewd98 from the 2024 zig roadmap. 0.12 is gonna be heavily supported and many companies are going to pin that version for support from official zig people too.
29:08 comptime is so powerful that i made a joke program where I read a json file (file stored on disk) at compile time and converted it into a struct and used that struct as a regular struct in the code.
this sounds less like a joke and more like the exact reason you want comptime, to support better dynamically generated interop. sounds cool :D
A use case I've used this for is using comptime to automatically create structs for glsl uniform buffers, so they're always in sync. Can save some headaches in the long run!
They don't have sandbox in comptime? That sounds like a supply chain attack about to happen
What if I wrote a lib, but I later add a comptime to scan your disk and upload any interesting file to a remote server 🤔
You can do the same in Rust with proc macros, but it's probably a lot more of a pain. (Though you don't actually have to use syn unless you need to parse arbitrary Rust source, emit is much simpler)
As someone who really likes Go I have to admit I like Zig. I’ve been looking into it and there are a couple of things that Go could actually adopt from Zig.
Can you please name those things?
Used Go before switching to Zig.
There are so many niceties that using Zig for lower-level tasks (like bitfields, C-integration, etc) is much easier than Go
I wish Go had opt-in manual memory management.
(You can using unsafe and C FFI, but it’s an extreme option)
They could have done this, but decided that half-baked generics was a better move, as the Go user base got flooded with new Java converts or something.
@bluzytrix
For me its a few things
1. Optionals
2. ArrayList in the standard library (I do not like the implicit backing array behavior of Go slices)
3. The "try" syntax as a shorthand for "if err != nil" (There's been discussion about Go adding this)
4. String literals being automatically compatible with C
5. Defaulting pointers to nil needs to be explicit with an `undefined` instead of being tied to Go's zero-ing behavior.
Some of those are realistic for Go to implement, others are not. ArrayList is a big one for me though.
same for me, Go should adopt Zig error handling (I hate those error handling every line of Go), optional, enum(yes, real enum), and union.... So, Go will be Zig with auto GC and Go has huge library to ready.
bro is able to turn 9 min into 48, content beast
Except it's not content, it's a lot of speaking without actually saying anything.
@@lodgin Or maybe you just don't think much......
@@TopOtheMorntoya Uhhh, you're saying _I_ don't think very much because I'm not easily entertained by his mindless waffling like yourself? That's some heavy projection there, buddy.
@@lodgin how easily you are entertained is not a sign of low intelligence or thinking, actually quite the opposite based on several studies but that is besides the point. Perhaps you should take a second and reflect on who the target audience is before you judge. He gives advice, you say he does nothing, meanwhile everyone else following his advice is living a better life than you. Stay sad, stay mad broke boy.
@@lodgin Or maybe you just don't think much......
Understanding control flow better, having explicit allocators, and having comptime make zig the ideal language for game dev imho.
and its unstable ABI and impossibility to ship pre compiled libs that dont go over C ffi make it a really bad language for game dev.
zig is an interesting language and i have met andrew kelley before but it has some deep inherent and unresolvable flaws.
@@gideonunger7284 I'm braindead, but what is an example of a precompiled lib that doesn't go over c ffi, and what language is that? I'm just thinking maybe C# DLLs or something? Does C++ allow for a more advanced ffi or something?
@@gideonunger7284 You won't miss it as much once they have the incremental compilation, because than you can basically recompile your code really fast, and make the change you need.
@@gideonunger7284 You can get around the pre-compiled libs problem by just wrapping that C interface in a Zig API
@@gideonunger7284 "impossibility to ship pre compiled libs that dont go over C ffi make it a really bad language for game dev"
with that criteria in mind, what languages do you think isn't a "really bad language for game dev"? C#?
when you say "for game dev", are you talking about tools, middleware, engines, games, or development platforms? are you talking about open source, or a B2B use case? cause they all have different solutions to this problem.
I think zig has the best philosophy for it to be adopted. The fact that it essentially can be used as an all-in-one replacement for cmake and clang/gcc and integrates well with C code is fantastic. Rust was created to be it's own entity, which is the biggest turnoff for people learning it imo
Nah, it can't replace CMake. I tried and it couldn't even link with libasan because clang is shit.
@@infastin3795 did you file a bug on this prerelease software? or did you decide to just write it off and then tell everyone you did?
@@infastin3795 libasan literally originated in clang... so that sounds more like a skill issue
but here's a small gotcha between these two:
- gcc's -fsanitize=address is equivalent to clang's -fsanitize=address -shared-libasan
- clang's -fsanitize=address is equivalent to gcc's -fsanitize=address -static-libasan
so, maybe that was your problem
btw, thank gcc developers for that difference
me thinks Zig is THE best effort thus far at a language that could be a replacement for where C is used.
@@TheSulross I don't disagree but have you also looked into Odin?
Zig is my #1 favorite language. I tried to like Rust, i truly did, but once I tried Zig, I fell in love with how easy it was to just "do stuff"
Yeah, it’s so easy to implement a trait on a struct, right?
@@egorsozonov7425 It is, there are multiple ways of doing that with the @hasDecl for example, and with comptime evaluation, and anytype.
@@egorsozonov7425 traits on structs are indeed one of the easier parts of rust. it's not a feature of zig, and there are much more difficult parts of rust.
@@egorsozonov7425Zig doesn't use traits, using a different language comes with learning how to use it
I have been dabbling in Zig when I get the time, and it is indeed a a super interesting language that I definitely want to deep-dive into as my next "go-to" language. It is definitely my own skill issues, but I find Rust to be too restrictive to do the things I want to do (mainly game-dev stuff), and I too often find myself fighting against the language instead of just getting stuff done.
Danke!
Yo prime, nice to see you on more zig. Regarding the try syntax: postfix operators are not a big thing in zig in order to promote explicit intermediate values. Zig is a hardcore imperative language, so chaining is intentionally kept to a min.
Finally Prime coming around to Zig. I believe its going to replace C for sure. They have alot to do at the moment, though.
The man is like a squirrel. Everything catches his attention at some point.
@@TehKarmalizersquirrels eat nuts. He may give everything attention, it doesn’t mean he comes around in everything. He likes zig. He doesn’t like every single project.
Hey dudes! Glad to see Zig being explored and curiosity growing day-by-day. I've got a couple of playlists for learning Zig. Zig Master covers the latest version: th-cam.com/play/PLtB7CL7EG7pDKdSBA_AlNYrEsISOHBOQL.html&si=rylNoBpDV14kfjIh ; and Zig in Depth covers version 0.11: th-cam.com/play/PLtB7CL7EG7pCw7Xy1SQC53Gl8pI7aDg9t.html&si=-py8hirleVyyKpHj . For Spanish-speakers there's also Zig Master en Español: th-cam.com/play/PLtB7CL7EG7pC960XOA5vymEyTfQ3M_QhL.html&si=vcTfQf5TEwwwRURk
Love your zig vids!
Your Zig playlists are AMAZING!
Yes, they are.
A big difference with Zig/Odin/Nim/etc … vs The Others, is independence. They are run by programmers, for programmers.
Development costs are funded by genuine enthusiasts, with money flowing back to hiring qualified contributors.
There is no committee of highly paid political lobbyists who suck up the funding, telling the pleb volunteer programmers what to do next and how to do it.
Proper Freedom isn’t always the most efficient way to get anything done .. but damn, it’s the most fun by a long shot.
You don't understand. We just approved the C++45 standard with 4748292 new features. We expect the people behind gcc, llvm, etc to start programming at once.
The only way you can make driving 100% safe, is just to not drive.
sure. we can agree that staying home forever is a nonstarter.
but we can also agree that riding a JATO rocket everywhere also isn't safe.
and we can also optimize the safety of the car itself, the training of drivers, the road construction and city planning, and the rules of the road.
it needs to turn into a series of conversations and agreements for someone, somewhere. and it can be valuable for us to at least understand those conversations, and possibly for us to be involved in those conversations in some cases.
@@blarghblargh Sure, what I'm trying to say is that no matter how much we improve languages, generate patterns, tools, etc. Problems will be latent. As such, we must try to not avoid them, but tend to them. And I feel the better language is the one that does just that, in a simple and elegant way.
@@keymatch-clovis I don't think simple and elegant are necessarily always the right tools. sometimes what you need is for bugs to stick out like a sore thumb. this is especially true in languages focused on performance, where you actually need to do some "risky" things for purposes of efficiency, and need a useful way to thoroughly audit them.
But yeah I think I generally agree with you. I just think a lot of people (not necessarily you, here) choose to use blanket statements to cover up things they don't want to deal with, when really the whole ecosystem could benefit from more expertise across the board. We will get to significantly better places through hard work done by lots of people, not (just) with savior languages or magic bullet features. Those can help too, for sure, but they're not going to save us.
Trains are the answer most of the time.
@@jamad-y7m if your Tesla has the portable extra dimensional wormhole installed, maybe. Studies show that Tesla drivers are very accident prone. They also don't magically save you from tractor-trailers or vehicles that are significantly taller, like SUVs
Are we going to get the reaction to the I'm Leaving Rust GameDev article as a vod?
18:02 A similar mechanism to defer exist in Dlang: scope(exit)
29:28 Compile time function execution (CFTE) like this could be done with Dlang already ages ago.
Anybody else here who remembers segment registers and non flat address spaces as on the 8086?
8:02 Agreed, but that's also because computer science has based its curriculum off of C (and C-like languages) for half a century. It's like saying a piano naturally represents music theory, where in reality the standard 12-tone scale is largely built around the piano. Not to say C or the piano are bad or holding back either field, just that their ability to feel natural isn't unique to them nor an accident.
15:54 Why is Result an "evil" statement. Frantically asking since most of my error handling is done this way lol.
Not too familiar with Rust but couldnt it be rewritten as Result where ErrorKinds is an enum where you put your possible errors?
There is nothing wrong with it if it fits your needs
You normally make an enum with all the possible errors, makes it possible to fully handle all errors (not having some default which mostly is panicking). Also it's a little bit faster (no box, no vtable)
We just use anyhow
@@Aras14 there is nothing wrong with doing that if it fits your needs
@41:59 Matheoux7 posted "zig reverted async"! That is so important. Zig was about to go down the C++ route of including all the latest 'cool' gimmicks, but in the process introducing all sorts of footguns (footgun mentioned). Thank god they reverted it. Well done Zig team. The devil is in the details though.
But what is the alternative? Do they focus on something like channels? Or what is the new approach?
@@ITSecNEO I've used Go's channels and they seemed to be nice; but it would be better still to have a thread orchestration primitive, and then the compiler could do static analysis on it.
I had the same opinion about “what should I learn next?” questions. But then I spent 4 months learning Rust for game dev. It isn't very good for that. Looking back, if I asked and read more opinions, I would spent that time on something more useful, like making my peace with Cpp.
Why isn't it good for game dev, more precisely? Genuinely asking
@@leeroyjenkins0Well one word describes it pretty good: Lifetimes. Game Dev is also all about performance, so you need to handle GPUs very good and also need to support multithreading and other performance stuff. Rust is definitely not the language where you want to do all that, trust me. There are a lot of game engines for Rust, but literally not a single game (with bigger impact) made with one of them 😅 so yeah, try Rust for Game Dev, but you will not be happy
I just love how Prime and LowLevel are becoming friends. They're just my favourite TH-camrs
My favorite way to do error handling in Rust is by returning a `Result`. When an error occurs, you simply eprintln!() it and return Err(()). So if all of your functions do this, it's very easy to use the `?` operator and not worry about converting between error types. Of course, this might not be the most versatile approach, but for application code it's fine 99% of the time (Library code is different)
Have you heard about the anyhow crate?
Try color-eyre crate
Funnily enough, this makes it work closer to how it works in Go. And I often hear people say Go should adopt something similar to Rust's error handling.
@@ehllie The whole point of my approach is that I don't have to download extra crates. So no
when i'm prototyping i tend to make a "generic" result type that can catch anything that implements the Error trait, it works well: type GenericResult = Result
46:25 read the tests next to the function implementation :)
The zzd example is missing `defer file.close()`, no? I'm fine with explicit allocations if combined with RAII.
Doesn't the compiler error if we forget to defer?
LLL/Ed was one my childhood best friends (12-16), we wrote game maker language code/built 2006-2010 style websites (that I often had to "fix" because I had 1 or 2 years more experience than him). We'd stay up all night programming and studying and drinking energy drinks (vault gang/mr coffee gang). We woke up so many days at his parents house at 2-4pm because we stayed up til they made us coffee and breakfast when they woke up, my parents would always let me stay over because they knew I was working on stuff/learning, super funny hahaha. It's crazy to see him on your channel! Long live the joveproject and long live mario fan games.
Don't forget about the ROM hacks haha.
zig is a great centrist systems language, its almost exactly what a C continuation should be imo.
I just like Zig's compiler. I can write my code, in C or Zig, and compile it for all of my supported platforms with a single command. Right now, I'm working on a library similar to GLFW or SDL, and being able to use C to talk to libraries like Xlib in a more reasonable fashion while using Zig to do the "hard" stuff, all using a single build file is just so nice.
Compilation for all platforms is half LLVM and half a licensing issue for the SDK. IIRC, Zig is doing some heavy lifting there to package up the platform SDK for you without hitting licensing issues, but Rust should get it "soon" (raw-dylib feature), in a way that arbitrary packages can define the linkage across targets without external libraries (and it's already supported by the windows package).
14:40 I sort of think there's more common space on this between you and Uncle Bob than you admit; IIRC his advice in his talks is boils down to "babysitting" the try/catch in to a function of its own, and then return a "normal" value. (I'm not sure, though, I need to re-watch your interview with him.)
C is chaotic neutral, chaotic evil is C++.
is lisp chaotic good?
I'd call php chaotic evil. or perl.
@@blarghblarghlisp is lawful evil
For me the most confusing thing with Zig is its allowance of . to dereference a pointer and access a struct’s members. In C++ it’s super clear that I’m dealing with a pointer when I use ->. While that may make it easier to write it makes it a lot harder to read; am I operating on a copy of the data or the original data?
C is awesome, super simple, and with the newer safety stuff like shadow stacks, _s methods, etc, it's getting safer and safer to use.
sidenote: a lot of C standard libraries refuse to implement the _s functions
that includes glibc
@@kuhluhOG shadow stack isn't supported everwhere either, you can still use checked versions like snprintf, or use something like safeclib, was just mentioning that there are safer ways to use c when those things are available.
True on the first part. With a bit of preproccessor magic I can have most of the niceties of zig, many of which done better. IMHO, zig has made some really stupid choices. But shadow stacks suck too. I'll rather have security through clean and/or statically verified code than have my assembly littered with that codebloating endbr64 nonsense. -fcf-protection=none and nice dense assembly outputs for me please.
@@pskocik tbf, the endbr64 (and other assembly weirdness) comes from the fact that LLVM can sometimes produce weird code when it gets input it doesn't expect (which is something a lot of projects using LLVM but aren't part of the LLVM project like clang have a problem with actually)
but well, we will see how long term Zig's self-made backend will end up
but there is one thing I disagree with you: the C preprocessor sucks; and to this day I haven't seen one preprocessor thing where I would be like "yeah, that's better than what you can get in Zig or even C++99 templates" (and the latter is quite frankly a really low bar)
@@kuhluhOG true, though you can always use something like safeclib or equivalent if you want more safety on glibc
Pointers to stack allocated objects caught me so much when I started with zig
I'm curious why his allocator is the page allocator. Won't each allocation will give an entire page of memory regardless of how small the allocation is?
You're supposed to figure out your memory layout upfront and ideally allocate all of it in one swoop.
You're right. I think it would've been better if he used page_allocator as described under the "Choosing an Allocator" section of Zig's official documentation, where it is shown how you can wrap the page_allocator in an ArenaAllocator to get something more similar to a dynamic array/vector. I can say from a year of experience with Zig that arenas are awesome, since you don't have to worry about freeing ptr1 nor ptr2 individually, as it all happens at the .deinit():
var arena = std.heap.ArenaAllocator.init(std.heap.page_allocator);
defer arena.deinit();
const allocator = arena.allocator();
const ptr1 = try allocator.create(i32);
const ptr2 = try allocator.create(i32);
@@sanderbos4243 Another thing I like about the arena allocator is it can be reset at any time while retaining the capacity and be reused.
And yeah ghost allocations is the reason that when I worked in medical systems we weren’t allowed to use libc. We wrote all we needed ourselves, as to be damn sure that if libc changed or the platform changed the code was still tested and working. Last thing you want with an insulin pump (and that was the junior/medior development because insulin is forgiving) is that you had a OOM and in an embedded device you don’t see that, and it will not deliver that insulin when needed.
I've used Python and D recently, and I'm thinking of trying Zig for an upcoming project.
Odin is more like C than Zig is even though it's also quite Pascal-like. Zig has the momentum from Bun. I like both, and Rust. Go doesn't bring back the joy of coding C that Zig, Odin, Rust, and Swift do.
Go is boring, but it gets the work done. Zig, Odin, Rust and Swift are more interesting, but also have a higher learning curve. They're all good languages, for different reasons. If I had 2 days to write a prototype, I'd pick Go. If I had a year to write a solid program, I'd probably choose Rust. And if I also needed interaction with C, I'd go for Zig.
I tried both Zig and Odin. Odin wins for me. Zig is annoyingly verbose. Coding in Odin is a joy in comparison.
@silas-bv1ql That's not what I've found. I had some outliers when I was experimenting with all these languages at with some of them there was a slowdown caused by array/slice bounds checking which, in Odin and Zig at least can be turned off. Some were also affected by their dynamic array or map/dictionary implementation. The one that surprised me by its slowness was Swift, but unlike Odin and Zig I didn't go to their Discord to ask for advice so maybe it could've been better.
@silas-bv1ql How big difference was it now? Last I checked it was a pretty small difference
8 seconds in, he says "we're like 2 minutes in" lol
18:10 ok, that's amazing
But doesn't go essentially have try/catch with panic/recover and rust with panic/catch_unwind?
try/catch can have it's usefulness. It can be much easier to escape multiple levels of functions with a simple try/catch then multiple levels of returns and if/match statements. But if you don't like try/catch then you can just think of throw as panic and just don't catch it. Nothing is stopping anyone in any that has functions from returning an error rather than using try/catch.
The fact that I can install zig as a clang replacement in my windows for some libraries/apps is just mindblowing
most of skill issues in rust can be wrapped in unsafe.
Came for information about Zig, instead got inspired to learn every day and live life as it comes to me and use my best judgment rather than worry about what perfect is all the time.
It depend on the user and which area targeting. For this it is portable and small. But depend on the size as it need cross platform tool compiler to handle those stuff. To able to export to different platform is easy and hard. vs those toolchain has big file depend which toolchain is it and packages. zig is about 300mb last checked for exe size is 150mb. While other is +400mb. It depend on application and packages. It all one package or crazy different config builds.
I am not sure, what you are saying here, but just to clarify:
Zig can cross-compile to a lot of different architectures and operating systems out of the box.
Something that looks important to me about Zig is it seems less opinionated, and I think a language that simply 'allows for' but not built around assumptions, that is what I look for ... (I take the same view with social and economic systems. lol)
I don't know because I haven't really spent time with Zig yet, but it looks appealing.
I think defer is a bad design...this code demonstrates one of the reasons, where is the close for the file? The defer was missed.
There are many other issues with defer like scoping, slow, etc.
EDIT: Just spotted fBuf clean-up was missing
There are zero jobs for Zig yet, but anyone who can get rid of GC while enforcing safety against leaks is a genius. Keep pushing and get more VC!
26:30 "You should learn," and the round of applause. Great, Primeagean! Very good.
Now tell that to an employer who prefers 100+ years of experience in every effing damn framework for ONE language (otherwise, if your interests are broad -- you're considered mediocre at everything, at best, from the get go) as deep as possible for the "new grad" position for 16/hr
31:42 I LOVE this feature!! It's like having a garbage collector without the garbage collector
Wise words from ThePrimeagen:
"If you can just keep on having something you can do again, that's better than the thing you'll do once."
Or equivocally: smoke weed everyday.
I keep equivalating about that.
@36:00 ‘skill issue’ is just ego stroking. P ! NP
Difficulty can’t just be hand waved away…
Writing and reading zig code is so freaking simple!
I just end up writing actor systems over and over again in async. Someday I’ll figure out macros and make that into a proper crate.
In terms of safety, medium-core C++ is straight up safer than zig. As long as you're using smart pointers, as long as you never use new/delete/malloc/free manually, you're already never going to get memory leaks in C++. In zig, absolutely nothing stops you.
21:51 It seems Ziggs has a sort of like a global "std enum" for errors. I think the reason Rust isn't using this `catch |e| switch (e)` is the fact that Rust's Errors are not something special of the language, but a sort of neat byproduct of the design choices done, aka Enums. so far, the only thing that makes Error special is the fact that it is implemented by std, and everyone is following std. So far, no specialized syntax to catching errors. Even the "?" used to early return errors are being converted into a Trait call, which is for now, a step closer to make Rust's std more like a library instead of Compiler's Magic doing background work for you.
The biggest problem about Zig is that the language is still very unstable ATM. I'm actually working on a game using Zig and Raylib and things get broken every major update. Aside from that the language is a joy to work with as long as you're prepared to potentially adjust your code due to breaking changes every now and then. Also LLM assistants have yet to adjust to the latest version of the language. That said I can see it being my favorite language once the language itself is stable enough.
Hmm seems like a lot like Odin but with more syntax quirks on top and the nice comptime which it currently doesn’t have.
people tend to search for a more optimal path when they want to do less work which ithink many programmers now adays because alot of people go into programming for money (happens in all careers that balloon up)
yeah life also gets pretty busy when you're not a CS student/beginning of your career dev. Happens in most areas as you get older. The fluff falls to the wayside.
The answer to "should I LEARN X or Y" is always "you should learn X AND Y". Obviously you don't have to master both things, but you gain so much more insight when the time comes to answer the question "which language should I USE (for a particular problem)". Unless you're jumping between Functional, Procedural or Asynchronous language families, all languages are similar enough that there is no reason you can't dip your toes into all of them enough to be able to answer the question "which language should I MASTER and/or USE" when the time comes. And since there is no such thing as a "single best language for all problems", you're gonna need to be learning as many languages as you possibly can anyways (and trust me, once you've learned at least just 1 of each of the major language classes [functional, Procedural, asynchronous, etc] it's 10x easier to hop to other flavors of the same general class of language). So always do your best to answer these questions yourself. When you no longer need to ask these sorts of questions because you've experiencially answered them yourself, you've leveled up as a developer
Programmers know A or B allows both. : )
@2:08 - I couldn't agree more. Hope there's some consideration for it as it becomes more mature.
But... what about Nim? Where we can place it compared to Zig?
Is there anything that Zig adds that couldn't just be added to Rust?
Like the build logic/comptime feels like it should be able to expanded on further in Rust's proc macro system.
I say this because Go's greenthreads were so popular they just got adopted everywhere.
A lot of Zig's appeal comes from features it doesn't have. Zig has enough functionality without being overwhelming, so Rust can't do that without becoming even more complex. Zig is also willing to break to achieve the fastest possible performance, Rust can't really do that either since it's past 1.0. And Zig has had an absolute shitton of time put into hot reloading and compilation speed. While these aren't yet ready, they'll be other killer features that simply aren't possible in Rust due to its complexity and reliance on LLVM.
Zig's `comptime` reminds me of Perl/Raku's BEGIN.
zig is pretty much the modern C but when I tried it there were a few annoyances specially there is pretty much no support in the language for any sort of interface/trait(or either I have massive skill issues) to share functionality which could lead to repetitive code but the language is elegant though and I am excited for 1.0 release and hoping they polish the tooling specially the LSP because it takes up a lot of resource and kinda buggy.
“anytype” params sort of do that - the compiler ensures the param matches the required interface, without having to define & maintain contracts.
A different approach, yes, but it solves a similar problem
@@steveoc64 I mean that's cool but feels like sort of a hack for something that should be native to the language
But interface/trait also have no support from C. There are other languages that have them but they're not like C or Zig.
Did @ThePrimeTime managed to do the C course for DSA?
rust is like trying to be cpp alternative, creating cpp...
i like zigs idea. clean and simple.
I was thinking about the Linux kernel including Rust. I think that since Zig isn't 1.0, it won't be considered, yet. Zig may be closer to what we would want in the kernel, since it doesn't have hidden control flow. I could be wrong here, and I'm to busy to put in the time to figure out if I am. The main problem is thread safety, but when you're in the kernel, the Rust compiler doesn't have information about everything, so the thread safety is only for what's made in Rust. I'd like to do some Actor Oriented code in Zig to see how safe that pattern could make things without needing a borrow checker, which seems to be what blocks many people from using Rust.
Never heard of "memory disclosure leak"?!? What is it compared to memory leak?
"I don't know what it means to attach a payload to an error". Alright man
What if you port your Go code to Odin? It will be a lot fun.
I was Ok with Zig but read the issue (zig fmt) of tabs and 2 space indentation and almost felt like the proprietary Rust
Oh and learning Zig, like I have showed in my first video, is to open it stdlib source code and read the tests and code. Because documentation is currently lacking and the language is changing a lot.
Prime slowly becoming the Zig version of his Elixir dev meme
proc_marco is extreme hard , but once it over, it become the best templating tool to reduce the most of dev time
the problem of go is actually not GC for most perforamce use cases but its green threads. the problem is the slowest ffi in the world. i dont know how its not but a go callback called from c could have up to 1ms call overhead due to the green thread stuff go is doing.
writing a game engine under those condition where you simply need to talk a lot to the OS is just unfeasable regardless of any other features of the language
I agree! Rust gets very hard and unfriendly in embedded systems. And when I did Zig (I have a couple of videos) it all is so simple in comparison. It’s a bit verbose here and there although Rust is that too, but you don’t need to do lifetimes; which is a terrible syntax imo, looks like a hindsight implementation. I choose Zig for any project I’d normally would use C now.
I've get yt recommendation: Vlang: "The language of 2023". Year Old Prime video. But zig at least is working
Where are the jobs for Zig? It's fun learning languages and all, but Zig isnt in version 1.0 yet!
C++ LIIIIIIIFE.
Pretty simple really - different programmers think in different ways.
Languages are a tool to express a thought process about how to build a thing.
Zig is not for everyone, but it’s great for programmers that mostly think in terms of assembly and system calls when they are coding a solution. (Just like C programmers do)
There aren’t many programming languages left that target this direct mode of thinking.. so it’s nice that Zig exists in this space.
The stdlib is a bit of an evolving mess, but that’s fine, as it’s more a collection of suggestions at this stage rather than a hard reliance. Doesn’t get in the way at least, and isn’t needed for a lot of jobs.
If you are in this camp, then unused vars (for example) is a bug, and deserves to be a compiler error. Likewise - formatting code is not a concern, and syntax quirks are what they are.
I learned assembly before I learned C and for me Zig still feels more abstract than C. Odin feels more like C as in allowing the direct mode of thinking that I don't have in Zig yet. When trying to feel out new code, debug, iterate, refactor, the unused vars thing has not stopped irritating the hell out of me yet. Maybe if I mainly used Zig that would stop?
@@andrewdunbar828 just turn the option on in the language server to format on save - it should inject lines of code to stub out decl for unused vars
And use underscore for the name of unused params
It’s similar to the way Go does it
You asked about async in Zig. Worth noting that async has been removed from Zig for a couple of major releases now. They deemed their first implementation flawed and scraped it 🤨
I opened yt to learn about UI libraries. How the hell did I end up here?
I was interested into trying zig for embedded, but their repo about it seems to be abandon from a few years... while Rust embedded team made miracles to give safe and generic interface to pretty much any LLVM supported chip
The catch part is the same as let Ok(_) = ... else { } or let x = match { };
Idk why I’m so obsessed with Zig atm. Currently studying for 3 exams so I don’t have time to code in it, but I can’t wait to get my hands on the language.
Something about it just appeals to me
As a mathematician I gotta confess... Golang's " :=" syntax is just awesome, I loooove it 😎
Saw a comment about C++ modules. Get cmake nightly and clang 19 (may have to build from source tho, or ask your linux distro community)
Both `import std` and custom modules work
Have fun!
28:58 bro you can do that with rust macros you know?
The primes take is different to mine. Rust does focus on giving you a language which feels like a high level one but is really low, this is what most people interact with. Rust also has 'unsafe' as i'm sure we all know, but it is nothing like C or Zig. A simple way to explain this is with C and Zig (pointer based languages), it is made very easy to read and write from pointers. Rust makes it safer; you can still write Rust byte by byte, but the verbosity is enormous compared with C or Zig. Again Rust has an interface in 'unsafe' Rust with methods on say a `*mut u8` has methodscalled write() write_bytes() which make reading to a writing to a bit different. The point is trying to write unsafe like C or Rust can be don't but it's difficult, even in 'unsafe' there is still methods to help ensure lengths are taken in a the very least, or they can be fail. I get the appeal of Zig, and i'm hoping my son picks it up. But i'm settled on Rust, i learned it, i know it and i'm good with it