My Zig Experience | Prime Reacts 

Learning new technology at home to maintain the passion and having to use the same old shit at work is the most relatable thing ever.

"If you are not always rusting, it's hard to remain fresh in the rust world" - Spot on observation, always makes me feel like I dunno what I am doing whenever I open a complex Rust project I've done in the past or come back to Rust after a few weeks doing something else.

I worked with a tech lead once that wanted everything to be camelcase so badly that even when we adopted a codegen tool that produced a largely snake case'd GraphQL API, he aliased every single field to be camel cased... and nobody questioned it, and hundreds of hours were spent aliasing things as a result. Moral of the story is that it's okay to have opinions about things that don't really mater, but the moment you have to put effort into that opinion, you have to drop it.

I Zigged so much to the point that I left my compiler in the rain and got Rust

Loved this vid, zig definitely got my attention after this. Also, I thought I was the only one, but like you Prime, I love to see examples on documentation, it's how I understand most of things, by example.

Afaik the first language to introduce the concept of a "borrow checker" was Cyclone developed at AT&T Labs (So not whoever this Tom guy is).

Last month i did two videos on this channel learning and teaching Zig. And I’m in love with it. Let me put it this way, I’m so in love with it that when I need to do something in C now, I’ll do it in Zig.

The casing on the compiler builtins is based on whether the output is a type. @This, @Type, @TypeOf, @Vector all "return" types. The other builtins don't. This makes it so you can tell at a glance what you can actually do with the builtin's output and when even without looking at the language reference.

Love this zig arc. Keep it going!

23:45 pretty sure I saw something added to the 0.13 milestone that would make functions assignable to consts like that, so anonymous functions would be a thing for closure like fun. I really wish we get to see that level of consistency.

8:37 weird thing is that JavaScript also had this idea (with the commonjs require()) which was born out of language limitation of not having import syntax and it turned out that it worked really well. And then Ecma standard committee decided to add "import" statement creating endless package compatibility issues.

I love that having keys on your keyboard with unknown functions is a flex in the programming community.

16:03 Looks like chat told you but just to be clear: undefined means (in default build mode) store a trap value that crashes the program if you attempt to load it or (in fast build modes) leave memory uninitialized. You can however do this: > var buffer = std.mem.zeroes([1024]u8);

the ? operator on rust is also called a try. it used to be a macro (try!) and then changed to what it is now. but if u go and look at what trait implements it, it's still called a try underneath

Dude I need to finish my current Job & Personal projects to go back to playing with c / c++ . This video made me excited to add zig to that...

I like how things start with capital letter if they return a type, and small if not in zig

3:22 EXACTLY thats how I feel too. Like I get to the crate page and all of the stuff it says doesn't help me at all

11:20 - 12:30 Could you elaborate more on this in a future stream/video? The "a catch b" pattern still allows you set a default value if you encounter an error, or am I missing something about the problem?

27:47 I wouldn't choose isize, since the number you're using shouldn't really be dependendant on the target you're compiling to, and your program would behave different given different compile targets, with isize::MAX being different compared to i32::MAX always being the same.

One of the best features of Zig is solving the problem with function coloring.

10:23 I feel like what rust lacks here are structural enums. Like "(i32, i32)" is an structural version to the tuple struct "struct Point(i32, i32);" Rust needs something like "i32 | String" for "enum Foo{ V0(i32), V1(String) }"

The for loop looks like it was designed so an IDE can autocomplete the collection variable, know the type and suggest an element variable name asap.

Is zig + go set omnipotent like rust, but faster to write?

