Totally agree with this blog post. C is awful to use, but not for the reasons many developers think. Zig team recognized the good and the bad of C and made a modern language that embraces C’s advantages and fixes its glaring issues. People think “low level” means “hard to write” or “arcane”, but it doesn’t have to be that way. “Low level” is about control, not boilerplate, verbosity, difficulty, or being error-prone.
@@LeviShawando Hard to find UB, strings are null-terminated instead of slices, no kind of generics, all pointers are nullable, no namespaces, etc. Basically, C is really starting to show its age.
@@mgord9518 UB is not that hard to find, use `-Wall -Wextra -pedantic`. strings in many languages have been null-terminated arrays. What difference would it make to make them as slices? Generics, use `void*` for function params, use `uint8_t*` + `size_t` for general data. Why do you need namespaces in C? C has 4 namespaces: global, local, tag, label.
@@yonderalt2662 no, it’s really not. The standard library is sparse AND bad, and yet using libraries is a pain every single time unless it’s a single header file library. CMake! Ugh… As for memory allocation, everyone uses malloc and free, so it’s nearly impossible to use any libraries and also take control of memory in your app. The most simple, mundane things are undefined behavior, like probably half the loops you write are accidentally UB. Signed vs. unsigned overflow, casts and implicit conversions, etc. Error handling is horrible, either forcing you to verbosely make a struct or tagged union manually that can represent error state or else use a sentinel value, or use an enum or int error code as the return and use output params, or some other annoying hack. Macros. #include and header files. I can go on and on. C is horrible to write for all these reasons that are fixable! And that’s exactly what Zig does for literally everything I mentioned in this comment
Zig can add a lot of stuff to the standard library without being bloat, because of the compilers lazy evaluation. I wish other languages did that. Every time c++ adds more things to the standard library it becomes slower to compile (and the c++ shared library size increases).
I've loved the Zig language so far, but I don't really like some of the standard library. It's really nice how easy it is to use the language as basically a C stand in without the std library (and it's almost recommended to use it this way at the moment with the constant breaking changes).
I totally concur with my experiences in Zig! I love Zig and I will definitely use it where I still use C, because Rust is definitely not a C replacement. It's more a C++ replacement. But I also found, like Andrew warns people, Zig is not yet stable and should not be used in production, things are moving a lot. But it will get there for sure, and then you have a lean, clean fast language that really does the low-level systems stuff better (and in smaller binaries) than Rust can. Rust is great for the higher level apps, what we currently use and/or used C++ for.
@@anonymousalexander6005 problem with Rust is the relatively large binaries even with no_std it’s still 15-20% larger than the equivalent C program. And compiled C is already not small. So for real embedded things Rust is not ideal yet. And Zig is very similar in size to C binaries. But for back end or desktop apps where I mainly use C++ I now tend to use Rust. As there I have cycles and memory aplenty.
It's nice that zig can compile C code. It works with lto and stuff like that so I have a project written in zig and it includes C code and the C code is around 200 000 lines. Most of that C code gets removed by zig as it's not used from the zig code. This works the other way around as well (using zig from C). So the final (static) binary size is just a few kb.
With gcc there are options to separate each function into it's own section, and tell the linker to remove unnecessary sections. Ld -static for a static binary size.
The testing allocator can actually catch leaks, so you can ensure your code isn't leaky. The GPA also has the option for checking it, but I prefer to rely on tests for it.
Maybe they could add a keyword like "temporary" to tell when a variable will be deleted when off-scope. Or the opposite, "persistent" for when a variable will stay until you explicitly delete it. But the latter would imply changing some fundamental things about the language while the former is just adding a new feature, so I think it's easier going with the former.
Thought about this too by just combining defer in the variable assignment like “const defer something = …” but this way and your “temporary” example relies on hidden control flow because it would call the deinit() method without explicitly stating it so it basically goes against the promises of the language.
Ive just had to write a personal statement for a scholarship, and I normally hate writing, but I think me watching all these article reading videos have improved my skills substencially. Thanks Prime!
D tried to be too many things and couldn’t decide if it wanted to be garbage collected or not, and for too long had two competing standard libraries. People couldn’t be bothered, and by the time they figured out what D was it was too little, too late
@@KManAbout this is the first release with a package manager, zig will also be moving away from LLVM and reimplementing async, also the stdlib is planned to be rethought/made more consistent. so imo, unless you're ready to comeback to the projects u write and/or are always going to be following releases and making the changes accordingly, zig just isn't very ideal right now.
I had that take too as a heavy vscode user. I tried using a basic nvim setup for rust but felt I was missing some comfort features and was too familiar with my vscode workflow. For zig a basic lsp, zls, and nvim really works well. It’s just different, zig is not a language that needs a lot of tooling in my opinion because it’s quite simple.
@FlanPoirot c doesn't have async either and you will have to rewrite some things I think that it is already good enough for doing a lot of the stuff people use c for today already.
Did some toying around with zig on the weekend and I really like it. Feel like the go of low level language. No overly complex syntax or crazy rust macros (tho it can KINDA do macros with comptime and inline). Only thing that tripped me up was the language server was super unhelpful. Wouldn't show me obvious compile time errors like not passing a tuple to debug.printf. Or simple sanity checking like telling me I'm storing or passing back a dangling pointer
I dont know where he hosts his data - 12.5GB is more like 0.05$ on a root server SSD while his blog states 12.5 GB = 2.5$ 25% markup did he wanted to make it sound more drastic?
The policy of being explicit isn't actually bad; there's a reason why people hate “and then it's magically taken care of”. It's confusing at times. The destruction wouldn't be so bad if the compiler wouldn't allow you to forget it. Ideally, the compiler sees the "defer" and it's good, or you want to do something special, then you need something else to tell the compiler that you've thought about the destruction and defer isn't what suits your needs (and then you do whatever you want). As a C++ programmer, I'm used to destructiors running implicitly, but if the language forced me to write them out explicitly, that would be okay, I guess (assuming they're non-trivial - don't bother me with the destruction of every int). Initialization is the same game. Making it hard to do memory acquisition without initialization is smart because usually, you want your stuff initialized.
I said this before on an older video, but using defer is a better approach than RAII, because implicit destruction requires you to implement massive amounts of complexity just to escape that destruction. You end up having to write copy constructors or move constructors to eliminate segfaults caused by dangling pointers after assignments or implement reference counting; which then requires you to implement weak pointers properly to solve cyclical references. You're constantly fumbling with a loaded footgun as you try to understand the lifetime of every object. Rust allows you to unload some of that burden onto the compiler, but you still have a steep learning curve, and the price you pay is tearing your hair out in frustration when you want to implement something like a linked list, tree, or graph, because the compiler can't prove that what you're doing is correct.
@@dynfoxx I already explained this in the comment. With defer, you opt **in** to object destruction. With RAII, you opt **out** of destruction. Opting out is a lot harder than opting in.
@@bitskit3476 I would agree that defer is opt in but RAII is opt in or out its your choice. Why is opting out harder? Now this depends on the langage to an extent but in the languages I work with it's fairly easy to ignore destruction if you want to. You can create defer from RAII you cannot create RAII from defer.
@@dynfoxx No. RAII does not allow opt in destruction. The very idea of RAII is that an object is constructed when it enters the lexical scope and destructed when it leaves the lexical scope. You can't just say "well, I can choose not to use RAII!" and pretend like that alleviates any of the complexity that's involved with using RAII. The fact of the matter is that RAII automatically destroys crap, so you have to explicitly go out of your way to make it *not* destroy crap. And the mental burden of doing that far outweighs the complexity of using a defer statement right after creating something by several orders of magnitude. If you forget to `defer object.destroy()` right after you create something, it's a single line of code to fix, and it's something that you're *never* going to forget to do anyway. If you need to hold on to an RAII object in some random library you're importing, you need to use unique_ptr or shared_ptr/weak_ptr and write copy/move constructors. But far more likely than that, you ARE *very* likely going to forget about this because the destruction is implicit. Your program is just going to segfault, and you're going to spend a half an hour pulling your hair out trying to figure out wth is going on before you finally figure it out. You'll then spend the next hour crafting a solution. It's a complete waste of time, and the tradeoff is a net negative.
@@bitskit3476 I’ve never seen a program segfault because of RAII. If en external library makes you program segfault, either this library is not well-written (and you probably shouldn’t be using it) or you’re using it incorrectly. But anyway, the point of RAII is that you write things once and then it’s done, no need to think about it, ever, and no need to tell the users of your library “make sure to use destroy() either”. It is as good as garbage collection, from a user perspective. Now, do not get me wrong, I love defer, and if you’re using something only once, then it’s easier than to write a RAII wrapper. But when your object is going to be used hundreds of times in your own code and god knows how many times in external code, then RAII is superior.
They could possibly add defer to the variable assignment. Instead of “const something = …” it could be “const defer something = …” [Edit] Nevermind that would break their no hidden control flow promise since it would be calling the deinit() method behind the scenes.
The defer keyword also has nothing to do with de-initialization, it's just how it's typically used. Giving it new meaning on variable assignment could be confusing
Languages that use "begin/end" rather than "{ }" seem to not catch on. Crystal is decent but I bet if it had curly brackets, people would actually use it (yes, that's pretty sad)
I like “begin/end” syntax. The biggest thing that keeps me from those languages, though, is that bracket languages have massive ecosystems that make them super convenient. Crystal intrigues me, but I just don’t know where to find good tooling and libraries to use.
@@JayDee-b5u there’s an aesthetic to them that I like. I’ve always been a fan of Wirth-style languages (my first experiences with programming was largely with languages from the 70s and 80s that tended to be BASIC or Wirth-like derivatives)
I think this is mostly true with two exceptions I can think of though one is mostly dead now. The mostly dead one is visual basic, but it had a pretty long life and likely still sees some use on VBA. The other is SQL which is clearly not going anywhere but you could argue that's basically the days version of JS
So cant imagine a better place to ask this. I want to convert my C++ game engine into rust or zig. Open to suggestions. Like for rust, comment for zig.
Another thing I don't understand is why they dislike interfaces and polymorphism so much. A simple trait-like system wouldn't hurt anyone, and would bring so much to the table it's crazy. For example the standard library could offer the "Allocatable" interface / trait / whatever, which has its deinit cb that then could be called automatically as needed.
They have an allocator struct in the std library. It uses function pointers for polymorphism. I think it aligns very well with the goal of the language to be explicit. In C++ you would have an implicit vtable
@@Sergeeeek I know but I'm not talking about an "allocator" interface; instead, I'd appreciate an "allocatable" interface (or something else) which has its deinit prop to be called. But that's just an example. A trait/interface/abstract/etc. polymorphism feature is quite needed nowadays. And that's pretty simple, so I can't see why it would break zig simplicity.
@@venir_dev it would break zig's promise of no hidden control flow if you want deinit to be called automatically. Zig has implicit "interfaces" similar to Go, where you can accept an arbitrary type and call methods on it or do whatever you want. Compiler will check that the types you actually pass have the required methods so it's not like dynamic typing.
@@Sergeeeek Thank you for this explanation. This is the thing I'm not sure I've understood yet. It sounds like "any" in typescript, but without the dynamic typing? How can I be sure that what I pass to the - say - function actually has the required method at compile time? Also when I try this on VS Code I get no analysis warning nor errors, but I guess that's another topic.
@@venir_dev yeah, it's like any, but the compiler knows which types you pass because it analyzes all call sites. I think it's a language feature that makes editor tooling really hard, I would also like if they added some explicit interfaces. I know that there are projects that attempt to add interfaces and more strict interface type checking using comptime.
Businesses use programming languages and there aren’t so quick to adapt. Embedded is even more archaic in terms of the ecosystem. I don’t see Zig winning long term there.
I really want to pick up learning Zig but the issue is the word "Zig" in my local language it literally means "Defecate" making it almost impossible to mention it in a professionally while maintaining a straight face. "Ah yes the IT staff defecate code" 😅
for now there's no point, in the future zig is a more secure and nicer language that's essentially a drop in replacement for C you get expressions (statements are kinda boilerplatey), optionals, error unions, tagged unions, namespaces, etc along with the safety stuff like debug mode being able to detect memory leaks, bounds checking being a thing, error handling being explicit, slices, etc etc it really is a decent C replacement, but rn it's just not ready
I have no reason to use Zig instead of C++ (lack of destructors is a deal breaker, sorry). But there's lots of reasons to use Zig over C (once it matures).
@@FlanPoirot a lot of what you said can be implemented in C (such as tagged unions, slices, and a namespace-like system) just with less clean syntax. But there is no way I would switch to a language which in my opinion has worse syntax and more complicated features just for cleaner slices and namespaces.And if I want an arena allocator, I would just implement it myself in C, or use someone else’s. tl;dr: Zig’s relative complexity and syntax style outweigh its convenience features for me.
It would be nice to one day get a video that Explained Like we're 5 what the differences are between these (relatively) obscure or emerging languages, tools and runtimes etc. I don't do much Web stuff, I made a "something" in AngularJS when that was new and fancy, around the time MongoDB and NodeJS spawned, but I can't keep up with all the colorful SVGs of animals and morphed letters, which half the time look like the marketing departement for the latest Heartbleed or Rowhammer. (Off-topic comment-bloat: lost the code in my great harddrive crash of 2017, 1x 8tb drive just came up blank one day and windows immediately helped me get the drive into a much worse state, by over writing the MBR MFT etc. which has distracted me on and off many projects as I go back to this thing code where I try to recover what I want, without paying out the butt to give someone else all my data, and without losing all the names of all the folder and files)
Starting to think zig might take over but, it isn't simple like everyone seems to repeat. The build system is done with a build "script" written in zig. So, if you don't know zig, how do you write a custom build.zig? Documentation isnt bad, but I guess I just don't know enough of the idioms to be productive.
Nothing you can do about storage? Seriously when will web engineering stop doing stupid stuff. Go learn from the game industry how to properly space encode stuff. It's such a massive gain to do space optimization right. Transforming data for the context such a novel idea....
> Go learn from the game industry to properly space encode stuff Is this a joke? Most modern games don't even bother optimizing for nearly identical textures and can be hundreds of GB for
wrote C for at least a decade. I don't necessarily agree with the way Zig goes about things. 1. I would've 100% preferred Golang's syntax over Rust's syntax. 2. `errdefer` is weird. I like `defer` but having an erroring version of `defer` is bad design imo. 3. C is about to get its own `comptime` in the future with `constexpr` adoption from C++, it doesn't apply to functions yet but that advantage for Zig isn't a strong one when most C compilers are also C++ compilers so that advantage can easily be matched. 4. There's no such thing as "C macros". The preprocessor is not part of the C language itself. Also, you shouldn't be using the C preprocessor much except for doing conditional compilations or file inclusions.
@@kippers12isOG preprocessor actually isn't part of C. The C language itself has no "awareness" of the preprocessor. Read about it here: en.cppreference.com/w/c/language/translation_phases also: en.wikipedia.org/wiki/C_preprocessor
1: Zig's syntax looks nothing like Rust 2: Why? 3: Comptime expands beyond "constexpr". Comptime in Zig means that generics, conditional compilation, automated type creation, etc. All share the same basic syntax. This makes it much easier to learn and use 4: Whether or not it's defined as part of the language doesn't matter when it's completely necessary to compile any non-trivial C program
@@LeviShawando Have you never used Zig or Rust? The only difference between Zig's function syntax and Go's is the keyword... That style is essentially standard for modern, C-inspired languages. Has nothing to do with being similar or dissimilar to Rust, which also includes an arrow. `condition: bool` isn't even a valid Zig declaration, it's simply supplying the type. To make a variable you'd have to Do `var condition: bool = false`. (Or undefined if you're going to overwrite it before reading) Zig's try and catch is essentially unique to Zig, I've never seen that kind of error handling in any other language.
there's no "import syntax", it's just a compiler built in function there's no true module system syntax in zig afaik, it's just that the compiler is smart enough to be able to compile it all every single file in zig is a namespace (aka a struct) and u "importing" a file is just making a constant refer to a particular namespace zig's syntax feels odd but for me at least when I look at why they chose what they did, it usually makes sense it's usually bc it makes it explicit, less complicated or something along those lines once u write a lil bit of zig you just don't really think about it much
@@FlanPoiroti like the module import syntax of js or the python import syntax like import {std} from "std" or import std or from std import std as standard it feels better i want to use zig to build a game engine but im waiting for a stable version
@@ulrich-tonmoy In Zig, all files (and namespaces) are structs. When you say `const std = @import("std");` it is literally defining a struct that contains all of `std`'s public declarations. Most of Zig looks strange at first glance, but is quite nice when you use it for a bit and understand what's going on.
You're too much into the text, you should go to the right of the frame and the text to the left of the frame, that margin is wasted space; your chat also shouldn't be on the text. Get your mic 🎙️ on your left. You're welcome
@@FlanPoirot Zig is cool. But if I see another LLVM programming language that I have to learn, I am going to strangle somebody!!! I feel like another hype train comes out every 6 months. It also seems that people in this industry don't like long term solutions. You can't pick just one LLVM language because somebody in the org keeps messing up the trust. Rust put a bad taste in my mouth. I made my own LLVM language. I feel like everybody else is doing the same and then I fear that they'll go on a power trip and start adding CoC or whatever crippling license. Again Zig is ok. Everybody keeps telling me to go to Zig instead of Rust. I purged rust from all my business software.
"Learning a language" does not mean the syntax; that's easy. Its the tooling and edge case screw ups. I have to learn what I cannot do with zig. Can I compile this on arduino or TI or the chipset on a hearing aid? I am reading about zig and learning what it can do with embedded systems and binaries. Does zig have a quantum computer library? You know, off the wall stuff like that. Do I have to join a Zig Embedded group to figure out the designs of what I need to do. Bascially, I have to study the ASM code that the compiler produces. I am finding out some cool things. But its research time that I don't have or want to f up like I did with Rust. I think most guys on this thread only do the web type stuff and not the mission critical stuff that I'm d1ckkn6 around with.
@@complexity5545 Zig will no longer be LLVM based. they made a proposal that has been accepted a week or so ago where they state that they're "divorcing LLVM" and will be creating their own backends.
Tried zig a few weeks ago. Their example build script did not work with the binary provided on Fedora repos. I've dismissed the language entirely, ever since.
They're changing stuff fast. In the latest release they made breaking changes to the build system to support their new package manager. It's still an unstable language, if you want to be an early adopter you need to keep up with release notes.
Nice to see prime checking in on zig. They just had 0.11 release with a lot of work done. Can't wait for 1.0
i just posted a video about 0.11 yesterday!
@@ThePrimeTimeagen yes you did
@@IStMlt😂r3rt6y8
@@IStMl😢35333333
33rte2y😅
Totally agree with this blog post.
C is awful to use, but not for the reasons many developers think. Zig team recognized the good and the bad of C and made a modern language that embraces C’s advantages and fixes its glaring issues.
People think “low level” means “hard to write” or “arcane”, but it doesn’t have to be that way. “Low level” is about control, not boilerplate, verbosity, difficulty, or being error-prone.
why is C awful to use? I've been writing C for a decade but I write it in my own way, not the way alot of people learn it during school/college.
@@LeviShawando Hard to find UB, strings are null-terminated instead of slices, no kind of generics, all pointers are nullable, no namespaces, etc.
Basically, C is really starting to show its age.
@@mgord9518 UB is not that hard to find, use `-Wall -Wextra -pedantic`.
strings in many languages have been null-terminated arrays. What difference would it make to make them as slices?
Generics, use `void*` for function params, use `uint8_t*` + `size_t` for general data.
Why do you need namespaces in C? C has 4 namespaces: global, local, tag, label.
C is easy to write when you write functional-styled code with no shared state.
@@yonderalt2662 no, it’s really not.
The standard library is sparse AND bad, and yet using libraries is a pain every single time unless it’s a single header file library.
CMake! Ugh…
As for memory allocation, everyone uses malloc and free, so it’s nearly impossible to use any libraries and also take control of memory in your app.
The most simple, mundane things are undefined behavior, like probably half the loops you write are accidentally UB. Signed vs. unsigned overflow, casts and implicit conversions, etc.
Error handling is horrible, either forcing you to verbosely make a struct or tagged union manually that can represent error state or else use a sentinel value, or use an enum or int error code as the return and use output params, or some other annoying hack.
Macros.
#include and header files.
I can go on and on. C is horrible to write for all these reasons that are fixable! And that’s exactly what Zig does for literally everything I mentioned in this comment
Zig can add a lot of stuff to the standard library without being bloat, because of the compilers lazy evaluation. I wish other languages did that. Every time c++ adds more things to the standard library it becomes slower to compile (and the c++ shared library size increases).
The last part will hopefully be resolved with import std, which means hopefully by 2033 we'll be able to use it.
I see you on every zig video bro xD
I've loved the Zig language so far, but I don't really like some of the standard library. It's really nice how easy it is to use the language as basically a C stand in without the std library (and it's almost recommended to use it this way at the moment with the constant breaking changes).
Precompiled headers help a bit but I’m also hoping for import std
@@permutationlockThe docs says that the std library still very experimental, so now wonders that it still bad.
Zig needs a good linter. With lints, it's almost trivial to spot the "woops I forgot to deinit stuff"
I totally concur with my experiences in Zig! I love Zig and I will definitely use it where I still use C, because Rust is definitely not a C replacement. It's more a C++ replacement. But I also found, like Andrew warns people, Zig is not yet stable and should not be used in production, things are moving a lot. But it will get there for sure, and then you have a lean, clean fast language that really does the low-level systems stuff better (and in smaller binaries) than Rust can. Rust is great for the higher level apps, what we currently use and/or used C++ for.
@@anonymousalexander6005 problem with Rust is the relatively large binaries even with no_std it’s still 15-20% larger than the equivalent C program. And compiled C is already not small.
So for real embedded things Rust is not ideal yet. And Zig is very similar in size to C binaries. But for back end or desktop apps where I mainly use C++ I now tend to use Rust. As there I have cycles and memory aplenty.
It's nice that zig can compile C code. It works with lto and stuff like that so I have a project written in zig and it includes C code and the C code is around 200 000 lines. Most of that C code gets removed by zig as it's not used from the zig code. This works the other way around as well (using zig from C). So the final (static) binary size is just a few kb.
With gcc there are options to separate each function into it's own section, and tell the linker to remove unnecessary sections. Ld -static for a static binary size.
The testing allocator can actually catch leaks, so you can ensure your code isn't leaky. The GPA also has the option for checking it, but I prefer to rely on tests for it.
The only reason I don't code in zig, is because I don't want to be called a zigger😢.
Only ziggas can say that word
Sad reality of the Russian invasion.
💀
Maybe they could add a keyword like "temporary" to tell when a variable will be deleted when off-scope. Or the opposite, "persistent" for when a variable will stay until you explicitly delete it. But the latter would imply changing some fundamental things about the language while the former is just adding a new feature, so I think it's easier going with the former.
Thought about this too by just combining defer in the variable assignment like “const defer something = …” but this way and your “temporary” example relies on hidden control flow because it would call the deinit() method without explicitly stating it so it basically goes against the promises of the language.
That just sounds like stack vs heap to me
Yes!!! Finally I managed to catch a glimpse of why Tom’s a genius!!!! He truly is!!!
I've been pretty interested in zig. This was very helpful article.
Who says the enthusiasts die? What these guys do is awesome!!!
When you watch a video, there is lore, you understand the lore, you are a genius like tom
Ive just had to write a personal statement for a scholarship, and I normally hate writing, but I think me watching all these article reading videos have improved my skills substencially. Thanks Prime!
It's like in D with dstep, importC or betterC. Except that dlang has been around for too long to be new and shine.
D tried to be too many things and couldn’t decide if it wanted to be garbage collected or not, and for too long had two competing standard libraries. People couldn’t be bothered, and by the time they figured out what D was it was too little, too late
@@biggiefrosty too late, but not too little. D is still a great, expressive language. I think it's better than Rust.
Zig looks promising but I’ll try in a year or so when tooling will be better
i think this is a good take
I'd argue the tooling is good enough rn to use over c in a lot of cases
@@KManAbout this is the first release with a package manager, zig will also be moving away from LLVM and reimplementing async, also the stdlib is planned to be rethought/made more consistent. so imo, unless you're ready to comeback to the projects u write and/or are always going to be following releases and making the changes accordingly, zig just isn't very ideal right now.
I had that take too as a heavy vscode user. I tried using a basic nvim setup for rust but felt I was missing some comfort features and was too familiar with my vscode workflow. For zig a basic lsp, zls, and nvim really works well. It’s just different, zig is not a language that needs a lot of tooling in my opinion because it’s quite simple.
@FlanPoirot c doesn't have async either and you will have to rewrite some things I think that it is already good enough for doing a lot of the stuff people use c for today already.
4:03 they know sharding isn’t new right?
I really liket the thumbnail art, whoever did it deserves a raise
Did some toying around with zig on the weekend and I really like it. Feel like the go of low level language. No overly complex syntax or crazy rust macros (tho it can KINDA do macros with comptime and inline). Only thing that tripped me up was the language server was super unhelpful. Wouldn't show me obvious compile time errors like not passing a tuple to debug.printf. Or simple sanity checking like telling me I'm storing or passing back a dangling pointer
I dont know where he hosts his data -
12.5GB is more like 0.05$ on a root server SSD
while his blog states 12.5 GB = 2.5$
25% markup
did he wanted to make it sound more drastic?
I still wait on Zig until 1.0 is reached. Meanwhile learning Go.
0.12 is supposed to make Zig way more stable than it was when the comment was written. Coming out soon
The policy of being explicit isn't actually bad; there's a reason why people hate “and then it's magically taken care of”. It's confusing at times. The destruction wouldn't be so bad if the compiler wouldn't allow you to forget it.
Ideally, the compiler sees the "defer" and it's good, or you want to do something special, then you need something else to tell the compiler that you've thought about the destruction and defer isn't what suits your needs (and then you do whatever you want).
As a C++ programmer, I'm used to destructiors running implicitly, but if the language forced me to write them out explicitly, that would be okay, I guess (assuming they're non-trivial - don't bother me with the destruction of every int).
Initialization is the same game. Making it hard to do memory acquisition without initialization is smart because usually, you want your stuff initialized.
I said this before on an older video, but using defer is a better approach than RAII, because implicit destruction requires you to implement massive amounts of complexity just to escape that destruction. You end up having to write copy constructors or move constructors to eliminate segfaults caused by dangling pointers after assignments or implement reference counting; which then requires you to implement weak pointers properly to solve cyclical references. You're constantly fumbling with a loaded footgun as you try to understand the lifetime of every object. Rust allows you to unload some of that burden onto the compiler, but you still have a steep learning curve, and the price you pay is tearing your hair out in frustration when you want to implement something like a linked list, tree, or graph, because the compiler can't prove that what you're doing is correct.
How does defer remove any of that complexity?
While I like both I would prefer RAII since I can create defer using it.
@@dynfoxx I already explained this in the comment. With defer, you opt **in** to object destruction. With RAII, you opt **out** of destruction. Opting out is a lot harder than opting in.
@@bitskit3476 I would agree that defer is opt in but RAII is opt in or out its your choice.
Why is opting out harder?
Now this depends on the langage to an extent but in the languages I work with it's fairly easy to ignore destruction if you want to.
You can create defer from RAII you cannot create RAII from defer.
@@dynfoxx No. RAII does not allow opt in destruction. The very idea of RAII is that an object is constructed when it enters the lexical scope and destructed when it leaves the lexical scope.
You can't just say "well, I can choose not to use RAII!" and pretend like that alleviates any of the complexity that's involved with using RAII.
The fact of the matter is that RAII automatically destroys crap, so you have to explicitly go out of your way to make it *not* destroy crap. And the mental burden of doing that far outweighs the complexity of using a defer statement right after creating something by several orders of magnitude.
If you forget to `defer object.destroy()` right after you create something, it's a single line of code to fix, and it's something that you're *never* going to forget to do anyway.
If you need to hold on to an RAII object in some random library you're importing, you need to use unique_ptr or shared_ptr/weak_ptr and write copy/move constructors. But far more likely than that, you ARE *very* likely going to forget about this because the destruction is implicit. Your program is just going to segfault, and you're going to spend a half an hour pulling your hair out trying to figure out wth is going on before you finally figure it out. You'll then spend the next hour crafting a solution. It's a complete waste of time, and the tradeoff is a net negative.
@@bitskit3476 I’ve never seen a program segfault because of RAII. If en external library makes you program segfault, either this library is not well-written (and you probably shouldn’t be using it) or you’re using it incorrectly.
But anyway, the point of RAII is that you write things once and then it’s done, no need to think about it, ever, and no need to tell the users of your library “make sure to use destroy() either”. It is as good as garbage collection, from a user perspective.
Now, do not get me wrong, I love defer, and if you’re using something only once, then it’s easier than to write a RAII wrapper. But when your object is going to be used hundreds of times in your own code and god knows how many times in external code, then RAII is superior.
I still don't quite understand comptime, is it like interpreting code and then inserting the result?
yes that's the short version.
@@ea_naseer I see thanks for the confirmation
Four axes of programming languages? Is there more details on that? 10:03
C23 adds auto for type inference, like in C++
There should be more talk about C23 really. So many people think of C as something of the past.
i know C and i am learning zig, still trying to understand it better but i'm getting there
I swear, the more I look at him, the more he looks like the DrDisrespect of programming
I really dislike C, but I could see myself actually using Zig.
i wonder when will zig be production ready
They could possibly add defer to the variable assignment. Instead of “const something = …” it could be “const defer something = …”
[Edit] Nevermind that would break their no hidden control flow promise since it would be calling the deinit() method behind the scenes.
The defer keyword also has nothing to do with de-initialization, it's just how it's typically used. Giving it new meaning on variable assignment could be confusing
zig is kotlin for C
Edge this nuts!
just going to mention comp time is jon blows idea.
Yes you Zig.
Tranlate-c Linux kernel.c to kernel.zig, schwinggg.
Try it
FINE!!!!! I’ll learn zig
zig does `cImporting` you!
TheZigagen
Tom is really just Billy who changed his name and moved on from PHP.
The name is Thecimportigen
Smh where's the standard support for JDSL???
The electrical engineer in me refuses to use anything except c
Have you considered trying out electrical engineering?
I am a electrical engineer and i use c/c++/python/vba too. Must be nice to have your job lol😂
Honestly as a C fanatic and a rust skeptic zig is looking mighty good right now...
As a zigga I agree for now, until zig 1.0
Based. C is the goat
the video currently has 420 likes
Languages that use "begin/end" rather than "{ }" seem to not catch on. Crystal is decent but I bet if it had curly brackets, people would actually use it (yes, that's pretty sad)
I like “begin/end” syntax. The biggest thing that keeps me from those languages, though, is that bracket languages have massive ecosystems that make them super convenient.
Crystal intrigues me, but I just don’t know where to find good tooling and libraries to use.
Is it? Why not just use the brackets? Who wants to type 'end' and 'begin' 1000x?
@@JayDee-b5u there’s an aesthetic to them that I like. I’ve always been a fan of Wirth-style languages (my first experiences with programming was largely with languages from the 70s and 80s that tended to be BASIC or Wirth-like derivatives)
I think this is mostly true with two exceptions I can think of though one is mostly dead now. The mostly dead one is visual basic, but it had a pretty long life and likely still sees some use on VBA. The other is SQL which is clearly not going anywhere but you could argue that's basically the days version of JS
@@JayDee-b5uas if you’re typing nowadays and not autocompleting copilot
At the end of the day, if you're relying on chunked encoding, you're doing it wrong. Just my opinion, but you'll find my name in the relevant RFC.
Yeah but how does it handle the constantly growing data privacy and sovereignty concerns?
So cant imagine a better place to ask this.
I want to convert my C++ game engine into rust or zig. Open to suggestions. Like for rust, comment for zig.
Another thing I don't understand is why they dislike interfaces and polymorphism so much. A simple trait-like system wouldn't hurt anyone, and would bring so much to the table it's crazy. For example the standard library could offer the "Allocatable" interface / trait / whatever, which has its deinit cb that then could be called automatically as needed.
They have an allocator struct in the std library. It uses function pointers for polymorphism. I think it aligns very well with the goal of the language to be explicit. In C++ you would have an implicit vtable
@@Sergeeeek I know but I'm not talking about an "allocator" interface; instead, I'd appreciate an "allocatable" interface (or something else) which has its deinit prop to be called. But that's just an example. A trait/interface/abstract/etc. polymorphism feature is quite needed nowadays. And that's pretty simple, so I can't see why it would break zig simplicity.
@@venir_dev it would break zig's promise of no hidden control flow if you want deinit to be called automatically.
Zig has implicit "interfaces" similar to Go, where you can accept an arbitrary type and call methods on it or do whatever you want. Compiler will check that the types you actually pass have the required methods so it's not like dynamic typing.
@@Sergeeeek Thank you for this explanation. This is the thing I'm not sure I've understood yet. It sounds like "any" in typescript, but without the dynamic typing? How can I be sure that what I pass to the - say - function actually has the required method at compile time? Also when I try this on VS Code I get no analysis warning nor errors, but I guess that's another topic.
@@venir_dev yeah, it's like any, but the compiler knows which types you pass because it analyzes all call sites. I think it's a language feature that makes editor tooling really hard, I would also like if they added some explicit interfaces.
I know that there are projects that attempt to add interfaces and more strict interface type checking using comptime.
rust is rquivalent to deno and zig is bun
Businesses use programming languages and there aren’t so quick to adapt. Embedded is even more archaic in terms of the ecosystem. I don’t see Zig winning long term there.
Just because it doesn't get adopted immediately doesn't make it a failure.
I really want to pick up learning Zig but the issue is the word "Zig" in my local language it literally means "Defecate" making it almost impossible to mention it in a professionally while maintaining a straight face.
"Ah yes the IT staff defecate code" 😅
What's your local language?
I have no reason to use Zig over C.
optionals are always awesome
errors as values are always awesome
for now there's no point, in the future zig is a more secure and nicer language that's essentially a drop in replacement for C
you get expressions (statements are kinda boilerplatey), optionals, error unions, tagged unions, namespaces, etc
along with the safety stuff like debug mode being able to detect memory leaks, bounds checking being a thing, error handling being explicit, slices, etc etc
it really is a decent C replacement, but rn it's just not ready
I have no reason to use Zig instead of C++ (lack of destructors is a deal breaker, sorry). But there's lots of reasons to use Zig over C (once it matures).
@@isodoubIet unless C gets that new update with `constexpr` and other things that Zig doesn't have.
@@FlanPoirot a lot of what you said can be implemented in C (such as tagged unions, slices, and a namespace-like system) just with less clean syntax. But there is no way I would switch to a language which in my opinion has worse syntax and more complicated features just for cleaner slices and namespaces.And if I want an arena allocator, I would just implement it myself in C, or use someone else’s.
tl;dr: Zig’s relative complexity and syntax style outweigh its convenience features for me.
It would be nice to one day get a video that Explained Like we're 5 what the differences are between these (relatively) obscure or emerging languages, tools and runtimes etc. I don't do much Web stuff, I made a "something" in AngularJS when that was new and fancy, around the time MongoDB and NodeJS spawned, but I can't keep up with all the colorful SVGs of animals and morphed letters, which half the time look like the marketing departement for the latest Heartbleed or Rowhammer.
(Off-topic comment-bloat: lost the code in my great harddrive crash of 2017, 1x 8tb drive just came up blank one day and windows immediately helped me get the drive into a much worse state, by over writing the MBR MFT etc. which has distracted me on and off many projects as I go back to this thing code where I try to recover what I want, without paying out the butt to give someone else all my data, and without losing all the names of all the folder and files)
Starting to think zig might take over but, it isn't simple like everyone seems to repeat. The build system is done with a build "script" written in zig. So, if you don't know zig, how do you write a custom build.zig? Documentation isnt bad, but I guess I just don't know enough of the idioms to be productive.
Gcc -E
bingo
Kotlin is doing pretty cool things.
Translating C is such a killer feat. Boo rusty.
Rust also has a C to Unsafe Rust translation just FYI
Embedded Rust is an abomination, already. Zig will be a new inclusion on the list.
Nothing you can do about storage? Seriously when will web engineering stop doing stupid stuff. Go learn from the game industry how to properly space encode stuff. It's such a massive gain to do space optimization right. Transforming data for the context such a novel idea....
> Go learn from the game industry to properly space encode stuff
Is this a joke? Most modern games don't even bother optimizing for nearly identical textures and can be hundreds of GB for
wrote C for at least a decade. I don't necessarily agree with the way Zig goes about things.
1. I would've 100% preferred Golang's syntax over Rust's syntax.
2. `errdefer` is weird. I like `defer` but having an erroring version of `defer` is bad design imo.
3. C is about to get its own `comptime` in the future with `constexpr` adoption from C++, it doesn't apply to functions yet but that advantage for Zig isn't a strong one when most C compilers are also C++ compilers so that advantage can easily be matched.
4. There's no such thing as "C macros". The preprocessor is not part of the C language itself. Also, you shouldn't be using the C preprocessor much except for doing conditional compilations or file inclusions.
Point 4 said like a true stack overflow mod. Well done
@@kippers12isOG preprocessor actually isn't part of C. The C language itself has no "awareness" of the preprocessor. Read about it here: en.cppreference.com/w/c/language/translation_phases
also: en.wikipedia.org/wiki/C_preprocessor
1: Zig's syntax looks nothing like Rust
2: Why?
3: Comptime expands beyond "constexpr". Comptime in Zig means that generics, conditional compilation, automated type creation, etc. All share the same basic syntax. This makes it much easier to learn and use
4: Whether or not it's defined as part of the language doesn't matter when it's completely necessary to compile any non-trivial C program
@@mgord9518 Zig's syntax looks nothing like Rust? Wow you're blind...
`fn function_name(params) return_type`
@@LeviShawando Have you never used Zig or Rust?
The only difference between Zig's function syntax and Go's is the keyword... That style is essentially standard for modern, C-inspired languages. Has nothing to do with being similar or dissimilar to Rust, which also includes an arrow.
`condition: bool` isn't even a valid Zig declaration, it's simply supplying the type. To make a variable you'd have to Do `var condition: bool = false`. (Or undefined if you're going to overwrite it before reading)
Zig's try and catch is essentially unique to Zig, I've never seen that kind of error handling in any other language.
i hate the Zig import syntax it feels like the old js import syntax
there's no "import syntax", it's just a compiler built in function
there's no true module system syntax in zig afaik, it's just that the compiler is smart enough to be able to compile it all
every single file in zig is a namespace (aka a struct) and u "importing" a file is just making a constant refer to a particular namespace
zig's syntax feels odd but for me at least when I look at why they chose what they did, it usually makes sense
it's usually bc it makes it explicit, less complicated or something along those lines
once u write a lil bit of zig you just don't really think about it much
@@FlanPoiroti like the module import syntax of js or the python import syntax
like import {std} from "std"
or import std
or from std import std as standard
it feels better
i want to use zig to build a game engine but im waiting for a stable version
@@ulrich-tonmoy In Zig, all files (and namespaces) are structs. When you say `const std = @import("std");` it is literally defining a struct that contains all of `std`'s public declarations. Most of Zig looks strange at first glance, but is quite nice when you use it for a bit and understand what's going on.
You're too much into the text, you should go to the right of the frame and the text to the left of the frame, that margin is wasted space; your chat also shouldn't be on the text. Get your mic 🎙️ on your left. You're welcome
All these got-dang-it programming languages are becoming like the stock market. Pump and dumps.
Zig is 8 years old. how's it "pump and dumb"?
@@FlanPoirot Zig is cool.
But if I see another LLVM programming language that I have to learn, I am going to strangle somebody!!! I feel like another hype train comes out every 6 months. It also seems that people in this industry don't like long term solutions. You can't pick just one LLVM language because somebody in the org keeps messing up the trust. Rust put a bad taste in my mouth. I made my own LLVM language. I feel like everybody else is doing the same and then I fear that they'll go on a power trip and start adding CoC or whatever crippling license.
Again Zig is ok. Everybody keeps telling me to go to Zig instead of Rust. I purged rust from all my business software.
"Learning a language" does not mean the syntax; that's easy. Its the tooling and edge case screw ups. I have to learn what I cannot do with zig. Can I compile this on arduino or TI or the chipset on a hearing aid? I am reading about zig and learning what it can do with embedded systems and binaries. Does zig have a quantum computer library? You know, off the wall stuff like that. Do I have to join a Zig Embedded group to figure out the designs of what I need to do. Bascially, I have to study the ASM code that the compiler produces. I am finding out some cool things. But its research time that I don't have or want to f up like I did with Rust.
I think most guys on this thread only do the web type stuff and not the mission critical stuff that I'm d1ckkn6 around with.
@@complexity5545 Zig will no longer be LLVM based. they made a proposal that has been accepted a week or so ago where they state that they're "divorcing LLVM" and will be creating their own backends.
Ok but Go > Zig
copium
I love go but they suit different use cases.
Write a kernel in go, or an interpreter. Manual memory is a must in some domains.
GC as a default is insanity for almost any kind of program
C > Zig
First!
ну ок, тогда я второй... в очереди к твоей маме
Tried zig a few weeks ago. Their example build script did not work with the binary provided on Fedora repos. I've dismissed the language entirely, ever since.
They're changing stuff fast. In the latest release they made breaking changes to the build system to support their new package manager.
It's still an unstable language, if you want to be an early adopter you need to keep up with release notes.
@@Sergeeeek yeah, that would obviously unfortunately be a enormous waste of my time.