You should do a "Fireship 100 seconds video in 100 seconds" to explain what goes into you making these - for example, how much time do you spend with the language, researching, doing graphics, etc.
EXACTLY, its insane to see how much (deep) knowledge he has about all the topics he presents. I'm out here struggling with a single language my man is playing god on github.
Zig is awesome, but be aware it’s pre-1.0. Async and even a package manager are still in the works (well, re-implementation in case of async). But yeah, the language is small, and it really does integrate with C better than anything else, so it’s incredibly powerful. Oh, and it natively compiles to wasm, with the Zig compiler, so no more wasm tooling. It’s the bee’s knees.
Another neat thing with the allocator features is since you have to pass the allocator you can use the std library on bare metal. No need to implement arrays and hashmaps into your own code.
@@ko-Daegu are you asking why Uber uses it that way or why zig built that into the language? If the former, I don’t know maybe the way their structure is set up it benefited them. As for the latter there’s plenty of talks and articles on this, you just have to have the willingness to learn.
You really need to add the Rockstar language to your resume, so you can be a Rockstar programmer. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-gdSlcxxYAA8.html
Honestly I think what's the coolest about zig is the explicit control over pointers. One of the inconsistencies with c is that when you pass a int or float to a function it makes a copy. But if you want to pass an array you are just passing a pointer. In zig it's explicit if you pass an array [8]u8 that works the same as passing an int or a float you pass a copy of all 8 u8s. Same with custom types. And if you want to pass a pointer you can. This makes working with pointers most of the time effortless. Because your not pointlessly allocating something on to the heap just to keep reference to it. It helps keep things neat on the stack and in control
As a C and Rust developer, I appreciate the fact that Zig is stupid simple, yet powerful. It seems the perfect alternative to C for applications that don't require extensive memory safety.
In Zig, most of the memory safety is optional, for example, it does compile-time bounds checking, but you can compile with or without run-time bounds checking. I think you can also switch memory allocators to a slower implementation that does additional run-time checking, and switch back to the default allocator for production. The string functions in the Zig library are also designed to not have the common issues of the ones in the C library (not saying the Zig standard library is perfect yet, but they have a goal)
The whole point of comptime is to be used in combination with Zig's best feature: types are a first-class type. The `std.ArrayList` example code is _a comptime function_ that returns what is the equivalent of a template instantiation.
@@2004seraph Yeah! But not really scripts, just more Zig code, you can just look them up in the standard library (contrary to C++ where the standard library is a nightmare) and it's Zig all the way down.
1:06 Clarification: Zig can still cross compile with LLVM, the issue was just about not including those libraries by default in the Zig package, but you could still choose to depend on them if you want.
Zig could compile whole projects that consist only of C files (taking advantage of the Zig build features) and then you could also add Zig code to existing projects.
As with everything in this "C-meta-world", Zig will replace very small parts of it first, using the LLVM to compile into a bigger environment... then, when new bigger open-source low-level projects come out, some open-minded person, followed by other open-minded teams, might see the advantages of Zig over C (which, honestly for me, are clear on certain scenarios), and chose it. As we all know, everything in the IT world comes down to "what's the best tool to deal with this problem?" and "do we have the expertise needed with this tool to really deal with this problem?" - when it's a "yes/yes", here we go. I really don't know why I expressed my whole thought here, but I'm in the same boat as you: Zig has pretty much everything I've ever wanted on a low-level programming language (just as C for the C creators and enthusiasts back in the day), I'm really endorsing it by using it on personal projects, taking it to the company I work at, taking it to my own company, and teaching it to people around me, and I hope to see it grown in the future (: [also I really dig the name, since my nickname is Zeca, lol]
Idk, Go works for a very specific set of web-facing applications that would otherwise be C. I appreciate, at least, that Rob Pike tried to make it into something that "fit in one person's head," something designed-by-committee "systems" langs like C++, Ada, Rust, etc. could not be bothered to try. But yeah, Zig is the best "better C" so far.
Zig is the first language that I have seen in decades that has hope for being a true successor to C, both technically and in spirit. C is and has been my most beloved language to use, but Zig is looking to be sooooo good. It really does seem to have pulled off being C without the legacy crud and hidden gotchas. My biggest fear for it, and have seen with other projects, is that the developers won't know when to stop adding features (yes, this is a direct insult to C++ and ready to be towards Rust). Go has its own purpose and priorities, but this is one area that they have pulled off perfectly: anyone with programming experience can learn the language enough to be halfway-competent with it in an afternoon. Once the addition of async is complete and part of the the stable language spec, I hope development slows down on feature additions, and goes the route of "quality over quantity".
I agree, I think part of the success is the developer(s) laser-focus on deleting anything that is not strictly required, and instead improve the existing features to make the new feature unnecessary. Most features of other language can be replaced with the Zig "comptime" feature, and for example the ability to use types as a parameter.
@@alvarohigino I don't know, I personally cannot name any remotely popular language that has grown near as slow. C17 didn't add any language features. C11 was pretty much just threads. After that we have to go back to C99, which was probably the biggest change in recent history, with revolutionary concepts like stdint.h, booleans, and inline comments. If memory serves it also added variodic/inline functions at that point, which is a rather large change for a language like C, though would only bump a minor revision in any other. Before that was the Lord's version: Holy C89, so that is over 3 decades where I can list 90% of the of "bloat" in a brief YT comment from memory. Tooling has increased by leaps and bounds, but that isn't the language, so not really a fair metric.
Zig is really cool. Rust does not try to be a C replacement. Instead, it offers a wholly new way of doing things from the ground up with focuses on memory safety in application code. Zig offers you an actual, drop-in replacement for C that offers better _tools_ for safety than C, without zealously enforcing this safety on you the way Rust does. I use Rust for all of my new personal projects, and have even started some greenfield projects at work in it. I view Rust as the ultimate .language for writing safe, reliable _applications_. Zig is what I would use today if I wanted to build my own kernel module.
@@kianureeves2519 that's a simple question with a complicated answer. Put simply: yes. And python, and C#, and Go, and Haskell and Nim and and and... Less simply: learn to program, don't learn a language. You can choose a language you're comfortable, build some software with it, and that will teach you how to program. Once you know "how to program", "learning" new languages is as simple as reading their "getting started" docs and then referencing specific things you don't know or understand. I haven't "learned" zig, but I can write some non-trivial programs in it despite that. :D
Rust isn't meant to be a C replacement. It's meant to be a C++ replacement. Big difference. Rust is far more complicated than languages like Zig, C, or Odin (another C replacement language), just like how C++ is far more complicated than C.
Awesome comparison. It makes me wonder how long Zig will live though. Rust is very quickly moving into every software space, I even use it on bare-metal no_std now with Embassy, and it's a dream to work with. As more and more C APIs are wrapped in Rust bindings the use case for Zig diminishes. Though it won't disappear completely any time soon because C will likely outlive the heat-death of the universe.
@@godnyx117 the hard part is the quasi-"natural monopoly" that C has. There are a million libraries, projects, examples, and an ecosystem already out there... not to mention a plethora of teaching materials, books, and online courses. If something is worthwhile, it gains traction and will take off the way Rust or Go has. Its not guaranteed, but if it finds a niche or can service a specific set of users (I'm really curious how Rust will affect AAA game dev in the coming years), then it'll sustain long term.
@@atkascha That's part of the problem. I believe (tho of course it's just a theory) that if a language releases that (almost) EVERYONE will like, it will truly take over C. Funny enough, I also develop my own language. I will not market it as a "better C" however. I think this will do more harm than good.
Ooo, the exclamation and the comptime keywords are interesting. I've not tried it yet, but you've also made me remember their neat option syntax, for both type declaration and unwrapping. I wish rust used ! and ? for error and option declaration/unwrapping and found something else for macros.
@@standinonstilts I could be wrong, but I don't think so, you can unwrap results while passing the error up on fail, but can still be annoying with different error types (at least I don't know a nice way to quickly union, but there's probably some derive crate). Correction: it does work on options, but it also returns early on the unsuccessful path, I wish there was a shorthand for ordinary unwraps/expects. And also for type definitions, pattern matching on a ?u8 rather than Some(u8) would be nicer.
@@johanngambolputty5351 I think let Some() does what you're looking for, although it is a bit more verbose. It would be nice for the ? operator to infer that with options.
@@johanngambolputty5351 In rust the ? is for error propagation (the same as Zig's try keyword shown in the video). And the ! is basically either Result or Option. Plus another note, ideally you should never use unwrap() or expect() in a serious program, which is why making shorthands for those doesn't really make sense.
@@mr.vladislav5746 operators should not be used for encapsulating business logic. overloading almost always results in hiding functionality that could've been made explicit, and with that, the code more readable.
@ So if I'm making a vector datatype, I can't make the + add two equal-dimension vectors and * be the dot product of them? Whenever anyone wants to do operator overloading it's probably because it makes sense in that scenario? ¯\_(ツ)_/¯
Год назад
@@mr.vladislav5746 that's a valid usecase, because (mostly) everyone knows what the sum of two vectors is supposed to be. Consider two business objects which is foreign to the developer, where the sum is not immediately apparent. People shouldn't look up how symbols supposed to work.
This seems pretty interesting. I guess with the comptime keyword, you can basically get all the meta-programming benefits that C++ templates provide, but more readable and distinguishable from Generics in other programming languages.
Nix would be interesting to see. A functional programming language for a cross platform package manager that creates the EXCACT same environment every time
I really REALLY wanted to like Nix, but it's really difficult to use + poorly documented. Ian Henry's blog post series "How to Learn Nix" conveys a lot of the frustrations/confusions I had with the tool.
The exclamation mark for return type or error is such a neat concept. It boggles my mind how a language like C#, which puts such a strong emphasis on type safety, doesn't even give you type safe control flow. So many versions of the supposedly enterprise grade language and somehow everyone is fine with code that can blow up in your face on every line. Even TypeScript is better at this point because type inference can actually analyze control flow of your code and add undefined to the return type.
@@vulpo Well I don’t know Zig but I assume the string is just array of chars underneath, so it’s basically casting more specific type moniker to more generic, which is perfectly safe
@@pfili9306 I am not familiar with Zig either, so maybe there are aspects of this that I don't understand. However, he defined the field, name, as an array of u8 which, according to his earlier example, is an 8-bit unsigned integer. Although a String can be viewed underneath as an array of 8-bit unsigned integers, so can all of heap, but that isn't necessarily a very type-safe interpretation of it. Type safety is supposed to be about ensuring that something that is one specific type, meant to be used with one specific set of methods and functions, is never mistaken for another type and used with another set of methods and functions that weren't designed for it. For example, if you want to sort something (i.e., a file) by a particular field, you would want to ensure that it sorted according to the type of data that is stored in the field: alphabetically if the field is a String; numerically if it is an integer; chronologically if it is a date. If you sorted a list of files by their last-modified date, but it sorted them numerically instead, it could have dire repercussions. Likewise if you have field that is supposed to be a String, like "name," then you ought not be allowed to assign a date, or an integer to it, or to assign the name to a date, even if they could all be interpreted as arrays of 8-bit unsigned integers underneath. So if you assign a String constant to an array of integers it ought to generate a compiler error. Then again, maybe this would actually have generated a compiler error.
@@vulpo Sure it is, strings are just arrays of integers. In Zig the type of a string literal is *const [_:0]u8 (pointer to a null-terminated array of 8 bit integers encoding the string as UTF-8) which can safely coerce to a slice type like []const u8 like in the video. Zig is very strictly typed and only implicit coercion that are safe like that are allowed, anything else requires an explicit cast.
@@GreyDeathVaccine Yeah, I've seen that too. Although "scam" would be a really ugly word to fit here. I recall once the Ocaml author created an issue in the V repository and the creator of the V lang's response was quite hilarious. The language promises way too much more than it actually has.
I watch this guys videos every day despite having no programing experience/knowledge, I have no idea what he is talking about 98% of the time. but he is simply so entertaining I don't care. even if this mf was speaking in sandscript I would still watch his video's.
VHDL is NOT software programming. You are literally defining a digital logic circuits via a program. It's NOT software that runs on a computer it is a circuit. Get that clear.
@@carldrogo9492 I did not say it is... I literally extended the shortcut to be clear about that. But's still a big term in computer science, so it's definitely worth the attention.
@@carldrogo9492yes, it's hardware programming. But I ever read that if we run the HDL inside FPGA, it's worked same as software programming since it's manipulating the state of combinational unit (logic gate unit). Unless if the HDL is running on ASIC which directly creating the logic gate unit. So, FPGA is development staging while ASIC is production.
Really great short summary Jeff - cheers :) Zig is great, and is no doubt Blazingly Fast!! But by swapping out allocators, do you need to maintain separate source code branches (or even repos) for each architecture you target? If so there's a crying need for a CI tooling step to swap out those allocators automatically. This is maybe just a criticism of how Zig sells itself, but you say in the video (as the Zig evangelists also do, loudly and often) "No Hidden Control flow". But then 70 seconds later you say "the defer keyword... ...will automatically de-initialise the list when it goes out of scope". Are allocators forbidden from containing any other control or clean up logic? It's making its Rust style scope memory deallocation explicitly opt-in, instead of opt-out (or even mandatory), which is really good. Is this approach nonetheless a big improvement on C, which has far more potential foot guns? The big question really is, when to use Zig over Rust, and what does it offer over it, other than a much lighter, faster (but far less proactively helpful) compiler?
> But by swapping out allocators, do you need to maintain separate source code branches (or even repos) for each architecture you target? Nope, you can use comptime switches / if expressions to change parts of the code based on the target.
Defer is not hidden control flow. It is explicit that the deinit function will run at the end of scope, whereas C++ has destructors and rust has the drop trait (I think that's what it's called?) which will run without you knowing.
Zig isn't "far less helpful". It's like 95% of the way to rust and improving static analysis all the time. One massive benefit to zig is that you aren't required to "just know" 50 different methods and what their behaviour is and why you should use a specific pattern just to be able to return maybes. And that's just returning values! You can know everything about zig just it what it takes for Option and Result documentation. To say that Rust is "bloated" is a massive understatement. Rust might well be the most complex language ever, outdoing even C++. You also don't need to learn 3 distinct Turing complete languages (rust, macros, generics) just to use the language.
I predict that Zig will become a hackers' favorite in a couple years. Direct low level memory control, more robust than C, and, most importantly, new. New compilers are known to produce binaries that are hard to detect to antiviruses because of unregistered patterns in the binary.
@@drewsarkisian9375 well, its true. zig language is not stable. its syntax and std library API are keep on changing from time to time if you want to run on the zig master branch.
In every release notes and in a couple places on the website they specifically warn that Zig is not mature yet and things will break between releases until it reaches 1.0.
Everytime I see a new language like Zig I wonder why was created in first place, instead on focusing efforts on making existing more popular alternatives (like Rust) to provide the same advantages and differential features.
@@Elefantoche There's an article about that on the website, search for "Why Zig When There is Already C++, D, and Rust?". Like many other languages (even Rust) it was born due to frustration with existing tools and wanting to try a different approach
Can someone please direct me where I can learn to make that cool 3D effect Fireships every 100s video starts? Is it made in Blender? Or in AAEffects? Or both .. or something else? I need to learn it :D
I think he has mentioned in a video how he does it, but I wasn't able to find it. The best one I could find was this: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-N6-Q2dgodLs.html But there be basically only mentions that he use Premiere and After Effect.
I tried to like Zig, but in its current state, I can't. Zig is another one of those languages that changes already established syntax from prior languages for no real reason other than to "be different." It doesn't make coding easier or more intuitive. One of the tutorials uses new features from the unstable 0.11.0 version instead of the stable 0.10.1 version. Granted, this isn't the fault of the language, but it did trip me up when learning. Zig also has some annoying quirks. For example, this code won't compile as of 0.10.1: const expect = @import("std").testing.expect; fn is_bit_set(x: u64, n: u6) bool { return x & (1
That code will likely never compile as-is, Zig is a strictly typed language and you're just using it wrong. The type of 1 is comptime_int. You cannot do runtime bit shifts on comptime integers like that because well, that is not how they are meant to be used (1
@@dan203 Well some of the most important things it has is strict typing (C/C++ are weakly typed which causes many bugs), automatic checks in debug mode for detectable UB (integer overflows, pointer alignment cast violations, out of bounds reads on slices, etc), a first class type system to facilitate generics (something C sorely lacks and something C++ overcomplicates), compile time programming (again something C++ has via metaprogramming and constexpr to a degree but terribly overcomplicated), a unified build system (no more worrying about if a project supports CMake or your build system of choice, and the build system is "scripted" in Zig so it's quite powerful), and unlike a lot of other new languages Zig focuses a lot on C interop so it has a lot of tools to make using C libraries as practical as possible so it's not totally dead on arrival ecosystem wise. There's more stuff too of course, enumerating it all would take forever but point is there's a lot of improvements even beyond those more major ones.
Just tell me that they didn't say Zig was a C killer. Edit: I just realized that this video was uploaded like 3 minutes ago... This is the earliest I've ever been for everything.