Zig looks awesome - it looks like a healthy mix of C and Rust. I like the fact that the type system is so plain and simple like C, and yet nullability and errors are built in to the language as type qualifiers (I've never seen this before). I normally like a language with a powerful type system, but usually people abuse the type system in library code and you end up digging through 5 layers of abstraction to figure out how to get the 32-bit RGBA pixels of a PNG (had to do this with some bitch ass rust library written by a dude high on his own farts). I think these days I'm more attracted to a language with a simple type system and just enough features to get the job done.

The OS provides zero'd memory so you can't peak at what other programs wrote to memory. You need to have allocated and written to the memory before in-order to get non-zero'd memory. PS, in debugging it's a good idea to write some random value to memory you're not going to clear in production in-order to catch problems with zero assumptions. Of course, you also want to test with the production release code. so more testing.

Maybe I'm just too used to it, but I have no issues reading or writing code with a combination of snake and camel case. In fact, I'll need to remind myself not to do that when working on other people's code 😅 (I mostly work in PHP)

8:39 packages into a constant... don't have to switch in your head to another tool. That part should be talking about mental overhead of context switching concepts (tools) while already keeping the rest of jigsaw in your head while bringing in other jigsaws.

Not gonna lie, I haven’t tried it yet but I like the philosophy of Zig more than the Rust’s one. I am into Rust right now for its safety but I can feel it being tiring to code in, almost like C++. Should I switch? Will Zig be professionally viable? I can see Zig being an awesome hobby language but Rust looks like it is being adopted more and more.

18:21 undefined is like empty glass, it got air in it but it doesn't stop us from filling water or beer or anything you want to pour in it

For the import aliasing, in rust, just only do the `use` for one level higher than the conflict so you can qualify it....

23:52 that’s because types can be manipulated at Comptime. You need to treat it as value for generic types for example. I somehow like that because even before you reach generics it hints at you that types are first class.

Are rust allocators as good as Zig allocators? Zig allocators are really my only reason for looking at the language right now. I'm sure that there are other reasons that should be compelling, but I just haven't found them yet.

The package manager is going to have warnings for when you import code that is not version > than 1.0.

I cracked up at the comment about TS being "lentils, except every sixteenth lentil is actually a BB, and you break your tooth when you bite down on it." 😂

Try x is a shortcut for x catch | err | return err, no hidden control flow, it’s in the docs as an expression shortcut.

There is a proposal for the assignment of functions like that, it isn't done yet if they decide to do it.

I'm gonna add some stuff to this. In my opinion I will say what are my good, bad and ugly things about zig I think should be added. The good: - Compile time expressions and execution. I can't even express how good this is, even if you don't use explicitly comptime, the compiler is smart enough to spot where it can do optimizations for compile time values, or when you want to specify it to get things done for be ready to use on runtime. Or even if you want to use conditional compiling depending on variables known in compile time without using macros just by making evaluate it when it is compiling (you can also define variables with its build system before compiling) so it's very handy if you want to define platform-specific implementations - Errors. Specially compared to C where errors don't even exist. - Cross compiling. I consider this one if it's biggest features, you can compile for almost every LLVM supported architecture, and a lot of OS from every device where zig runs, so you can compile a program for a windows computer with i386 architecture with MSVC abi even with your Android phone. Also you can add cpu features and instructions set for better compatibility and performance for your target without installing anything else (not like in rust where you have to install a target-specific toolchain/target binaries or some custom native toolchain like Microsoft Visual to be able to target MSVC ABI). I have to add that the standard library does not have all the functionalities implemented for each platform/abi, so there are a lot of things missing. - It is already self-hosted within ~50mb weight toolchain statically linked with zero dependencies. That's it, you don't need anything else, you can run and compile from almost everywhere. Drop-in C/C++ compiler. This is just a great thing because it uses LLVM/Clang underneath to achieve it but with a lot of layers of code of optimizations to make the compiler cross platform too. It also has drop-in an archiver, objcopy-er and a linker will be added in the future. This means you don't need to install neither GCC nor clang nor anything else to compile your C/C++ binaries for a almost every target. And if you need to, you can link it against libc for a lot of platforms too, because they are already shipped inside the toolchain. - Great C compatibility. You can use a lot a lot of C libraries for your zig projects, you only need to import them with @cImport and @cInclude macros, and also you can define C macros with @cDef when using C source files for conditional compiling or just defining macro variables - Incredible build system. Zig has an incredible build system where you can create a build script in a build.zig file to define all the logic needed to compile your project. You can use it for your zig projects or even for other languages like C, this means you can replace Makefiles or Cmake with zig build system and cross compile C, C++ and zig projects with the same toolchain. - Blazingly fast. Zig is just as fast as C or even faster because Zig produces a highly optimized assembly since zig is a low level language with high level features. - Compile time and runtime type reflection. Zig has reflection. With it you can create generic types using functions to generate structs or use pattern matching with the switch statement to conditionally do things based on types. - Statements as expressions. You can define variables using switch or if statements just like Rust by typing it as result for a variable. - Meta programming. Zig has meta programming to achieve things without the need of a macro system. For example, you can access to the fields of a struct and get information about it like its type and values (the struct type has to be known in compile time) - Other tools. Zig has useful things like a C translation tool, that converts your C code into Zig code. You can also compile your Zig code into C code by targeting C as your output format. The Bad: Since zig hasn't reached 1.0 yet, it lacks a lot of documentation, specially for the std lib. There are not a lot of zig projects, so there aren't a lot of usable packages too. No string type. This is intentionally done by design to keep the language small and simple, but this makes a little bit harder to understand and there aren't string specific functions, even for formatting you always have to specify with {s} to let the compiler know that you are working with strings, if not, then it will print it like a bunch of numbers because it is an unsigned int slice itself. The Ugly (at least for now): - Package Manager. Zig doesn't has an "official" package manager yet, there is one incoming but nothing done yet. There are attempts of this like zigmod and gyro but those aren't official. - Lots and lots of bugs. Zig is still under development, so it's not weird that this happens often, but I personally think there are a lot of broken things and it's not very usable for big projects yet. - Breaking changes every release. Because zig tries to improve its syntax or how things are currently done, it has a lot of breaking changes all the time, so it doesn't has any backwards compatibility. - It has very few packages. As mentioned above, Zig is a very new programming language, and because its breaking changes, bugs, and lack of a package manager, there is a very tiny amount of packages that you can use for your projects and aren't stable yet Due to all these things I recommend to wait to Zig reaches maturity to use it in production, meanwhile you can give it a try and test it, or even improve the language itself

would be very nice if you could make a video on what would be your ideal language combining all your wishes and cool stuff already in existing languages :) Thanks !

