I appreciate your thoughts, but if you view this as wasted time, you likely don’t put the same value on learning new things as I do - and that’s okay! People have different priorities, but I do not view this as wasted time :)
I’m contemplating learning zig, but my go to project for a new language is writing a web crawler, but zig only supports threads, so I’d love to see some sort of how to do async for client http requests. Thanks!
Zig currently does not support asynchronous code or green threads without pulling in an experimental runtime like Zap. If you're interested in writing asynchronous code in a systems language without a garbage collector, I would recommend Rust with the Tokio runtime. The latter is battle-tested and is proven in large industrial-grade systems. Granted, Rust is a more complex language and requires more up-front cognitive investment, but I like to think of it like riding a bike: it sucks to figure out, and you'll get hurt a few times, but once you get it, you've got it and you can never forget it.
@@jenreiss3107 The problem I have with Rust is that I feel deceived with their async story. One of the tag lines has always been “fearless concurrency”, yet they break that promise with the footguns when trying to do async in rust. I was willing to climb that initial hill of learning a more complex language for the benefits it would provide. But I feel duped with the async implementation and footguns. If I don’t get those guarantees with the addition of async, why do I want to deal with the complexities of the language? That’s why I’m eager to see how zig’s async story will evolve. In the meantime, I’d love to learn how to do be able to make multiple client http requests using nonblocking IO-even if it’s using some other C library from zig. I just have no idea how to start as this is a bit lower than I’ve gone in the past, which is why I was hoping @CodeWithCypert would entertain the suggestion.
Zig.guide and reading the standard library source code as well as actually building things in Zig. This would be my top three that I mentioned in the video
The syntax may change and new tools may become available, but the core things you’d learn from using Zig now will still be useful imo - things like allocators, preventing leaks, etc.
I have looked at your comment so many times now and while I’ve read Orwell’s animal farm (albeit many, many years ago) I’m having a rough time understanding if your comment about comptime is satirical or not haha
also, we should collaborate sometime! I've decided to stream / make videos again as part of the new year thing. I know you're not in Louisville anymore, but hey, it's the internet!
I'm going to take your offer for the topic to discuss: comptime. I've been avoiding it coz I've been told once we implement comptime, it will spread to the rest of our codebase like a plague. The same as I have avoided unsafe Rust in favor of safe Rust or C++ in favor of C lol.
I haven’t seen comptime become an invasive species, but I believe conservative use of it is probably key, just like unsafe in Rust (I’m aware these are two very different concepts though). Time will tell as I end up writing more zig though!
As an industry, we've spent the last 5 years learning about how >80% of all new software bugs are caused by human-error in memory unsafe languages that require the programmer to manually allocate and free memory. Now, the hot topic is to throw out all that learned experience, and go back to writing a tower of if statements while manually calling alloc() and free(). Zig can be a good language to learn if you're interested in learning more about how the software works under the hood, but you shouldn't expect that learning Zig will open up job opportunities for you. Being a competent professional is more than just being good at coding: you have to consider how your code will be interacted with by others, how it could possibly fail, and how to design a system that can be maintained for years post-hoc.
@@CodeWithCypert I would add that for people who are interested by this kind of low level work, getting really good at Rust can be great too. I've worked professionally in rust for the past 3 years, and I find it to be incredibly productive for working on low level systems. One of my coworkers used to be an engineer at Citadel working on high frequency trading systems in C++, and his insight was that while Rust's compile times are much slower than for a web-focused language with a high level of abstraction and a built-in runtime, It is much, much, much faster than build systems for legacy codebases that have CI runs that measure in hours, not minutes. For me, I enjoy problems where I get to weigh a mutex on one hand and an mpsc channel on the other. I like having that level of control when it comes to OS primitives and system design. In that space, Rust is the clear winner, as I can make those kinds of low level decisions without waking up in the middle of the night sweating about whether I added a call to malloc() or free() in the right place, or if I used an array of pointers when I should have instead used an array of indexes.
comptime is not amazing at all! languages like Forth for example give you complete access to the whole Forth VM both at compile and run time. Zig's comptime is so limited and used as a buzz word for marketing by the Zig fans, kinda like what Rust people are doing with their "safety" features which is false too.
i get rust's saftey being way overstated, but i really havent seen comptime being buzz worded to market zig, i hear far more about the build system, c interop and simplicity, i see newer zig users thinking comptime is cool but not much else
Comparing to what ? to language runing on VM ? LOL ;) Zig comptime is not limited, it is suited for it needs, maybe optinionated choice but vaild choice to avoid macros, generics and other magic.
@@AK-vx4dy LOL? There are many different flavors of Forth. There are even Forths which compile like C and are super fast. It is not just a language on a VM, there are many different flavors both interpreted and compiled. Zig's comptime is limited, and only gives you a bunch of things which you'll need. You don't have the whole compiler power at your hands with its comptime unlike Forth and Lisp (Though Lisp is not low level so I didn't mention it).
@@deadmarshal Yes both are they own league. And you're right i misunderstood what you appealing to, I'm not sure if Forth abilities should be mixed with other languages features called comptime or constexpr. In this case limited is very fair and generous description.
I am a Go dev that wants to learn Zig from these videos! Thank you!
Awesome! I hope they help! Go is my primary language, so I’ll likely be comparing a lot of the zig code to Go code!
So you want to waste your time or break your toy project?
I appreciate your thoughts, but if you view this as wasted time, you likely don’t put the same value on learning new things as I do - and that’s okay! People have different priorities, but I do not view this as wasted time :)
I’m contemplating learning zig, but my go to project for a new language is writing a web crawler, but zig only supports threads, so I’d love to see some sort of how to do async for client http requests. Thanks!
Zig currently does not support asynchronous code or green threads without pulling in an experimental runtime like Zap. If you're interested in writing asynchronous code in a systems language without a garbage collector, I would recommend Rust with the Tokio runtime. The latter is battle-tested and is proven in large industrial-grade systems. Granted, Rust is a more complex language and requires more up-front cognitive investment, but I like to think of it like riding a bike: it sucks to figure out, and you'll get hurt a few times, but once you get it, you've got it and you can never forget it.
I appreciate the suggestion and will add it to the list, @fixpoint!
@@jenreiss3107 The problem I have with Rust is that I feel deceived with their async story. One of the tag lines has always been “fearless concurrency”, yet they break that promise with the footguns when trying to do async in rust. I was willing to climb that initial hill of learning a more complex language for the benefits it would provide. But I feel duped with the async implementation and footguns. If I don’t get those guarantees with the addition of async, why do I want to deal with the complexities of the language? That’s why I’m eager to see how zig’s async story will evolve. In the meantime, I’d love to learn how to do be able to make multiple client http requests using nonblocking IO-even if it’s using some other C library from zig. I just have no idea how to start as this is a bit lower than I’ve gone in the past, which is why I was hoping @CodeWithCypert would entertain the suggestion.
@@CodeWithCypert Thanks! More rationale for my request in my response to the other commenter here.
What are your recommendations to learn zig? Seems to be evolving fast which quickly out dates books/blogs
Zig.guide and reading the standard library source code as well as actually building things in Zig. This would be my top three that I mentioned in the video
Amazing....
Do you think building something in Zig (0.13.0) and let's say building something in Zig (1.0) will be radically different?
The syntax may change and new tools may become available, but the core things you’d learn from using Zig now will still be useful imo - things like allocators, preventing leaks, etc.
Another day, another win for Zig!
You seem quite invested in Zig winning something haha
Animal Farm.
Four legs good two legs baaaaaad.
Comptime gooooood!
I have looked at your comment so many times now and while I’ve read Orwell’s animal farm (albeit many, many years ago) I’m having a rough time understanding if your comment about comptime is satirical or not haha
Defo need that Zig Zap tutorial with postgres ;)
I plan to start working on it soonish!
It's not in the std lib, but there's a great rust crate - directories - for the app data / storage discovery.
also, we should collaborate sometime! I've decided to stream / make videos again as part of the new year thing. I know you're not in Louisville anymore, but hey, it's the internet!
Good to know! Thanks for sharing that!
@ I’m just on the other side of river :)
@ lmao for some reason I thought you were up in Indy! Good news!
Also, I think RUclips broke replies heh
I'm going to take your offer for the topic to discuss: comptime.
I've been avoiding it coz I've been told once we implement comptime, it will spread to the rest of our codebase like a plague.
The same as I have avoided unsafe Rust in favor of safe Rust or C++ in favor of C lol.
I haven’t seen comptime become an invasive species, but I believe conservative use of it is probably key, just like unsafe in Rust (I’m aware these are two very different concepts though).
Time will tell as I end up writing more zig though!
Nice!
Glad you liked the video!
Can you do more videos FROM SCRATCH?
A fair number of my videos have me coding from scratch :)
@CodeWithCypert Yes the more the better :) im a new subscriber, some channels start halfway and then I dont have any clue whatsoever.
@bobby9568 I appreciate the feedback!
As an industry, we've spent the last 5 years learning about how >80% of all new software bugs are caused by human-error in memory unsafe languages that require the programmer to manually allocate and free memory. Now, the hot topic is to throw out all that learned experience, and go back to writing a tower of if statements while manually calling alloc() and free().
Zig can be a good language to learn if you're interested in learning more about how the software works under the hood, but you shouldn't expect that learning Zig will open up job opportunities for you. Being a competent professional is more than just being good at coding: you have to consider how your code will be interacted with by others, how it could possibly fail, and how to design a system that can be maintained for years post-hoc.
Good insight, and I agree in regards to job opportunities. My main recommendation for people seeing work is JS, TS, or Python for that reason.
@@CodeWithCypert I would add that for people who are interested by this kind of low level work, getting really good at Rust can be great too. I've worked professionally in rust for the past 3 years, and I find it to be incredibly productive for working on low level systems.
One of my coworkers used to be an engineer at Citadel working on high frequency trading systems in C++, and his insight was that while Rust's compile times are much slower than for a web-focused language with a high level of abstraction and a built-in runtime, It is much, much, much faster than build systems for legacy codebases that have CI runs that measure in hours, not minutes.
For me, I enjoy problems where I get to weigh a mutex on one hand and an mpsc channel on the other. I like having that level of control when it comes to OS primitives and system design. In that space, Rust is the clear winner, as I can make those kinds of low level decisions without waking up in the middle of the night sweating about whether I added a call to malloc() or free() in the right place, or if I used an array of pointers when I should have instead used an array of indexes.
That’s great insight. I look forward to hearing more of your thoughts in the future - you seem like a wealth of knowledge!
comptime is not amazing at all! languages like Forth for example give you complete access to the whole Forth VM both at compile and run time. Zig's comptime is so limited and used as a buzz word for marketing by the Zig fans, kinda like what Rust people are doing with their "safety" features which is false too.
I’ll have to check out Forth
i get rust's saftey being way overstated, but i really havent seen comptime being buzz worded to market zig, i hear far more about the build system, c interop and simplicity, i see newer zig users thinking comptime is cool but not much else
Comparing to what ? to language runing on VM ? LOL ;)
Zig comptime is not limited, it is suited for it needs, maybe optinionated choice but vaild choice to avoid macros, generics and other magic.
@@AK-vx4dy LOL? There are many different flavors of Forth. There are even Forths which compile like C and are super fast. It is not just a language on a VM, there are many different flavors both interpreted and compiled. Zig's comptime is limited, and only gives you a bunch of things which you'll need. You don't have the whole compiler power at your hands with its comptime unlike Forth and Lisp (Though Lisp is not low level so I didn't mention it).
@@deadmarshal Yes both are they own league. And you're right i misunderstood what you appealing to, I'm not sure if Forth abilities should be mixed with other languages features called comptime or constexpr. In this case limited is very fair and generous description.