1:25:30 It's funny that prime was watching a youtube video at 1.5x speed, and I am watching Prime at 2x speed, so the RUclips video runs at 3x speed, and at this exact moment that youtube video has 3x speed highlighted on its screen.
I start to think about it in my head because I was like “No way 1.5 x 2 is 3” then i realised it was but was still confused then I thought “1.5 + 2(3.5) is more then 1.5x2(3)” now I’m more disturbed then anything.
it's the same approach I used to take in C, it's so much better than C++ virtual functions cause I can control exactly how I want to construct the vtable. that being said, the more you program in a procedural language, the more you realize how few cases actually benefit from using a vtable at all.
Interfaces can be nice, when the language supports them, but I think they're just not something I'd really want to use unless the language directly supported them. I'd probably usually just use a struct of function pointers, and then only at library boundaries.
I tend to agree. I have been writing a lot of Zig the past few months, and have encountered a few scenarios where an interface might be convenient, but overall I get by just fine without them using other features that are more idiomatic That said, It would be nice to see some Zig features that alleviated some of the pain in implementing interface-like types. I have gotten by using comptime features to enforce the contract of the "interface" (i..e. wrapper type), but it always feels kind icky.
Most times, you can just use anytype .. relax and trust the compiler to enforce the interface contracts, and let you know if your code is missing anything. There is generally no need to re-implement interfaces from scratch. The compiler will do that for you implicitly
This is true for functions, but for structs that need a field with an anytype that implements some functions, here you need an interface because anytype is not available in struct fields.
@@cagataykaydr3015 yes true - storing an interface type is an absolute pain. Currently doing exactly that - options are store an *anyopaque and fiddle the casting at the callsite (YUK) ... or create a union that wraps over them. No good options there. But then again, in Go, I would steer clear of trying to store interfaces anywhere, or returning interfaces from a function, if possible. Agree with you though - life isnt always simple :)
@@steveoc64 Yeah, I wish there was an interface sytnax in this delicious language. Started to coding a 16 bit virtual machine in Zig, and I must say that Zig is a great experience and I learned so much about writing a virtual machine. But right now I'm writing a memory mapper, and it definitely needs an interface type for mapped memory to check if it has read and write functions. Oh god I just started to learn v-tables, I guess it's gonna take some time :) But you're right, it's a pain and if possible, using anytype is so much better
Union enum + inline switch is what I have been doing. Then in whatever struct I have, I have a method that returns self as a the interface enum, to prevent nested initialization.
It's freaking insane how fast you move around in your code. I MUST learn how you do that. I would love to see you teach a course, or maybe you already have, on how you setup your environment to achieve those speeds. Particularly how to do DRILLS to increase keying speeds... Also, that's probably, at least in part, why you suffered from RSI. I can only top out at around 50-70 WPM, depending on the day, and never have issues.
i'm doing the same thing in my project, though with Odin. been messing around with the reflect core library and specialized structs to achieve an interface to allow easier addition of mods to my game.
2 hour session *learning* how to implement an interface, not just implementing one. Rust's trait system with trait boundaries, dyn and impl may (and in the most cases will) take longer to learn than just understanding how dyn works under the hood (it is essentially what Prime is doing in this video). In the end, it is just a pointer to data and a pointer to a vtable, nothing more.
@@Presenter2 em... if you know what vtables and type erasure are, &dyn Trait takes 5 min to explain. Granted, if you dive into complex trait bounds you can get confused, but the basic type erasure is super straightforward. And stuff that would use complex trait bounds would become total nightmare fuel if written by hand.Getting that stuff correct in rust/c++ would be trivial, and in zig... well... you'd have to get good I suppose.
@@alexpyattaev Well, you're correct. What I wanted to tell is that implementing an interface in Zig does not take 2 hours. It took that long because there's a big difference between knowing a theory and implementing this theory in practice (creating your own vtable, creating a fat pointer structure and some helper method to quickly instantiate the fat pointer). *Rust and C++ will do this for you, which will decrease required time and cognitive pressure.*
There's going to be a certain type of developer who thinks the approach from the blog is really cool yet hates design patterns. This is literally a design pattern for Zig, but probably something you'd codegen instead of writing by hand because this is cursed, poorly maintainable code.
i sort of assume that at some point (some size of Zig community), we're just going to have some library for creating interfaces... right? (not sure if it's possible with language like Zig)
Tagged unions are generally superior to interfaces anyways. Some types of libraries/modules are better with interfaces, but as long as you get used to tagged unions, the need for interfaces will decrease massively.
@@AloisMahdalI don’t see how it can be impossible given that we can create interfaces this way. It might be difficult to cooperate with the compiler and LSP if the “interface lib” is made by a 3rd party tho
For some reason the .Foo syntax of zig just wrecks my brain. Im all for low level control but I really don't care to implement my own vtable. Definitely seems like the language has a lot of other neat tricks though
I think the .Foo thing is just about enum (or tagged union, in the .Pointer case where Prime was confused). since it's a typed language, it already knows the type of LHS so if it's enum, on RHS you can just type the second part of enum name, which i think is actually pretty cool.
Zig is great if you know C. There's very little affordance given to the developer otherwise. The compiler is not very delightful and the docs are barren, and hard to look up. But man does it run fast
@@TankorSmash It was the position a few years ago (not certain if it still is) that while decentifying the docs is obviously a precondition to 1.0, it's unwise to do it _too_ quickly as a) while things are as unstable as they are all you do is double the churn, and b) a more accessible language means a large influx of new devs, which the existing small community might not be equipped to effectively help.
Nah man, I code in C and when I look at the syntax of zig I would honestly rather keep coding in C, it is just so bad. Zig could have been great, but they messed up the syntax completely.
@@lmnts556 Syntax is the most shallowest possible thing to complain about at least, what else do you not like about Zig? Errors-as-values is a a big step up IMO
@@TankorSmash That is the exact reason why so many people ditched java, so no you are mistaken. If the way you write the code is bad it will turn away a lot of potential coders because they really can't be arsed to write it lol.
to print to stdout you have to 1. get stdout 2. (optional) get buffered writer 3. write try stdout.print("{} ", .{}); 1. is because zig is explicit and 3. has alot of punctuations with the try keyword and the dot after the apostrophe which is again because zig is explicit about allocations. beside that, zig isn't unnecessarily verbose
Interfaces are more comparable to virtual classes, instead of templates. But yeah, Zig is VERY verbose, like now I know how a VTable works under the hood 😅
What specifically makes it seem "verbose" to you? It doesn't look more "verbose" than rust, C# or C++. I'm asking because I write Zig almost exclusively and haven't noticed anything verbose about it.
1:25:30 It's funny that prime was watching a youtube video at 1.5x speed, and I am watching Prime at 2x speed, so the RUclips video runs at 3x speed, and at this exact moment that youtube video has 3x speed highlighted on its screen.
i could not understand the guy so i slowed down that part to 0.5 speed, making Prime kinda drunk
I start to think about it in my head because I was like “No way 1.5 x 2 is 3” then i realised it was but was still confused then I thought “1.5 + 2(3.5) is more then 1.5x2(3)” now I’m more disturbed then anything.
@@LatterDay-Soldier what are you trying to do 😂
@@ckpioo a lot of things man, a lot of things
It's kind of based how interfaces in Zig are just structs and you have to raw-dog the vtable
it's the same approach I used to take in C, it's so much better than C++ virtual functions cause I can control exactly how I want to construct the vtable. that being said, the more you program in a procedural language, the more you realize how few cases actually benefit from using a vtable at all.
Interfaces can be nice, when the language supports them, but I think they're just not something I'd really want to use unless the language directly supported them. I'd probably usually just use a struct of function pointers, and then only at library boundaries.
I tend to agree. I have been writing a lot of Zig the past few months, and have encountered a few scenarios where an interface might be convenient, but overall I get by just fine without them using other features that are more idiomatic That said, It would be nice to see some Zig features that alleviated some of the pain in implementing interface-like types. I have gotten by using comptime features to enforce the contract of the "interface" (i..e. wrapper type), but it always feels kind icky.
"inline switch" is a time-saver
Most times, you can just use anytype .. relax and trust the compiler to enforce the interface contracts, and let you know if your code is missing anything.
There is generally no need to re-implement interfaces from scratch. The compiler will do that for you implicitly
This is true for functions, but for structs that need a field with an anytype that implements some functions, here you need an interface because anytype is not available in struct fields.
@@cagataykaydr3015 yes true - storing an interface type is an absolute pain.
Currently doing exactly that - options are store an *anyopaque and fiddle the casting at the callsite (YUK) ... or create a union that wraps over them.
No good options there.
But then again, in Go, I would steer clear of trying to store interfaces anywhere, or returning interfaces from a function, if possible.
Agree with you though - life isnt always simple :)
@@steveoc64 Yeah, I wish there was an interface sytnax in this delicious language. Started to coding a 16 bit virtual machine in Zig, and I must say that Zig is a great experience and I learned so much about writing a virtual machine. But right now I'm writing a memory mapper, and it definitely needs an interface type for mapped memory to check if it has read and write functions. Oh god I just started to learn v-tables, I guess it's gonna take some time :) But you're right, it's a pain and if possible, using anytype is so much better
You don't need interfaces in Zig. It's just not necessary you're only wanting them because that's what you're used to.
Can you make generic types like a relationnal database handle ? Sql request in, tuples out ?
Edit: i guess that could be an enum
.Pointer is an enum. Struct fields use the same naming scheme. The . prefix makes parsing context-free.
The best part, the syntax will change!
🤣🤣🤣🤣🤣
doing vtable manually is source of bugs, they definitely need to have some compiler help there
Union enum + inline switch is what I have been doing.
Then in whatever struct I have, I have a method that returns self as a the interface enum, to prevent nested initialization.
It's freaking insane how fast you move around in your code. I MUST learn how you do that. I would love to see you teach a course, or maybe you already have, on how you setup your environment to achieve those speeds. Particularly how to do DRILLS to increase keying speeds... Also, that's probably, at least in part, why you suffered from RSI. I can only top out at around 50-70 WPM, depending on the day, and never have issues.
i'm doing the same thing in my project, though with Odin. been messing around with the reflect core library and specialized structs to achieve an interface to allow easier addition of mods to my game.
When &dyn Trait in is a 2 hour session, and people still say rust is hard...
Its not hard its just verbose
2 hour session *learning* how to implement an interface, not just implementing one. Rust's trait system with trait boundaries, dyn and impl may (and in the most cases will) take longer to learn than just understanding how dyn works under the hood (it is essentially what Prime is doing in this video). In the end, it is just a pointer to data and a pointer to a vtable, nothing more.
@@Presenter2 em... if you know what vtables and type erasure are, &dyn Trait takes 5 min to explain. Granted, if you dive into complex trait bounds you can get confused, but the basic type erasure is super straightforward. And stuff that would use complex trait bounds would become total nightmare fuel if written by hand.Getting that stuff correct in rust/c++ would be trivial, and in zig... well... you'd have to get good I suppose.
@@alexpyattaev Well, you're correct. What I wanted to tell is that implementing an interface in Zig does not take 2 hours. It took that long because there's a big difference between knowing a theory and implementing this theory in practice (creating your own vtable, creating a fat pointer structure and some helper method to quickly instantiate the fat pointer). *Rust and C++ will do this for you, which will decrease required time and cognitive pressure.*
@@Presenter2 yeah, that is true, if you know exactly what you are doing getting the actual lines down is not particularly tricky.
Aren't there videos on youtube of previous work on this project in zig?
There's going to be a certain type of developer who thinks the approach from the blog is really cool yet hates design patterns. This is literally a design pattern for Zig, but probably something you'd codegen instead of writing by hand because this is cursed, poorly maintainable code.
not every pattern, but a lot of them are just a workaround for not having a feature directly supported in the language
This is how interfaces were/are done in pure C, with some Zig specifics on top of it.
All the boilerplate written by hand...
i sort of assume that at some point (some size of Zig community), we're just going to have some library for creating interfaces... right? (not sure if it's possible with language like Zig)
Tagged unions are generally superior to interfaces anyways. Some types of libraries/modules are better with interfaces, but as long as you get used to tagged unions, the need for interfaces will decrease massively.
@@AloisMahdalI don’t see how it can be impossible given that we can create interfaces this way. It might be difficult to cooperate with the compiler and LSP if the “interface lib” is made by a 3rd party tho
1:24:50 LOL! I was already watching at 1.5x, so when you doubled your speed, I was then watching the nested video at 3x. A bit fast.
"somehow you got that joke wrong!"
54:54 Nah bro, you be Zigglin.
Wasn't there another video on the channel a minute ago? Something about 2000 people playing Doom at the same time
Oh it's a main channel video
It would be nice to have token leak section
How refreshing. A community with no one saying "First!"
glad that only people who watch prime are well behaved gentlemen 🗿🎩☕
Yeah, we yell CHROOT CHROOT CHROOT
Sneaky one there ;)
Zeroth it is
First!
zig is a quiche language
For some reason the .Foo syntax of zig just wrecks my brain. Im all for low level control but I really don't care to implement my own vtable. Definitely seems like the language has a lot of other neat tricks though
I really don't see what's so hard about it. It's just a struct.
@@i-am-linja I did not say anything is difficult. I said my brain doesnt read something well, and said the other thing is tedious
I think the .Foo thing is just about enum (or tagged union, in the .Pointer case where Prime was confused). since it's a typed language, it already knows the type of LHS so if it's enum, on RHS you can just type the second part of enum name, which i think is actually pretty cool.
learned Zig before C#. L take.
But in all seriousness, Zig is great and you are cool prime. TOKIOOOOOO in Zig when with liburing
What I'm learning is that I'm too dumb to learn Zig.
Zig is great if you know C. There's very little affordance given to the developer otherwise. The compiler is not very delightful and the docs are barren, and hard to look up.
But man does it run fast
@@TankorSmash It was the position a few years ago (not certain if it still is) that while decentifying the docs is obviously a precondition to 1.0, it's unwise to do it _too_ quickly as a) while things are as unstable as they are all you do is double the churn, and b) a more accessible language means a large influx of new devs, which the existing small community might not be equipped to effectively help.
Nah man, I code in C and when I look at the syntax of zig I would honestly rather keep coding in C, it is just so bad. Zig could have been great, but they messed up the syntax completely.
@@lmnts556 Syntax is the most shallowest possible thing to complain about at least, what else do you not like about Zig? Errors-as-values is a a big step up IMO
@@TankorSmash That is the exact reason why so many people ditched java, so no you are mistaken. If the way you write the code is bad it will turn away a lot of potential coders because they really can't be arsed to write it lol.
last++
Why is bro implementing binary search on a data structure where insertion is O(N) anyways 💀💀💀
Why people say zig is verbose? It is possible yo provide a example?
to print to stdout you have to 1. get stdout 2. (optional) get buffered writer 3. write try stdout.print("{}
", .{});
1. is because zig is explicit and 3. has alot of punctuations with the try keyword and the dot after the apostrophe which is again because zig is explicit about allocations.
beside that, zig isn't unnecessarily verbose
people say rust is difficult and it can be but zig is difficult in it's own ways. i would personally rather deal with the borrow checker.
this looks worse than c++ templates...
Interfaces are more comparable to virtual classes, instead of templates. But yeah, Zig is VERY verbose, like now I know how a VTable works under the hood 😅
SECOND!
Zig is more BS
59th!
I hate how verbose it is
Same, I would rather just stay with C. Lots of YTers try it and just ditch it for c or other languages.
last
Zig syntax feels like java, I hate it.
have you seen Java
@@gronki1 Yes, and writing it and Zig feel similar.
@@lmnts556not gonna protect zig syntax but how can it look like java 's
@@СергейГордиенко-п4д It just feels similar to write, verbose and clunky.
What specifically makes it seem "verbose" to you? It doesn't look more "verbose" than rust, C# or C++. I'm asking because I write Zig almost exclusively and haven't noticed anything verbose about it.
last