have you seen "What's Zig got that C, Rust and Go don't have? (with Loris Cro)" on the Developer Voices channel?

I don't really get the want for that sort of auto type detection based on how the var is used at compile time. I suppose it is quicker to write, but doesn't it make the code less descriptive and readable?

I'm a fan of the snake case for vars, camel for fn's and pascal case for Types. I can tell what it is just by looking at it.

Unrelated question: what colorscheme is that?

How do you write Typescript and not get skipping curly braces? 🤔

Using advent of code to learn languages is great. Doing it in C allowed me to learn all about C's hashmap and arraylist implementations just like you said!

I rotate between about 6 different case styles so that each of my classes has it's own feel to it. It helps me remember but people would hate me if they had to read my code.

17:20 (About _undefined_ in Zig.) D has _void_ for this purpose. If you don’t initialize a thing, it’s default-initialized, which means zero-initialized for types that have no natural invalid value, and an invalid value for types that have. In D, _float f;_ makes _f_ gives NaN value, not zero. I guess Zig’s _undefined_ initialization is the same as D’s _void_ initialization: It says: Don’t actually default initialize this, it’s a waste of time, I’ll override it anyway, just reserve me some space. I consider that not initialization, it’s mere resource acquisition. Initialization is having your object be ready to be used, but mere memory acquisition (i.e. resource acquisition) usually requires a constructor to run over it to make the object fully formed; sometimes, for performance reasons, you want that. In most cases, you want the memory acquisition and initialization to happen in one go without a second thought. C++ classes do that; if you do _vector xs;_ that vector is fully initialized and usable. In C++, getting just the memory and initializing later is hard - as it should be.

I'm designing a programming language at the moment, and contents like these are super invaluable to me. I love seeing what people prefer/hate in languages. Maybe we'll get Primeagen react to the first draft one day, when it's ready :)

Also, your example at @23:33, omits the fact that in C++ struct has default public visibility, thus verbosity is equivalent to zig-lang.

