Is 2024 The Year Of Zig ?
Вставка
- Опубліковано 6 тра 2024
- Recorded live on twitch, GET IN
Reviewed Video
• zig is the future of p...
By: Low Level Learning | / @lowlevellearning
My Stream
/ theprimeagen
Best Way To Support Me
Become a backend engineer. Its my favorite site
boot.dev/?promo=PRIMEYT
This is also the best way to support me is to support yourself becoming a better backend engineer.
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Kinesis Advantage 360: bit.ly/Prime-Kinesis
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/deeznuts - Наука та технологія
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
@@VojtaJavora 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
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.
"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.
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.
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.
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 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++.
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.
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
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.
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.
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.
Your interview content is always so good. More please.
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.
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.
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.
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.
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.
@@luisalejandroquirogagomez1721 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.
Unless you're in a Tesla
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.
Are we going to get the reaction to the I'm Leaving Rust GameDev article as a vod?
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.
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)
Anybody else here who remembers segment registers and non flat address spaces as on the 8086?
Summary cons/pros
- return in Zig is always ending with semicolon. In Rust it is an expression if it doesn't have semicolon. So it is harder to grasp what is going on in Rust.
- performant Rust is 100% harder to understand than performant C++
- In Rust you don't know if something is on heap or on stack. You have to learn it. In Zig you know it.
- In Rust you feel like you program in high-level language. But you actually program in low-level language. And that mentally is a bit of a foot gun.
- Zig is like almost Rust but nicer.
- comptime in Zig is like macros in Rust but you don't have to have doctorate to use it. And you write comptime in Zig. And macros in Rust are like a different language. Level one is syntax. Level two is async and lifetimes. And procedural macros are very hard and like level 3. And you have to dye your hair blue when you reach level 3.
- When you start learning Rust, it is hard. It gets easy and then it gets significantly harder when you jump into async and stuff. When you use some web framework all that complexity is hidden from you. You don't even know what thread you're running on. But the moment you try to write those things, it's excessively difficult and generics can get really, really, really hard. Working with trait objects and generics is non-trivial. And people think it's trivial. And then you go to fourth level. The difficulty of Rust is a lifelong learning process and it is kind of a big issue. It gets exponentially harder. It is deceivingly easy at the beginning and then it very quickly ramps up.
- Using mutex, locking/unlocking it is cumbersome.
- In Rust memory will be freed and you don't know when. In Zig you know when memory is freed.
Also code github.com/rofrol/zzd
Regarding try:
'try' is on the left to discourage chaining on purpose. you can wrap parentheses to get around it, but having to 'try' usually means a resource was collected that you might want to defer. postfix error handling would leak easier.
Technically try is syntax sugar over catch |err| return err;
discord.com/channels/605571803288698900/1238567770157875200
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: ua-cam.com/play/PLtB7CL7EG7pDKdSBA_AlNYrEsISOHBOQL.html&si=rylNoBpDV14kfjIh ; and Zig in Depth covers version 0.11: ua-cam.com/play/PLtB7CL7EG7pCw7Xy1SQC53Gl8pI7aDg9t.html&si=-py8hirleVyyKpHj . For Spanish-speakers there's also Zig Master en Español: ua-cam.com/play/PLtB7CL7EG7pC960XOA5vymEyTfQ3M_QhL.html&si=vcTfQf5TEwwwRURk
Love your zig vids!
Your Zig playlists are AMAZING!
@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.
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?
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).
C is chaotic neutral, chaotic evil is C++.
is lisp chaotic good?
I'd call php chaotic evil. or perl.
The zzd example is missing `defer file.close()`, no? I'm fine with explicit allocations if combined with RAII.
Pointers to stack allocated objects caught me so much when I started with zig
The fact that I can install zig as a clang replacement in my windows for some libraries/apps is just mindblowing
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.
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.
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.
8 seconds in, he says "we're like 2 minutes in" lol
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
18:10 ok, that's amazing
31:42 I LOVE this feature!! It's like having a garbage collector without the garbage collector
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?
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.
most of skill issues in rust can be wrapped in unsafe.
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.
Rust's value proposition is still unmatched. Would comptime be amazing to have? It would. Would switching allocators be amazing to have? It also would. That does not detract from the fact that people make incredible things with it and prototype fast with it when they need.
If there were not already too many new languages, there is probably a great niche for another new language that's mostly an iteration of Rust but incorporating lessons learned from other new languages, especially from Zig. Rust's memory safety, ownership, functional style, etc. Not allowing implicit temporaries is another thing I would take from Zig.
@@andrewdunbar828 I definitely agree. Kinda hope that Rust manages to become it in time, though, instead of another new language (what with new trait solvers, and work on apis). I don't think we need more segregation.
I just love how Prime and LowLevel are becoming friends. They're just my favourite UA-camrs
46:25 read the tests next to the function implementation :)
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.
Zig's `comptime` reminds me of Perl/Raku's BEGIN.
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.
Hmm seems like a lot like Odin but with more syntax quirks on top and the nice comptime which it currently doesn’t have.
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.)
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.
Writing and reading zig code is so freaking simple!
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.
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
If we go right, we take the left type 🤔
zig is a great centrist systems language, its almost exactly what a C continuation should be imo.
rust is like trying to be cpp alternative, creating cpp...
i like zigs idea. clean and simple.
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.
proc_marco is extreme hard , but once it over, it become the best templating tool to reduce the most of dev time
"I don't know what it means to attach a payload to an error". Alright man
@2:08 - I couldn't agree more. Hope there's some consideration for it as it becomes more mature.
Zig is good for complied extensions for other languages FFI and C APIs
As a mathematician I gotta confess... Golang's " :=" syntax is just awesome, I loooove it 😎
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.
“Quick discussion” lol
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.
I was Ok with Zig but read the issue (zig fmt) of tabs and 2 space indentation and almost felt like the proprietary Rust
Prime slowly becoming the Zig version of his Elixir dev meme
my fav. youtube cam boys
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
Did @ThePrimeTime managed to do the C course for DSA?
I will finish Rust but I admit I really liked Zig since I learned about it. If I will stick to Rust it will depend on how I enjoy writing it.
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
But... what about Nim? Where we can place it compared to Zig?
A lot of takes also apply to Nim
Any time people talk about "programming languages" the guy from Office Space pops up in my head asking: "What would you say you do here?"
I’m imagining Prime answering the Wifeagen in this scenario. Well I roll in around 6, yell into the ether about deez nuts until 2 where I have some thing to eat and play with my kids until 7pm where I yell into the ether about deez nuts until 10pm.
i'm waiting for primes fp phase when he denounces go
Ron Burgendy "sqeeeeeeeeeel-X"
I just started learning rust yesterday and now this 😢
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.
But Odin is slower than C, Rust and Zig. Incisive Go is a little more performant than Odin.
@@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
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
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 🤨
it all feels like java from a syntax perspective. What am i missing?
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!
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.
No matter whether I talk to a Zig, Rust, C or Go developer they all seem to share one thing in common: They either dislike or straight up hate C++. 🤨
former C++ junkie. yup. C++ was basically beta in production the language. fortuately it went first, so every language coming after could learn the sharp edges without needing stitches.
"use after freeze" 😛
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.
for those who don't know, you create an error in rust by "tagging" a stype that implements Debug and Display as std::err::Error. it's a zero function trait
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. : )
What if you port your Go code to Odin? It will be a lot fun.
The catch part is the same as let Ok(_) = ... else { } or let x = match { };
Prime is rewriting coffee in Rust
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
2024 is all about Z3 stack: zed zig zustand!
I've get yt recommendation: Vlang: "The language of 2023". Year Old Prime video. But zig at least is working
The answer to "Should I learn Rust or ...?" is yes.
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.