The problem with the philosophy "this is how we implement interfaces in Zig" vs actual interfaces is, people will never use these design patterns simply because they don't know them. The user manual never really mentions them (it talks about the Allocator interface once), and doesn't explain any of these patterns. You have to look at the code of the Allocator interface to see how it's implemented. About 1% of the developers will ever do that. And even if they manage to understand, most will think it's just too much hassle. Anyway, I'm glad I found your channel, because it treats in depth a lot of material that one can see nowhere else.
Yes, there's been a lot of discussion in different Zig circles about adding interfaces as a language feature versus the current DIY approach. It's still undecided, but many point to the fact that C has gotten away without native interfaces for decades and it probably has allowed more flexible and powerful interface models to be implemented since the language won't get in the way with its own implementation. Let's see what the future will bring for Zig.
Thanks for the contribution! Many newcomers to Zig from object oriented languages try some complex ways to implement interfaces, but tagged unions are far easier and very ergonomic in Zig.
This one seems odd to me. I would love to see Go's implicit Interface conept, but with types and methods/funcs capable. I can't grok if this does the same thing, but feels like it's sort of a hacky way to try to support interfaces. Super early days for Zig so maybe they'll add interface types at some point that are implicit vs Java/TS/.Net explicit types.
Yeah, whether Zig will have interfaces at the language level is still up in the air. But for now, as with many other things, Zig is taking the C approach of "do-it-yourself" abstractions.
It probably won't, the zig way is always keep as simple as possible for the language itself, if you need a feature you can write it, the moment it has interfaces, the push to for inheritance will also be there, and all of those by definition will need to have a GC, so zig memory model would fail.
@@b3owu1f agreed, but they seem to be very conservative when it comes to new features, a bit too conservative imho. There doesn't seem to be any major new feature in the language in the development path unfortunately. They seem to focus on rewriting the compiler itself to get rid of LLVM. I don't think this should be the priority at this point, stabilizing the language and fleshing out a decent standard library should be. That's how they'll get new users, not having a new compiler. Personally, I think : - encapsulation (private) - inner functions without having to resort to a struct, - and interfaces or perhaps traits à la Rust, are features that should be included in the language. I'm not sure, but I believe these shouldn't break compatibility with C.
isn't this union(enum) approach not practical ? as if you re having an interface in a third party library, and you wanted to apply it to a custom struct of yours, you wont be able to (i am comparing it to Traits in Rust) ? or am i doing something wrong, i am very new to this language ! and thanks for your videos i ve learnt a lot ! Edit: i am dumb i just rewatched it again and you ve mentioned it ! thanks !
I’m not sure I understand why the alignCast is required. Surely the pointer will be set to the actual, already aligned, address of the Stringer implementation? Why does the storage into the anyopaque alter the memory address to come “out of alignment”?
It rally isn't required, it's just recommended as a safe best practice to remind us that alignment issues can happen when dealing with pointer casts, although in this case there's little probability of that. Here's a link to an answer in the Ziggit forum that explains it very well: ziggit.dev/t/vtable-interfaces-and-the-role-of-ptrcast-and-aligncast/2062/2
@@dudethebuilder Hmmm ... I still sort of don't get it :) I guess the comment in the thread you posted to that makes most sense to me is the one calling that maybe the alignment check should be an assert, rather than a cast; this would do "some" (not complete, and probably less than one imagines) run-time checking that you haven't passed the wrong pointer in. If one is always passing in a pointer that the implementation casts to, it seems to be the alignment should always be aligned with the downcast from anyopague to Stringer.
I'm eagerly awaiting (pun intended!) to be able to make an episode about this. But as of now, Zig's async functionality isn't working, so we'll have to keep an eye out to see when this lands.
Yes, but I'm afraid that the new model to be implemented will be very different from the previous 0.10 async model. So the safest bet would be to wait. I'll do some research into the status of this development work to see if an explanation of the old model is viable.
I think you'll find very few people in programming languages communities that would say "standard format" versus the abbreviated "stud fumt". I actually first heard these abreviated terms when working with Go some years ago.
Yes, since we're dealing with pointers (dereferencing and casting them) it's happening at runtime. Pointers can be used at comptime but the functionality is very limited since they don't point to real addresses in memory until the program is actually running.
The problem with the philosophy "this is how we implement interfaces in Zig" vs actual interfaces is, people will never use these design patterns simply because they don't know them.
The user manual never really mentions them (it talks about the Allocator interface once), and doesn't explain any of these patterns. You have to look at the code of the Allocator interface to see how it's implemented. About 1% of the developers will ever do that. And even if they manage to understand, most will think it's just too much hassle.
Anyway, I'm glad I found your channel, because it treats in depth a lot of material that one can see nowhere else.
Yes, there's been a lot of discussion in different Zig circles about adding interfaces as a language feature versus the current DIY approach. It's still undecided, but many point to the fact that C has gotten away without native interfaces for decades and it probably has allowed more flexible and powerful interface models to be implemented since the language won't get in the way with its own implementation. Let's see what the future will bring for Zig.
Thanks for the great demo of leveraging tagged unions for interfaces!
Thanks for the contribution! Many newcomers to Zig from object oriented languages try some complex ways to implement interfaces, but tagged unions are far easier and very ergonomic in Zig.
thank you for explaining common patterns, but in zig
This is really cool! Thanks for the explanation!
Very simple and clear explanation, thank you very much!
Awesome! Thanks Dude!
Great video!
This one seems odd to me. I would love to see Go's implicit Interface conept, but with types and methods/funcs capable. I can't grok if this does the same thing, but feels like it's sort of a hacky way to try to support interfaces. Super early days for Zig so maybe they'll add interface types at some point that are implicit vs Java/TS/.Net explicit types.
Yeah, whether Zig will have interfaces at the language level is still up in the air. But for now, as with many other things, Zig is taking the C approach of "do-it-yourself" abstractions.
It probably won't, the zig way is always keep as simple as possible for the language itself, if you need a feature you can write it, the moment it has interfaces, the push to for inheritance will also be there, and all of those by definition will need to have a GC, so zig memory model would fail.
@@fenilli I dont think so. Go has interfaces and doesnt have inheritance. It can be done.
@@b3owu1f go also has a gc that is the point
@@b3owu1f agreed, but they seem to be very conservative when it comes to new features, a bit too conservative imho. There doesn't seem to be any major new feature in the language in the development path unfortunately. They seem to focus on rewriting the compiler itself to get rid of LLVM. I don't think this should be the priority at this point, stabilizing the language and fleshing out a decent standard library should be. That's how they'll get new users, not having a new compiler.
Personally, I think :
- encapsulation (private)
- inner functions without having to resort to a struct,
- and interfaces or perhaps traits à la Rust,
are features that should be included in the language. I'm not sure, but I believe these shouldn't break compatibility with C.
isn't this union(enum) approach not practical ? as if you re having an interface in a third party library, and you wanted to apply it to a custom struct of yours, you wont be able to (i am comparing it to Traits in Rust) ? or am i doing something wrong, i am very new to this language ! and thanks for your videos i ve learnt a lot !
Edit: i am dumb i just rewatched it again and you ve mentioned it ! thanks !
I’m not sure I understand why the alignCast is required. Surely the pointer will be set to the actual, already aligned, address of the Stringer implementation? Why does the storage into the anyopaque alter the memory address to come “out of alignment”?
It rally isn't required, it's just recommended as a safe best practice to remind us that alignment issues can happen when dealing with pointer casts, although in this case there's little probability of that. Here's a link to an answer in the Ziggit forum that explains it very well: ziggit.dev/t/vtable-interfaces-and-the-role-of-ptrcast-and-aligncast/2062/2
@@dudethebuilder Hmmm ... I still sort of don't get it :)
I guess the comment in the thread you posted to that makes most sense to me is the one calling that maybe the alignment check should be an assert, rather than a cast; this would do "some" (not complete, and probably less than one imagines) run-time checking that you haven't passed the wrong pointer in.
If one is always passing in a pointer that the implementation casts to, it seems to be the alignment should always be aligned with the downcast from anyopague to Stringer.
Async await video
I'm eagerly awaiting (pun intended!) to be able to make an episode about this. But as of now, Zig's async functionality isn't working, so we'll have to keep an eye out to see when this lands.
@@dudethebuilder
Oh 🆗
But it is possible to explain with the 0.10 version right
Yes, but I'm afraid that the new model to be implemented will be very different from the previous 0.10 async model. So the safest bet would be to wait. I'll do some research into the status of this development work to see if an explanation of the old model is viable.
"stud fumt"
seriously? you do know that's "standard" "format" right?
I think you'll find very few people in programming languages communities that would say "standard format" versus the abbreviated "stud fumt". I actually first heard these abreviated terms when working with Go some years ago.
@@dudethebuilder they also use these ugly abbreviations in C++. I hate them.
is self.toStringFn(self.ptr, buf); runtime dynamic dispatch?
unlike the first option where everything is available in comptime?
Yes, since we're dealing with pointers (dereferencing and casting them) it's happening at runtime. Pointers can be used at comptime but the functionality is very limited since they don't point to real addresses in memory until the program is actually running.