If Zig can't use existing C++ code, it's not a replacement for C++. The replacement for C++ will be something like cppfront, Carbon, or Nim. (I don't know what C++ interop with Rust is like, but I heard it's not that good.)

20:43 I mapped that exact key to capslock on my keyboard (old ergodox ez)

Tom truly is a genius (genious? djeeniyous?)

1:45 “There should be 1 way to do things.” There should be at most 1 simple way to do things, and for simple things, there should also be at least 1 simple way to do things.

My man is not using closures in Rust? Or what was that | rant in the article. Sounds suspicious

Learning Haskell with aoc, was not prepared for the dynamic programming

3:31 This is more obvious, if you don't write the documentation for your crate then there will not be one, it is true for Zig and any other languages tho

12:00 yeah I HATE that identifier.?.property is the equivalent of unwrapping in Ziglang. Why, damn you? Why is "unwrapping" harder to spot and easier to use than propagation, which is almost always what you want to do? It's also IMO assymetric syntax, because do deref with ident.*.property, and both pointers and optional types are marked with "*" and "?" in their types.

Javascript is Lentils with 50% stainless steel BBs, and Typescript is Lentils with 1% stainless steel BBs.

I think you would love Swift

how his terminal line cursor always bottom?

The hardest problem in computer science: Naming Things. (Regarding mixing snake case and camel case in Zig)

27:40 I thought you didn't like auto vars?

