I’ve actually wanted to try switching to a career in rust (I currently do iOS dev). But there’s no rust jobs. At least swift is a good language though. I’m glad I don’t do Java or one of the million flavours of JavaScript at my day job.
@@Xaxxus Do you find that pay for an iOS developer is better than for let's say a frontend/backend developer in some of the web techstacks? I'm curious because I've dabbled with the idea of trying mobile dev ( I'm a C++ backend engineer ). I do realize that pay is subject to the market around you.
so frustrating. we started a new project but our company doesnt wanna allow us to introduce something new... ANYTHING new... still same old java (hey kotlin is fine now too, yaay, progress! ;D), spring angular typescript :O they praise themselves that they introduced kotlin last year and now fear that people onboard too many new things.
I feel the same, I can't handle the high level mass languages anymore I need more control of what I'm coding and no have to follow this nonsense 1000 layers of abstraction
"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.
Same effect I get with Mathematica. No matter how expert I get at it, there will always be a time when I come back and wonder what the hell is going on in my own code
😮💨 sole reason i started learning rust to avoid this....i thought strong type system and more modern system than structure than c including abstractions would make it easy to see a past project.... what js also missing....
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.
Then there's Nim, where for some god-foresaken reason, identifiers are case-insensitive, and blind to underscores. So fooBar and foo_bar are the same identifier.
@@109Rage the moment ```ìnt temp;``` and ```int Temp;``` are in the same scope it is already time to wake up and get real and start to learn some real programming
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.
The giraffe ate the rust, now i gotta "GO" and not get "TYPED" or "SCRIPTED" in a newspaper but i just got caught and thrown into the shark tank with the worse, the terrible, the evil c++ raw compiler jaws 😂❤
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.
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.
@@harleyspeedthrust4013 actually plenty of backwards incompatible changes were succefully added to js, for example with "use strict" annotation and later with the js modules. So it's a lazy excuse to say that crap is left forever for compatability. Sure old scripts have to work as they are but new scripts can be annotated with version number. Now that said I wouldn't call people working on it idiots. ECMA standard is probably the most distributed and open and widely used standard that there is accross whole software industry. It's very difficult to agree on good decisions when there are so many competing opinions.
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.
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.
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);
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.
Zig is far, far more tedious to program in than C++. Rust has more ergonomics for less control or it is harder to control on a granural level. But since tediousness is an issue to you thats good. Zig is probably the most tedious out of all three and by far too. You got everything in C++ that Zig has and more with the exception of comptime functions. You also have a massively larger eco system in C++.
Ok so Rust still looks like the best choice so far. So many new low level languages. Choosing one not knowing the low level world feels daunting today, C/C++ are still going strong and we don’t have a clear winner between these new ones. I would like to avoid learning a language that will be irrelevant in a few years. We have Rust, Zig, Nim then Google announced Carbon and a few days ago I have heard about Mojo that look like a power up of Python into the low level realm. It is getting very confusing especially if you don’t know precisely what you are looking for.
@@simonfarre4907 ok, thank for the feedback. I am kinda attracted though to the “no hidden control flow” philosophy. For how Zig is presented looks like a quicker Rust you would grab for smaller projects while Rust is more for enterprise. I hate meta programming though and that comptime doesn’t look great to me. I will keep going with Rust. Last time I tried to look into C++ it looked very painful to learn as you need to understand its evolution and the ecosystem which is almost as complex as the language (even if it is battle tested).
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.
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.
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." 😂
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
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.
you can have integers in Zig that have specific sizes like: u0, u1, u2, u54 etc. Which corresponds to unsigned integers of size 0, 1, 2 and 54 bits and anything in between or even bigger sizes. They are especially usefull in packed structs.
@@wiktorwektor123 i like that, that's like how rust does it too. makes a lot more sense today than "an int is no smaller than a short and is usually 32 bits but not guaranteed" and that type of nonsense
@@phitc4242 But it still doesn't have generics. Zig has them and many more out of the box while being more low level than C and maintaining high level syntax at the same time.
@@wiktorwektor123 I make generics happen with macros lmao XD (coolest thing I made with that is a generic vector or a hash map/lookup table for instance) there's also -- in case you need something more "dynamic" -- (don't really know how to describe things lol) there is also the _Generic keyword
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
Like tokio is the go-to async library, anyhow is the go-to error library for binaries which makes complete sense. They take a survival of the fittest approach where the best community tools will come out on top.
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
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.
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) }"
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.
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?
3:30 If you find a Rust crate with severely lacking documentation, ping me. I've set myself a goal of improving the state of Rust crate documentations. rustdoc is extremely powerful, with it's support for markdown and unit-tested code examples. But that stuff is only good when crate authors use it!
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.
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.
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.
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)
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.)
@@wiktorwektor123 As a C replacement it makes totally sense. I wrote my comment because I think the author of the blog wrote at some point that they think of Zig as a potential C++ replacement.
@@dariusduesentrieb Author of this blog made mistake in that case. Rust is supposed to replace C++. Zig is supposed to replace C. With generics and cross-compilation and LTO on by default it has HUGE chance to do so.
Rust C++ interop is worse than Zig because Rust's C interop isn't great either. Zig has fantastic C interop, so using C++ code still requires a C binding, but nothing more. Of course, if you want to make it more idiomatic, you can write a Zig wrapper as well, but using C libraries directly in Zig is just as, if not more easy than using them in C. Rust is a better C++, Zig is a better C and Carbon can be used to maintain existing C++ infrastructure before replacing it with something else.
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 :)
@@SamualN I'm working out the syntax at the moment. No compiler yet. I have to mention, when I started designing this I went with kebab-case, thinking "kebab-case needs some love". Then I thought "nobody is going to like this", and switched to snake_case. I did NOT expect a shoutout to kebab-case in this video though. So, I'm reconsidering :) Or maybe they were being sarcastic.
No matter how much time you spend in design and reading/watching some one else opinion you will never have language that everybody loves. There will always be people who don't like parts or all of it. You can't satisfy all people preferences.
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.
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 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.
I never use std:: anything for memory stuff, I've always found it to be annoying (as is C++), I much rather write my own allocators and do a Odin-like context thing for multi threading
@@marcs9451 I don't think you understand what "PMR" stands for in std::pmr. It stands for polymorphic memory resource. It means writing your own allocators. Just like you do in Zig, just like you do in Odin. That being said, we all wish C++ had introduced PMR in c++11 already. The previous allocator-related TS was a terrible idea.
@@marcs9451 If you want to know more about what PMR actually is, there's plenty of good CppCon talks both technical presentations and "how to use-example presentations". They're all great.
yeah C++ is just a great language. it hss its quirks but you can do pretty much anything and you can do it however you want. the standard library has a ton of useful stuff and if you know what you're doing then memory ownership will be clear in your code. I feel like memory ownership is only hard when it's a new concept, and that's where Rust can help, but once you get it you keep it in mind and it becomes easy.
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 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?
depends on the context and what you compare it to. also, readability is in the eye of the beholder, and a lot of it depends on their experience level I'm not really a fan of the default type being some assumed int type as he described in the video tho
After looking again at my java code from last night, I don't think I understood what he said, it seemed to me he said Java does not have mandatory curly braces, was that maybe the first version of java or what did he mean exactly?
@@portalomania I'm not exactly sure what he meant since I'm not a Java coder but I'm just a fan of curly braces. Maybe he meant that curly braces are not mandatory on one line if statements and for loops
@@portalomania You still don't need {} if it's on a single line. My teachers would mark me for doing this even though it was part of the language because it's just a bad feature.
@@gljames24 I am a noob so pardon me if this is a dumb question, why would having curly braces mandatory in single lines of code be a good thing? seems to me that would make it a lot worse not better
@@portalomania Because it allows for things like inlining code and a bunch of other features because the it garunttees to the compiler that it can parse the curly braces without it being ambiguous whether they will be there or not. It's also consistent for programmers reading the code where it would also be difficult for us to know if the control statement is going to function how we intend.
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.
As far as i know (which isn't much) you can change the global allocator in Rust, and it appears that more granular allocators like Zig's are coming to Rust.
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.
Not having curly braces without something like "END" at the end of the scope actually sucks. Sometimes you just need a multilined lambda, sometimes you're refactoring code and indentation is what causes bugs or makes the code not compile. wrapping enerything in curly braces is like a present, everything is all neet and contained. It feels unsafe working in languages that rely on indentation for scope identification
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)?
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.
"!type" means it infers error type, you can always be very specific and say: "FileError!type" and if function will try return other type of error compiler will tell you exactly where and why and refuse to compile code.
I don't think speaking undefined is a good type. Because undefined only happens if there's no value either possible to present or unknown. What's best possible thing cam be is that initializing the array with 0. It boils down to much simpler terms. I still feel like Zig quite isn't as mind blowing as the article author wrote. Also, at that part where he told that Rust enforces to "imports" in a sense where you practically can't state import alias, I guess that's what he mean. This isn't true in today's date though. Article author also target both C# (keyword: using) and Rust (importing style).
I don't get the comment about having to be in Rust world to be fresh with everything that's going on. Rust hasn't had any major changes since like a few years. And most of the changes were adding things that you would expect to "just work", like being able to define async methods in traits or returning and `impl`.
27:49 isize as default integer type seems like a bad idea. Having a type which has a dynamic amount of bits depending on architecture doesn't really sound like a smart idea. One could at most argue for a i64.
@@remrevo3944 well just to tell you then, isize seems to be inspired by ssize_t from C. there's also size_t (usize). it does make sense, and why it exists, but if it's good practoce or, not, idk
"Everywhere you do an allocation, you know you need to do a deallocation, its very clear" -The Primeagen 20.05.23 What??? Since when is ThePrimeagen a fan of manual memory management? Also zig does not have an affine type system. Which makes it a C++ without the legacy shit. It has some nice technical implementations, like its ability to hot reload stuff (if it still has it), and its super fast compile times, but in the end it does not solve any big problems just puts a new coat of paint on. Also completely unrelated, but have you ever look at the roc programming langugae
I just checked their homepage and it is just a wall of text, if you want to check the language there's like 5 youtube videos linked which are at best 40 minutes long. Quite honestly, not a good first impression. I just want to know what the language looks and feels like, I don't need a whole ass introductory course on it. It claims to be purely functional so I guess it is similar to Haskell?
"does not solve any big problems" Non-nullable pointers by default, strict type system, automatic memory leak detection, comptime (which is a unique approach to both macros and generics), simple syntax, extremely fast compilation, small executable size, extremely good C interop and more Not really sure what you expect out of a programming language, but Zig blows its competition out of the water.
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.
I really want to like zig but I just cant. There are some really cool features in here but there are also a ton of messy things that need to be fixed. Imports for example, I like the concept but writing const somename 50 times to properly avoid writing import.some.whatever everywhere just sucks. They need some glob import/namespace syntax. I don't want to have to alias everything but that is seemingly what you have to do with zig imports. It's like they saw some name conflict issues and overcorrected too much. At least in rust I can import everything in one single block and if I need to alias it I can just use the as keyword. Compiler errors are also cryptic as hell, reminds me of clojure errors. I forgot a tuple in a log call in one of my advent solutions and rather than pointing to the line where this occurred, I got some vague fmt.zig error. You should never see tracebacks to a std library or a external library as the first line of an error; it's not helpful to me that fmt.zig 86:9 expected a tuple. In rust, this would mean that the std library itself is broken. It should have told me that on line 20 of my code I forgot a tuple. Initializing complex types in zig is really annoying. Every single time I write the keyword undefined I feel like I'm doing something wrong. Maybe it's because I'm so used to null causing problems but it feels like a terrible addition to a language that's supposed to be null safe. I really don't like var versus const. The way rust and ocaml do mutability makes the most sense. You start with immutable variables and you add a keyword if you want them to be mutable. Having to decide if the variable is constant or mutable with two different keywords is deceptively clunky. Also because the LSP doesn't tell you what the return type of a function is as far as mutability is concerned, oftentimes I find myself using var more than I feel like I should. The try keyword is just another Band-Aid that doesn't really need to exist. I like the question mark in rust as a solution for unwrapping. Try just brings back so many bad memories from languages that use exceptions. The compiler needs to be able to deduce more types than it currently can. That var x = 0; is invalid sucks. The compiler should be able to figure out what type of integer I want based on static analysis of the code. And even when it can't figure out what I want it should at least have some kind of default integer. There are many other issues as well which I'm not going to go over. But yeah I'm probably going to stick with rust. Zig is supposedly simple but it's really not at the same time. Just because it's a small language doesn't mean it's actually conceptually simple.
I hate squirrelly brackets. I use an m4 macro to map { to start_seg and } to end_seg. This eliminates the need for Scottish brackets and makes code 5,217.8% more read-able.
11:55 That's actually something which i dislike about Rust since these kinds of unwrapping aren't grepable. (And because of that I write explicitly .unwrap()).
Package managers are ok, but can lead to pathological situations where your code is like a fraction of the whole project because you use a lot of downloaded libs with their dependencies, and you only use a fraction of the downloaded libs themselves. So package manager should not be provided by the language itself.
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.
Oh this hits home
I’ve actually wanted to try switching to a career in rust (I currently do iOS dev).
But there’s no rust jobs.
At least swift is a good language though.
I’m glad I don’t do Java or one of the million flavours of JavaScript at my day job.
@@Xaxxus Do you find that pay for an iOS developer is better than for let's say a frontend/backend developer in some of the web techstacks? I'm curious because I've dabbled with the idea of trying mobile dev ( I'm a C++ backend engineer ). I do realize that pay is subject to the market around you.
so frustrating. we started a new project but our company doesnt wanna allow us to introduce something new... ANYTHING new... still same old java (hey kotlin is fine now too, yaay, progress! ;D), spring angular typescript :O they praise themselves that they introduced kotlin last year and now fear that people onboard too many new things.
I feel the same, I can't handle the high level mass languages anymore I need more control of what I'm coding and no have to follow this nonsense 1000 layers of abstraction
"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.
Same effect I get with Mathematica. No matter how expert I get at it, there will always be a time when I come back and wonder what the hell is going on in my own code
😮💨 sole reason i started learning rust to avoid this....i thought strong type system and more modern system than structure than c including abstractions would make it easy to see a past project....
what js also missing....
Not rusting enough broooo
Haha yeah that's the problem with esoteric languages which let's be honest to a certain extent rust is
@@anon-fz2bo Do you know what an esoteric language is?
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 can appreciate this
Then there's Nim, where for some god-foresaken reason, identifiers are case-insensitive, and blind to underscores. So fooBar and foo_bar are the same identifier.
@@109Rage the moment ```ìnt temp;``` and ```int Temp;``` are in the same scope it is already time to wake up and get real and start to learn some real programming
@@109Rage i like that
Opinions are overrated. Just get the job done.
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.
yayaya!
I Zigged so much to the point that I left my compiler in the rain and got Rust
☠️ Go touch some grass and look at the Lua, but be careful with that Python overthere
The giraffe ate the rust, now i gotta "GO" and not get "TYPED" or "SCRIPTED" in a newspaper but i just got caught and thrown into the shark tank with the worse, the terrible, the evil c++ raw compiler jaws 😂❤
@@alexdefoc6919 this is the best one 🤣
Don't go outside, otherwise you will "C" that Python next to you!
@@MeinDasIstGut this one was simple, but wise 🧐
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.
Zig is definitely a fitting C replacement.
@@airman122469 IKR!
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.
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.
@@harleyspeedthrust4013 actually plenty of backwards incompatible changes were succefully added to js, for example with "use strict" annotation and later with the js modules. So it's a lazy excuse to say that crap is left forever for compatability. Sure old scripts have to work as they are but new scripts can be annotated with version number. Now that said I wouldn't call people working on it idiots. ECMA standard is probably the most distributed and open and widely used standard that there is accross whole software industry. It's very difficult to agree on good decisions when there are so many competing opinions.
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.
yeah, isize is meant for things which are target dependent like max sizes of array indexes
I love that having keys on your keyboard with unknown functions is a flex in the programming community.
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.
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);
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).
th-cam.com/video/QwUPs5N9I6I/w-d-xo.html tom reference
Love this zig arc. Keep it going!
I like how things start with capital letter if they return a type, and small if not in zig
damn that's sick
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.
Zig is far, far more tedious to program in than C++. Rust has more ergonomics for less control or it is harder to control on a granural level. But since tediousness is an issue to you thats good. Zig is probably the most tedious out of all three and by far too. You got everything in C++ that Zig has and more with the exception of comptime functions. You also have a massively larger eco system in C++.
Keep going with Rust, you'll see its beauty
Ok so Rust still looks like the best choice so far. So many new low level languages. Choosing one not knowing the low level world feels daunting today, C/C++ are still going strong and we don’t have a clear winner between these new ones. I would like to avoid learning a language that will be irrelevant in a few years. We have Rust, Zig, Nim then Google announced Carbon and a few days ago I have heard about Mojo that look like a power up of Python into the low level realm. It is getting very confusing especially if you don’t know precisely what you are looking for.
@@simonfarre4907 ok, thank for the feedback. I am kinda attracted though to the “no hidden control flow” philosophy. For how Zig is presented looks like a quicker Rust you would grab for smaller projects while Rust is more for enterprise. I hate meta programming though and that comptime doesn’t look great to me. I will keep going with Rust. Last time I tried to look into C++ it looked very painful to learn as you need to understand its evolution and the ecosystem which is almost as complex as the language (even if it is battle tested).
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.
lmao
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.
Os can give zeroed but Malloc is Libc which can return your previously used space .
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." 😂
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
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.
you can have integers in Zig that have specific sizes like: u0, u1, u2, u54 etc. Which corresponds to unsigned integers of size 0, 1, 2 and 54 bits and anything in between or even bigger sizes. They are especially usefull in packed structs.
@@wiktorwektor123 i like that, that's like how rust does it too. makes a lot more sense today than "an int is no smaller than a short and is usually 32 bits but not guaranteed" and that type of nonsense
@@wiktorwektor123 c23 should add this
@@phitc4242 But it still doesn't have generics. Zig has them and many more out of the box while being more low level than C and maintaining high level syntax at the same time.
@@wiktorwektor123 I make generics happen with macros lmao XD (coolest thing I made with that is a generic vector or a hash map/lookup table for instance) there's also -- in case you need something more "dynamic" -- (don't really know how to describe things lol) there is also the _Generic keyword
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
so tru bestie, faz o gama👇
Like tokio is the go-to async library, anyhow is the go-to error library for binaries which makes complete sense. They take a survival of the fittest approach where the best community tools will come out on top.
@@tqwewe whats the goto error lib for libs
@@remains2246 I would take a guess and say it's thiserror
@@remains2246 Yep its thiserror
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
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
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
and in debug mode, zig fills it with smoke (0xaa) so that if you see smoke somewhere you know it came from a cup you didnt fill
One of the best features of Zig is solving the problem with function coloring.
What does that mean?
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.
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...
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.
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) }"
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.
Try Nim also, don't just limit yourself to Zig just because it's the most popular thing on people's radar besides Rust.
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?
3:30 If you find a Rust crate with severely lacking documentation, ping me. I've set myself a goal of improving the state of Rust crate documentations. rustdoc is extremely powerful, with it's support for markdown and unit-tested code examples. But that stuff is only good when crate authors use it!
Javascript is Lentils with 50% stainless steel BBs, and Typescript is Lentils with 1% stainless steel BBs.
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.
Also, your example at @23:33, omits the fact that in C++ struct has default public visibility, thus verbosity is equivalent to zig-lang.
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.
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.
So much objectivity from a Rust fanboy. Respect!
27:40 I thought you didn't like auto vars?
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)
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.)
Zig was designed as C replacement not C++ and it can use C libraries without any bindings
@@wiktorwektor123 As a C replacement it makes totally sense. I wrote my comment because I think the author of the blog wrote at some point that they think of Zig as a potential C++ replacement.
@@dariusduesentrieb Author of this blog made mistake in that case. Rust is supposed to replace C++. Zig is supposed to replace C. With generics and cross-compilation and LTO on by default it has HUGE chance to do so.
Rust C++ interop is worse than Zig because Rust's C interop isn't great either.
Zig has fantastic C interop, so using C++ code still requires a C binding, but nothing more. Of course, if you want to make it more idiomatic, you can write a Zig wrapper as well, but using C libraries directly in Zig is just as, if not more easy than using them in C.
Rust is a better C++, Zig is a better C and Carbon can be used to maintain existing C++ infrastructure before replacing it with something else.
If you're not always rusting... you get rusty?!
Zig subreddit has lots of answered common questions that search engines don't index
it's private now
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 :)
how far have you gotten so far? I'm currently stuck on type checking and code gen
@@SamualN I'm working out the syntax at the moment. No compiler yet.
I have to mention, when I started designing this I went with kebab-case, thinking "kebab-case needs some love".
Then I thought "nobody is going to like this", and switched to snake_case.
I did NOT expect a shoutout to kebab-case in this video though. So, I'm reconsidering :)
Or maybe they were being sarcastic.
No matter how much time you spend in design and reading/watching some one else opinion you will never have language that everybody loves. There will always be people who don't like parts or all of it. You can't satisfy all people preferences.
@@wiktorwektor123 I don't think anyone's trying to please everyone
Heyo, im working on a language of my own too, wanna exchange thoughts?
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.
04:12 "While loops work, why add another way" 19:23 "For loops are a bit strange..."
My man is not using closures in Rust? Or what was that | rant in the article. Sounds suspicious
have you seen "What's Zig got that C, Rust and Go don't have? (with Loris Cro)" on the Developer Voices channel?
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.
Calling "try" hidden flow control is like calling "if" hidden flow control
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.
I never use std:: anything for memory stuff, I've always found it to be annoying (as is C++), I much rather write my own allocators and do a Odin-like context thing for multi threading
@@marcs9451 I don't think you understand what "PMR" stands for in std::pmr. It stands for polymorphic memory resource. It means writing your own allocators. Just like you do in Zig, just like you do in Odin. That being said, we all wish C++ had introduced PMR in c++11 already. The previous allocator-related TS was a terrible idea.
@@marcs9451 If you want to know more about what PMR actually is, there's plenty of good CppCon talks both technical presentations and "how to use-example presentations". They're all great.
yeah C++ is just a great language. it hss its quirks but you can do pretty much anything and you can do it however you want. the standard library has a ton of useful stuff and if you know what you're doing then memory ownership will be clear in your code. I feel like memory ownership is only hard when it's a new concept, and that's where Rust can help, but once you get it you keep it in mind and it becomes easy.
20:43 I mapped that exact key to capslock on my keyboard (old ergodox ez)
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
same, C is king. c23 looks dope
I love that my job is C. Not C++ but C. The danger makes it exciting
Is zig + go set omnipotent like rust, but faster to write?
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!
Bro doesn't even have htop 💀
my parents walked in on me zigging, the worst part is i didn't even stop.zig is like that sometimes.
Tom truly is a genius (genious? djeeniyous?)
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?
depends on the context and what you compare it to. also, readability is in the eye of the beholder, and a lot of it depends on their experience level
I'm not really a fan of the default type being some assumed int type as he described in the video tho
The package manager is going to have warnings for when you import code that is not version > than 1.0.
Try x is a shortcut for x catch | err | return err, no hidden control flow, it’s in the docs as an expression shortcut.
Amen for mandatory squirrely braces
After looking again at my java code from last night, I don't think I understood what he said, it seemed to me he said Java does not have mandatory curly braces, was that maybe the first version of java or what did he mean exactly?
@@portalomania I'm not exactly sure what he meant since I'm not a Java coder but I'm just a fan of curly braces. Maybe he meant that curly braces are not mandatory on one line if statements and for loops
@@portalomania You still don't need {} if it's on a single line. My teachers would mark me for doing this even though it was part of the language because it's just a bad feature.
@@gljames24 I am a noob so pardon me if this is a dumb question, why would having curly braces mandatory in single lines of code be a good thing? seems to me that would make it a lot worse not better
@@portalomania Because it allows for things like inlining code and a bunch of other features because the it garunttees to the compiler that it can parse the curly braces without it being ambiguous whether they will be there or not. It's also consistent for programmers reading the code where it would also be difficult for us to know if the control statement is going to function how we intend.
The hardest problem in computer science: Naming Things.
(Regarding mixing snake case and camel case in Zig)
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.
As far as i know (which isn't much) you can change the global allocator in Rust, and it appears that more granular allocators like Zig's are coming to Rust.
There is a proposal for the assignment of functions like that, it isn't done yet if they decide to do it.
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.
16:20 "Emooootional damage!"
Zig will be ready approx 2025/2026. Right now Rust is a better choice cause it's no longer in early access mode.
and I look forward to that day. I like Rust. I suspect I will like Zig better
For the import aliasing, in rust, just only do the `use` for one level higher than the conflict so you can qualify it....
Not having curly braces without something like "END" at the end of the scope actually sucks. Sometimes you just need a multilined lambda, sometimes you're refactoring code and indentation is what causes bugs or makes the code not compile. wrapping enerything in curly braces is like a present, everything is all neet and contained.
It feels unsafe working in languages that rely on indentation for scope identification
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)?
Yeeeeeeessssss!!!! It happened with Lisp, it happened with Signals, it happened with RDBMS...
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.
I think fresh cucumber being better than pickled is the most controversial take I’ve seen on your channel.
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.
"!type" means it infers error type, you can always be very specific and say: "FileError!type" and if function will try return other type of error compiler will tell you exactly where and why and refuse to compile code.
@@wiktorwektor123 Ahh ok, I guess that's not too bad of a syntax, thanks for clearing that up!
Pretty sure Prime's definition of TS came straight from the dictionary.
I don't think speaking undefined is a good type. Because undefined only happens if there's no value either possible to present or unknown. What's best possible thing cam be is that initializing the array with 0. It boils down to much simpler terms.
I still feel like Zig quite isn't as mind blowing as the article author wrote. Also, at that part where he told that Rust enforces to "imports" in a sense where you practically can't state import alias, I guess that's what he mean. This isn't true in today's date though. Article author also target both C# (keyword: using) and Rust (importing style).
I don't get the comment about having to be in Rust world to be fresh with everything that's going on. Rust hasn't had any major changes since like a few years. And most of the changes were adding things that you would expect to "just work", like being able to define async methods in traits or returning and `impl`.
27:49 isize as default integer type seems like a bad idea. Having a type which has a dynamic amount of bits depending on architecture doesn't really sound like a smart idea.
One could at most argue for a i64.
did you touch C before?
@@phitc4242 Not really, but the integer hierarchy seems extremely confusing.
And I'm really glad that rust doesn't have that concept.
@@remrevo3944 well just to tell you then, isize seems to be inspired by ssize_t from C. there's also size_t (usize). it does make sense, and why it exists, but if it's good practoce or, not, idk
Intro; If you are not "rusting" all the time you are hard pressed to keep up.... You mean you get Rusty?
How do you write Typescript and not get skipping curly braces? 🤔
"Everywhere you do an allocation, you know you need to do a deallocation, its very clear" -The Primeagen 20.05.23
What??? Since when is ThePrimeagen a fan of manual memory management?
Also zig does not have an affine type system. Which makes it a C++ without the legacy shit. It has some nice technical implementations, like its ability to hot reload stuff (if it still has it), and its super fast compile times, but in the end it does not solve any big problems just puts a new coat of paint on.
Also completely unrelated, but have you ever look at the roc programming langugae
I just checked their homepage and it is just a wall of text, if you want to check the language there's like 5 youtube videos linked which are at best 40 minutes long. Quite honestly, not a good first impression. I just want to know what the language looks and feels like, I don't need a whole ass introductory course on it.
It claims to be purely functional so I guess it is similar to Haskell?
It's not purely functional, lol, it still has while loops for God's sake
no language since the 60s has solved new problems, but nice try with the over generalization
"does not solve any big problems"
Non-nullable pointers by default, strict type system, automatic memory leak detection, comptime (which is a unique approach to both macros and generics), simple syntax, extremely fast compilation, small executable size, extremely good C interop and more
Not really sure what you expect out of a programming language, but Zig blows its competition out of the water.
Also, Roc rewrote its stdlib in Zig (originally was Rust), so Zig is obviously doing something right
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.
Unrelated question: what colorscheme is that?
Learning Haskell with aoc, was not prepared for the dynamic programming
28:00
I use Brave, btw
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.
I think you would love Swift
I really want to like zig but I just cant. There are some really cool features in here but there are also a ton of messy things that need to be fixed. Imports for example, I like the concept but writing const somename 50 times to properly avoid writing import.some.whatever everywhere just sucks. They need some glob import/namespace syntax. I don't want to have to alias everything but that is seemingly what you have to do with zig imports. It's like they saw some name conflict issues and overcorrected too much. At least in rust I can import everything in one single block and if I need to alias it I can just use the as keyword.
Compiler errors are also cryptic as hell, reminds me of clojure errors. I forgot a tuple in a log call in one of my advent solutions and rather than pointing to the line where this occurred, I got some vague fmt.zig error. You should never see tracebacks to a std library or a external library as the first line of an error; it's not helpful to me that fmt.zig 86:9 expected a tuple. In rust, this would mean that the std library itself is broken. It should have told me that on line 20 of my code I forgot a tuple.
Initializing complex types in zig is really annoying. Every single time I write the keyword undefined I feel like I'm doing something wrong. Maybe it's because I'm so used to null causing problems but it feels like a terrible addition to a language that's supposed to be null safe.
I really don't like var versus const. The way rust and ocaml do mutability makes the most sense. You start with immutable variables and you add a keyword if you want them to be mutable. Having to decide if the variable is constant or mutable with two different keywords is deceptively clunky. Also because the LSP doesn't tell you what the return type of a function is as far as mutability is concerned, oftentimes I find myself using var more than I feel like I should.
The try keyword is just another Band-Aid that doesn't really need to exist. I like the question mark in rust as a solution for unwrapping. Try just brings back so many bad memories from languages that use exceptions.
The compiler needs to be able to deduce more types than it currently can. That var x = 0; is invalid sucks. The compiler should be able to figure out what type of integer I want based on static analysis of the code. And even when it can't figure out what I want it should at least have some kind of default integer.
There are many other issues as well which I'm not going to go over. But yeah I'm probably going to stick with rust. Zig is supposedly simple but it's really not at the same time. Just because it's a small language doesn't mean it's actually conceptually simple.
I hate squirrelly brackets. I use an m4 macro to map { to start_seg and } to end_seg. This eliminates the need for Scottish brackets and makes code 5,217.8% more read-able.
11:55 That's actually something which i dislike about Rust since these kinds of unwrapping aren't grepable. (And because of that I write explicitly .unwrap()).
"just enforce curly braces" THANK YOU
Package managers are ok, but can lead to pathological situations where your code is like a fraction of the whole project because you use a lot of downloaded libs with their dependencies, and you only use a fraction of the downloaded libs themselves.
So package manager should not be provided by the language itself.
32:38
That's a good criticism
Programming languages are the new JS Framework. Lot’s of content for Fireship with a new language arising every week. 😂
THE LONG AWAITING
Does someone know where I can watch the Zig streams? He always goes live at the most inopportune moments.
He runs the channel TheVimeagen, where he uploads (all? most?) vods.
youtube.com/@TheVimeagen
you don't need {}'s in Java?
just rename the for as "from" and the reverse notation will be totally fine
for item in items {}
from (items) |item| {}