I’m very sad that he didn’t notice that the code for trying to declare variables without a type annotation wasn’t actually compiled :(

Bro doesn't even have htop 💀

Does someone know where I can watch the Zig streams? He always goes live at the most inopportune moments.

Trying Dart anytime soon?

I'm still trying to learn rust, but takes a while

Zig subreddit has lots of answered common questions that search engines don't index

"just enforce curly braces" THANK YOU

THE LONG AWAITING

04:12 "While loops work, why add another way" 19:23 "For loops are a bit strange..."

you don't need {}'s in Java?

my parents walked in on me zigging, the worst part is i didn't even stop.zig is like that sometimes.

32:38 That's a good criticism

16:20 "Emooootional damage!"

Intro; If you are not "rusting" all the time you are hard pressed to keep up.... You mean you get Rusty?

I use an Apple keyboard. I have up to F19 on my keyboard; Getting to | is trivial

Programming languages are the new JS Framework. Lot’s of content for Fireship with a new language arising every week. 😂

Reminds me of when Swift came around, and so on back.. Am I missing something? Do developerkind have to go through this again and again and again, because someone just had a genius idea now (which someone else had 20 or 1 year ago)?

Or built-in priority queue..

13:30 Why? I think it's quite obvious that certains workarounds would be provided by the community in any given language, this is a truth for serialization (as an example) in almost any language out there, C#, Kotlin, Java, Rust, C/C++, even Zig. Error handling is literally a very complicated task and having a community-driven lib for making things easier is 'ok', that's why we have things like macros in first place

Actually first time I saw error handling, when I tried swift. That was 2020

C is my favorite language, but it’s looking like zig might be just as good if not better. Hopefully it doesn’t get bloated

9:19 Nah, borrow-checker prevents some data racing conditions too, the predictability of the memory state, and it is more concise, but it is a powerful feature to be reminded of something.

I don't like rust that much, I'm more interested in Zig to be honest, but the critique of rust at the beginning is a bit shallow imho. Zig is not present in production as much as Rust, I believe that given enough time any programming language can acquire a reputation for being complex in some way. Yes Zig looks more simple if you appreciate languages that have no hidden control, but in other ways it can become complex and I think we'll see that coming up with Zig when eventually 1.x hits. Specifically I think Zig will have a lot of complexity around comptime programming, all be it, it will probably be a more comprehensive comptime programming than other languages by a very long shot mainly because because it doesn't shy to introduce metaprogramming into streamline programming (for example with "@import" or "comptime when") it will still be metaprogramming. In short, I don't think we can tell how complex of a language Zig is yet because, although there is surprisingly a lot of Zig code out there right now, there isn't enough to say if it's a complex language or not, and secondly because Zig is not officially in 1.x, the language may still introduce new things or change other things. I tried both Zig and Rust, I liked ZIg more and that's okay, because at the end of the day I'm coming from the world of Java, C#, Php, Node, and if any of these 2 languages can bring more programmers over that's a good thing. Some shills may say otherwise, but both Zig and Rust encourage you to write more stable, fast, and less convoluted software, and that's win for everyone: developers and users.

If you're not always rusting... you get rusty?!

I think fresh cucumber being better than pickled is the most controversial take I’ve seen on your channel.

if you're not always rusting, you're ganna get rusty with the rust

Zig is dope

I like the idea of Zig experimenting with how to do unsafe Rust, but better. Personally, I'm worried about how fast and loose Zig is playing with its syntax right now. The `try` example shown early on I think is a good example of where Rust is substantially better. Also, a singular type that represents all errors (the ! type) in Zig does sound convenient, until it's not. Rust error handling is definitely more verbose and needs some evolution to really streamline the process (like we saw with the ? operator), but the idea of losing type information on errors just because it's cleaner in small examples seems like a bad choice. To be honest, the theme I see in Zig is a lot of contradictions. "There should only be one way to do everything", but now you have two looping structures because it turns out it's really nice to be able to use a for loop. "The language will have no macros.", but every external piece of code is brought in with the import macro. It's the right direction I want languages to head in, but simplicity and power are actually a difficult combination to hit. Look at how much Rust has had to evolve thanks to all the different domains it's used in.

TL;DW: C attempted to finesse error messaging by arbitrarily defining zero as an error value (i.e. null) for pointer types, while also defining zero as a boolean error value (i.e. "no error") for integer function return values. That led to lots of ad hoc context-dependent (i.e. error prone) conditional error handling code. Zig avoids these pitfalls by defining both pointers and integers as C-style unions, that contain separate numerical fields and error fields. It then provides compact punctuation prefixes for specifying which union field you want to manipulate, eliminating the ambiguities that C left to ad hoc error trapping code to disentangle.

Using snake case and camel case to quickly visually distinguish different sorts of things makes some logical sense to me, but it does look disguising.

Ziglangs error handling is certainly interesting. I'm not sure if I prefer it - probably not, haven't ever gotten around to play enough with it - , but it's interesting and certainly easier to start with than Rusts Result. Theyre not really an C union tho. It's actually, from my understanding, a struct made up of an C error code and the return. The C error code could also be explained as a Rust enum with all error conditions, but on the ENTIRE program, and without the possibility for instance data. Because there is no instance data, it's easy to do it, as it does implicitly, over the entire program, while also avoiding the size overhead that large error instance data would require (from ALL error returning functions, without fancy optimizations that is). BUT it does also mean that if you want to add data to an error case, you need to communicate that out of band. And it also means there's a potential for name conflicts.

You have to look at Swift...

When are we going to get a language called “Tom” - the programming language for geniuses?

I love primeagen. I sincerely do. That being said; the borrow checker is not important, honestly, when it comes to deallocation and allocation. That's not even _remotely_ the point, really. It has everything to do with races and having a really constrained approach to sharing; which provides for _very good_ compiler optimizations in a multi threaded environment (and with CPU's pipe lining and speculative branches etc, also opens up for optimizations in single threaded programs), it also allows for optimizations that C can do with the `restrict` keyword, since a memory address can't be aliased (unless you drop into unsafe). Zig's allocator can't help you with that. These are two different problems being solved. That being said, I _wish_ Rust had better allocator aware design. Zig has that, and C++ has it with std::pmr. It's just that C++ feels like a better language overall, for all it's terribleness. I can do what Zig does with it's allocators, by using std::pmr. And PMR was introduced as a TS to C++ I think in 2013 or '14 and was finalized/landed in c++20.

"Having it use the same mechanism..." I'm wondering if they're referring to the fact that the keywords mod and as are overloaded in Rust whereas imports in Zig just work the same way as variable declarations.

I want to think I'm a rust scientist. You confirmed, I'm just a rust farmer.

28:00 I use Brave, btw

What the hell as anyhow in Rust?

Amen for mandatory squirrely braces