Except that JavaScript traditionally *was* a really bare bones language. That's the entire reason why things like 8 billion npm packages per project and `left-pad` are jokes that ring true-cuz JavaScript used to come with an insanely minimal internal API, and people had to keep writing the same basic utility functions for each new project. But yeah, you're right. C isn't bloated. Its compiler does do some truly magical shit, sometimes, though-especially w/r/t undefined behavior
JS is not bloated today. You are confusing libraries / frameworks with the language. Look at Java, or worse, PHP (yuk) with thousands of standard methods.
When he said c is bloated because it links in standard library, then said zig does the same. By the time it gets to full release, the standard library will very likely be much bigger than it is now. The same as c standard lib is much bigger now than it used to be.
I was on there discord for a while, they are a good community and try their best to help anyone that ask. I’m personally waiting for 1.0 but is good that you give it a try!
Exciting times we stand in where there are some genuine alternatives to C. They don't have the same pedigree and standing at crossroads is never fun but I am genuinely excited to see where this goes.
WTF are you talking about. Have you slept since C99? Is here some mass delusion going on? There are enough "alternatives" through time and space already here. Which doesn't impress systems or embedded programmers very much ... because THEY KNOW THEIR BUSINESS and don't need fancy BS, but RESULTS. Sorry for the arrogant reply, which you deserved (you are obviously blind???). At least we share the love for the Mechwarrior-Universe:) But not for the history (and facts) about BCPL and Algol based computer programming languages ... which is a little bit sad.
True, and I guess languages like Zig, Rust, Go or Carbon are just temporary experiments. Currently we are only finding out how we can overcome design flaws of C/C++, and how to build a language that is (thread) safe and bounds checked, of consistent syntax, easy to parse, read and learn and which brings package management, testing and so forth with it. But I guess there will come even more languages after them, that will combine the individual strenghts of today's new languages, each of which will probably hit its limit at a certain point of complexity we don't know yet.
@You Tube C isn't going anywhere anytime soon, but especially as far as new code goes, it's getting less and less common to write it in C. There will be a time where jobs involving C will be almost entirely maintaining legacy code -- similar to COBOL today. C is no longer the only realistic option for the embedded space, and some new low-level languages offer just as much freedom with safer code, better syntax and a lot of the time, faster runtime. Linux will be one of few reasons for anyone to write C in coming decades.
@@deNudge Rust solves the problems that C even doesn't try to solve, namely: - safe low level memory access - user defined safe abstractions - type safe error handling - safe multithreading and async - complete CI and development toolchain - cross-platform and C-interop ^^^ all this at the same time. So Rust is the unique technology right now, the only serious problem it has is the steep learning curve, because safety cannot be simple in principle.
I like that you are covering zig, but you didn't mention some of best selling points: comptime, the build system, the interoperability with existing c code, and error handling.
Because he does not seem that great of a low level programmer to begin with. So of course he won't go into the kind of depth, low level programmers would expect from him. Yet another programming channel that makes subpar content.
@@encapsulatio Make your own video's if you're that good. Also c-interoperability and error handling are not strong points compared to Rust, so I get why he didn't mention those.
3:11 "All your (code)base are belong to us" I love that reference to the game Zero Wing, in which the space fighter craft you control is called... ZIG.
I feel like out of all these new system languages, Zig is the closest in spirit to the good old C, but with some reasonable modernizations. It doesn't try to revolutionize too much about the way people program, like Rust does, instead it sticks to the good old structural, imperative programming with manual memory management, while bringing a lot of convinient features. I think this might be the future language for a lot of embedded development and quite possibly the best alternative to C for kernel development.
@@ygypt I see your point. In my experience, Rust gets really awkward when you need to do a lot of unsafe stuff. And you need to do a lot of unsafe stuff in kernel development. I know it's possible to use Rust to create a kernel, but despite my love for that language, Zig would probably be my choice for this sort of thing. Although, all my kernel development experience is in C, which is closer to Zig, so maybe I'm biased a bit.
As a complex language Rust also has BIG drawbacks for Kernel development. Linux kernel team is very careful about Rust for this very reason. Kernels need simple, minimalist language to avoid being clutered later.@@ygypt
I love the simplicity of C, and the fact that Rust is so complex is a deal-breaker to me. Zig on the other hand might be something worth learning, as its simple and avoids making binaries that are massive in size. Its almost perfect for embedded.
C is my go-to, but I want something with some modern conveniences: no header files, better types, package management. Rust is complex, but I do like the way you handle iterators with high-order functions. I've been trying to learn some Zig as it says "A Simple Language" on the tin. It isn't simple, and there isn't much in the way of learning the idiomatic way to do things. I think I'll hold off for a while or just try banging my head against Rust some more, at least the compiler messages are understandable.
Zig the language is cool. But I find its build system to be really annoying. But maybe that’s because I’m used to cargo and cmake? Dunno. But I wasn’t a fan.
Rust complex? Not complex for me. Im not the best programmer out there but once you get the handle of the borrowing system and some smart pointers its fairly easy to do stuff. What is true is that it's annoying the fact that you have the compiler all the time complaining about stuff, but for me is a love hate relationship. And although I hate the compiler sometimes, in the end the truth is I love Rust.
Yeah, Zig’s great usually. It just shows it’s pre 1.0 status a good bit (I’ve reported a few internal compiler errors and dealt with some annoying problems while writing my Scheme implementation).
Definitely still needs work, but each patch it gets a little (or a lot) better. I'm just glad it isn't one of those languages that rushes 1.0, then also has to rush a 2.0 and 3.0 to clean up
I tried it and really liked how it felt like c but better. Also I was blown away by the comptime feature and how it's used. And meta programmjng is nice too
I don't fanboy over much but Zig is pretty exciting. After weeks of frustration with debugging C, dealing with UB, etc. I thought that was just a part of lower-level programming. Coming from Python and Go, Zig was a little frustrating at first but I literally had it down in a couple days.
@@curio78 D doesn't catch on because it kept too many c++isms and tries to be everything for everyone causing it to suck for many of the same reasons cpp does. people don't want another cpp or yet another foray into failed '80s-'90s OO and RAII ideas, they want C done right now that we have 50+ years of hindsight. Rust was able to gain traction because it's "different enough" from cpp and provides a big idea feature (borrow checker) that appeals to the new breed of safe-space fisher-price programmers who have graduated from webdev kindergarten and want to do big-boy programming but are still scared of memory for some reason.
While it would probably be my perfect language in another world, many of the things it tries to do are just done better by other languages. Nim in particular comes to mind, since I feel it does things like c interop and compile-time evaluation much better, though it has much more hidden control flow and is very heavy on macros. Really hope Zig matures though, it absolutely has a place in this world.
@@morgan0 Well nim is relatively new compared to C or C++ which made me shout at the video author when he only mentioned them with Rust and, one language that may or may not exist in the future??? But also, Nim is also older then Rust, so not sure how long that history is, so the point stands. My first language was older then both me and Nim (Ruby). So yeah, no this is just semantics.
It is the Zig programmer's responsibility to ensure that a pointer is not accessed when the memory pointed to is no longer available. Note that a slice is a form of pointer, in that it references other memory. Cannot compare with rust
I sorta wish Zig stopped at being C's new Cargo utility, maybe bake in some safety passes for C. Language is great, but we're reaching the point where there's a new language every 3 months again and I'd rather stop learning syntax and do some real work
you don't have to learn zig if your current set of languages work well for you, doesn't mean others who haven't already committed to C or Rust or whatever shouldn't have another possibly even better option to choose from. New stuff can be useless/useful for each person, and more new stuff in the software space at least is generally always good. What is bad is potentially misleading marketing around said new stuff.
@@sadhlife it's more a concern of fracturing communities for me which we saw in the 80's-90's when lexx/bison made it easy to create languages (as LLVM does today) We see the same thing in rust game dev where there are 50 engines and no games being developed. Research and learning are great but if all we wanna do is fracture into another language instead of solving issues with what we have then it'll never end. Another eg: Someone is going to get mad at zig for not doing what they like so they make Zag, and then zig corrects those issues and now we have two communities building two sets of tools/libs.
I forgot about this language. It's really interesting. As someone who has an immense dislike for C++ and loves C, Rust and Go, I find Zig really interesting.
@@_slier I don't know about C or Zig, but Jai won't "smoke" Rust or Go "out of the water" because it's not intended to replace them. They're each intended to do different things, and differently.
I'm skeptical about languages that try to avoid strong abstractions, macros and reflection. In the end programmers will always want to do metaprogramming. If you don't think about how that will fit into your language from the start, then it probably won't fit well and you will end up with something like tools that half-arse-parse your language and generate code or abusing other features (like c++ template programming).
@@maninalift Yes, definitely yes. I just think that reflection is to be avoided at all times at all cost. It's not something I can imagine anyone to be happy about.
I recommend that people start with C BECAUSE you need to be aware of how memory works. Avoiding it because beginner developers might write unsafe code just delays the inevitablity of using a linter to identify where there's a security issue.
I used zig after using Rust for years and the thing that made me stop learning zig was the error messages. I found them really unhelpful. I understand that making good error messages is really hard but I think that it is the most important part of any new language. I also think it is very important when considering what language to learn first.
"One level above assembly, one level below c" is perhaps the strangest way I've seen Zig described to date. Apparently not loading a std library puts it below C (is C a level below itself when you don't load std library?), but what puts it above assembly? It's abstracted over the hardware, but no more or less than C is? What does it all mean!? :P But Zig is pretty dope, so onward!
Imo he misses the mark here. I didn't watch it all but it uses llvm so it translates to a virtual machine not assembly. So that's your one level above assembly. His statement one level below c is just flat out wrong. Any language like c that'll let you sneak assembly instructions into it is pretty damned low level. Regarding bloat you can address that in c real easy so that statement is complete nonsense.
I'd love to know your thoughts on Odin too. Both Zig and Odin set off with the same goal, a better C alternative systems language, without trying to be a memory safe language like Rust. But they both have entirely different philosophies. I explored both of them a little bit a while ago, now sorta settled in with Odin. This may just be my personal taste, but I'm enjoying Odin a lot more than Zig, especially for game programming.
@@quelkun Odin is a lot more simpler, and feels like it's more specialized for game dev and graphical programming. Zig shines more on the C interop and its drop in compiler. Ultimately, it's just a personal taste. There's nothing more to it. You gotta try both to know more about both.
Surprisingly one of the most unique features of Zig is the lack of "bloatness" compared to other languages. You can make a very tiny, portable, statically linked executable that does just what's meant to do and you don't have to do dirty hacks (like unsafe or nostdlib) just for it to be small or fast. Rust and C++ can't do that because of their huge standard libraries embedded in every application.
Why is the full library included in final compile? the compiler should notice that calls are not made to these functions and not included it. I use IAR Workbench free limited and pretty sure it does just that.
Rust also has integrated tests (even runs code snippets in doc comments when testing) and Rust also can do cross compilation. However, it has certain cross compilation limits. It is really difficult to cross compile to macOS in general because of all the macOS standard libraries you have to link and how to get them, but I heard Zig is doing that for you (increasing the download size of Zig, of course). So Zig is better in cross compilation, but if all you do is to cross compile to either other Linux hardware versions or to Windows then Rust (and C/C++) can do it easily.
To be honest I kindof hope Carbon fails. Difficult to describe it, it's just a lot of small things that don't fit right for me, and make me think it's not going to be good for us but will rather increase fragmentation without close to enough payoff. As I said in my other comment Zig is nice and I believe and hope it has a niche.
Yeah, given the reliance on interoperating with all of C++ and it being a Google language I can only see it just having the C++ problem relative to C++ (being locked to whatever can work with it to avoid foreign interop limitations).
I've never heard a *good* reason for Carbon to be developed. We already have D, and it's already in use. Good enough for me! And we also have Crystal, Zig (work in progress but already practical), Odin (maybe only for physicists and 3D graphics geeks), Vala, Rust and others providing more or less all the good features of C++ but safer, incorporating other modern ideas, and cleaner code. What can Carbon provide to be better then any of these languages?
As a javascript soy dev and someone who is learning rust, I'd really like to see where V language takes us with it's automatic memory management without garbage collection.
Neither C nor C++ require stlib/run-time, not even a dynamic memory allocation. You can program 8-bit AVRs with 2 kB of RAM (or less) without an OS of any kind in C or C++.
lighter than C ? I wrote an empty main.zig and built it. the statically linked executable size is 728k running through `nm` shows 860 symbols. hardly zero runtime overhead.
Other things aside, Zig is a lot older than Carbon. To me it's a level above C. C is more like assembly. I'm finding Zig harder to learn than C but easier than Rust. Zig still has a runtime, still has code that runs before your main(). I believe you can also build without that stuff like you can in C and Rust for when you want to write close to the metal.
@@sprytnychomikOnly if you’re targeting bare metal or DOS. If you’re targeting any other OS you have some setup code that runs before main(). Library loading, calling convention setup, and other stuff gets handled by that code.
I tried rust, then tried zig. I found zig to be more verbose and even more complicated. Might give it another try. Note, I have not done or liked C. So that might be a reason.
Yeah. Weird statement. C need not do anything at all before calling your main. It not need link in a ytbing. The Windows PE format will add stuff to your binary, but that is Windows and has zilch to do with C.
Hmm, at least good to know about it. But so many new programming languages are continuously popping up, that my current choice isto look at what is currently worth learning when it comes to the combination of popularity and maturity of the language. And I believe Rust is just reaching the point where it is finally really taking over the world (it has started to the enter the Linux kernel). So Rust is what I am currently very actively learning (but yep I cannot deny that it's definitely not my first language that I am learning, being a developer in many languages for about 20 years, I can see that the difficulty and learning curve of Rust can be a drawback to the newbies). When you have already seen everything about C#, a ton of C and C++ and also Java and JS, things are very different.
A drawback is also a benefit, keeps out noobs from competing for the same projects as you. Speaking as a retired non-coder who is also learning Rust (I know C, C++, Pascal, C#, Silverlight, ASP and SQL)
Rust, Zig, and Elixir are my main programming languages. Rust and Elixir for the job market. Zig for my personal operating system research. Of course, I first try to build a prototype in Rust, then port it to Zig in order to pad my resume/github.
I still don't see a place for a new language like C was in 1967, suitable for large-scale projects. There's a reason why C has become what it has become, and if Zig were to become a mature, production-ready project, they would have to develop a bunch of preprocessors, macros and whatever tools, such that they are indistinguishable from C, so what's the point?
I heard about this language for the first time about a week ago on Dave's Garage where it won the Code Drag Race (prime number sieve) against something like 100 other languages. It won by a massive margin.
From what I've seen that was largely because they cheated and did a lot of stuff during compile time instead of actually having the Zig program calculate it at run time. You really can't beat C and Rust by that much without cheating, because both are extremely close to the metal. It was basically similar to doing a constexpr in C++.
A use case I saw mentioned previously is that zig supposedly is a very good compiler of already existing c code. Haven’t looked into it so I could be way off, but that alone could make it worth while to check it out.
@@mithrandirthegrey7644 oof. Every C code base ever laughing the corner with all the evil macros. Personally I can't do rust but zig looks interesting, however I think I'll hold off till a 1.0.0 release
Yeah, Zig does embedded/baremetal really well. You can't really compare it to Rust in this space as rust isn't viable for baremetal with its implicit allocations and non-portable standard library, both of which work great in Zig.
Zig has an edge in being easier to deploy on embedded, and yeah allocations are more explicit, and Rusts standard library is less portable. Still though Zig is not at all as save as Rust. I don't know how LLL didn't manage to segfault zig, its not that difficult, especially if you don't use a "safe" allocator. Zig will have the edge once it's mature, but id say it's a lot closer than you think it is, and big projects should probably prefer the higher memory safety guarantees Rust makes, IoT has a lot of safety issues currently.
@@9SMTM6 Yes segfaulting Zig is not hard, but at least you have to explicitly shoot yourself in the foot to do that. There is no unsafe marking in zig, but I don't see that as an issue. The safety gurantees of rust really doesn't mean anything when you're running on baremetal though, as for example, two completely different regions of memory could reference the same DRAM, writing to an MMIO register a tiny bit wrong could just make your entire program invalid, there are DMA engines that have way higher privileges than any piece of your code etc. There is not much that "Rust safety" can do on baremetal, or to prevent logic bugs on any platform.
Should I start my programming with zig? Just like people say tackle the hardest then else is easy lol Edit : thanks for everyone in comments for suggestions :)
I say choose what sounds most interesting to you. I haven't used Zig, but it sounds like a great place to start, especially compared to languages like C++ or Rust
If you will choose C, I recommend to start with the "Beej's Guide to C". Today I probably would choose Go (as it's stable enough + there is a lot of learning material around). Then I would switch to Zig:)
To me, Zig *feels* higher level than C(it's far easier to program in), but its actually able to do a lot more than C can, making it lower-level. I've seen a few examples of kernels written entirely in Zig, without any handwritten assembly code. You simply can't write a kernel in C without handwriting at least a *few* lines of assembly, and a kernel in C++ requires even more non-C++ work to do. That's why he says its lower-level than C; Zig being advertised as a C alternative doesn't change the fact that Zig *is* lower level than C.
I've been putting off learning C in depth for a while because of the crazy errors it gives. I hope this language doesn't make you suffer for just trying to format strings.
00:02:10 ... We avoid the C bloat that comes from being forced to load the standard library.... By being forced to load the Zig library... then what is the difference? Then it is just a case of the standard library being written well, which is not a point for or against Zig...
I think you have to be careful about mentioning the standard library with C/C++. If you write Win32 code and use that API and the provided functionality, you don't need the standard library. Also the bootstrap code that you need before entering main/WinMain is really an operating system thing rather than a language thing. For some of the 4k demos I do, I've got my own startup code which is just the bare minimum of what you need to start a PE executable, which is greatly simplified if you understand what the startup code does and work without object orientation.
I think you forgot the most important part of zig unless I missed hearing you go over it. Zig has C interop as a first class citizen, so any c headers etc can be imported in zig. And like 95% of all existing low level code is c or c++ and has documented c headers, so that makes porting to zig 10009834892348 times easier than porting to rust. The real fit for this language is anyone that needs a system language that is easy to pick up because they already know some C++ (basic skills) and know Java or C# etc. Zig is way easier to pick up coming from an experienced dev view point than rust.
But a simple "Hello World" program compiles to a 4MB executable. I am looking for a way to program "hello world" really small, as in a maybe a 100 bytes or so. Even in assembly, which I am just trying to lear, it takes almost a kilobyte and that is after using "strip". But both ld and gcc produce executables way bigger.
It's still in beta and after trying to write game engine on top of SDL2 with Zig bindings and receiving illegal instructions error I gave up. It is still not mature enough, remember that.
I still don't see any sense of language like Zig. For teaching purposes, in first lessons you can use Python-like or Java-like subset of Rust, e.g. ignore advanced features like custom generics or "safe" memory management, and instead use e.g. Arc, which is essentially counting garbage collector (as the one in Python). That's how C++ (even more complex than Rust in some aspects) was taught decades ago. The best code (here: programming language) is the one that doesn't have to exist (and be bugfixed, maintained, etc).
The dependencies mess, macro, hidden code .etc… just because we need it, not a “defect” of any language. A new “simple” language sounds so naive to me because that not a problem to solve.
I'm currently learning Rust on the side while I learn Java... probably not the best choice, but it kind of helps me understand how things can be done differently in another programming language.
Hm.... you repeatedly mention "libc" as an example of a library that makes a C program "bloated" and may do stuff I'm not aware of.... but the first line in the example Zig program is an import of the Zig standard library. How is that any different from using the C standard library? How do I know what the Zig standard library does?
I currently can choose a language for a side project, a simple file server called JAM FS (Just A Messy FileServer). I want to use a new language, either Zig or Rust, booth are fast and get the job done.
Idk, i really, and i mean REALLY like rust macros. You can recursively expand them in your editor with rust-analyzer so to me theres barely any hidden code. I suppose if you dislike macros zig could be useful but stuff like sqlx query macros that validate types for your queries at compile time (you can even do it without a dev database now using a optional feature) are really fucking neat.
idk about macro, but if you want to do something in compile time this can be easily done with comptime and std.meta. For example you can look at case study section of comptime in zig's doc
As a numerics engineer even though this is a small community I could really see it adapted for very fast running simulation code - provided there will be libraries for it. Rust just feels too complicated for someone that wants to run some code that for the most part isn't really touched by anoyne. On the other hand though, people would also still use like Fortran66 and have all strange variable names...
you should do a video on nim. it’s on its second major version iirc, and has been out for a while and does the same sorta thing (except there’s a pretty powerful macro system, which has been used to make a python compiler and a cli interface generator among many many many things)
Zig is the language for me after I learn how to code in Go. Go is an easier transition to pointers coming from JS than Zig is. After I get comfortable in Go, maybe I’ll Zig more of a go (no pun intended). Zig just feels like too much of a leap for me right now when Go pointers/references/strictor than TS types are still tripping me up. I’m very experienced with JS and TS though.
Precisely. It made me think about this video by Adrian's Digital Basement where he tests Windows NT 4.0 on a MIPS R4600-based PC: th-cam.com/video/1n0kWWqQ0D8/w-d-xo.html
Since you've peeped Zig, have a look at Nim too -- a more mature, but less low-level systems language that compiles to C, C++, Obj-C (and somehow JS). Has a bunch of _wacky_ features, like homoiconicity.
I'm old-school (not just old!). I believe that learning C as your first language is a good start. If you really learn to master it, programming in Rust, PHP, Java and Zig will be easy.
I found it really interesting how you recommended to write something simple like a web server to test drive a new programming language. I guess it makes sense for a person who's written a million web servers in the past, but to me this sounds like a daunting and an extremely boring task. Why would I write a web server for a test drive when I could write a cool simulation? Or a raytracer? Or a physics engine? Or a game? But this just really shows that to each their own.
4:43 i would disagree with that statement. We learn by making mistakes. The more we fuck up, the better we get. And C enables us to write unsafe code, from which we can learn. As you say at 6:50 "You have to know what things are unsafe, to make things safer".
I'm old enough to have been programming long before C was released (anyone else remember City and Guilds mnemonic code?) And there has hardly been a time since when people were talking about some language that was about to displace C. I'm not going to hold my breath for any of the current contenders.
Zig will come into picture for me when APIs of Azure, Amazon and Datadog support it and there is a decent IDE and ecosystem with tons of libraries are available so I don't have to reinvent the wheel again
Haven't tried it, but from just looking at the examples, I like the syntax a lot. The syntax looks like a normal C-style language with less of they uglyness of C. It looks a bit like if JavaScript/Typescript was turned into a systems language.
Ouf, I'm not sur that I like Zig at all because of the absence of macro. Macros can be used to to gain performance in certain case in critical components depending on some hardware configurations. It would be crazy not not use a preprocessor at this point 😅
comptime enables you to do most things that macros are used for, but it gets handled safely. as a primitive example, you aren't forced in zig to use void pointers for ADT keys/values/elements. You use comptime and pass the type in, so you get the compile time checks and the performance benefits of having typed containers. As an added benefit, comptime gives you powerful reflection capabilities as well, making lots of things essentially trivial in zig that would be complex or impossible in C macros (see MultiArrayList for example).
This is not a good review in my opinion as he's conflating run time size with level of abstraction (the latter is independent of the former). The standard library (most of the run time) is not part of the language. It is very useful so you don't have to implement your own system operational code such as allocators, io etc. But that makes it a useful UTILITY not part of the language! For example, if you're developing for small microcontrollers you're not likely to use the standard libraries at all - you write your own allocators, io etc. The language standard (compiler implementation) is not the same as the standard library (standard utilities). Zig is a young language and it's standard library will increase with time as the language matures. But again this does not affect its level of abstraction.
I've been writing C in a while and macros are a very handy thing when you want to write the same code in multiple places and can't afford the time cost to call a function (a function call is slower than comparing two numbers and that is what actually stings in the qsort function performance, unlike in the case of C++ sort which has the code of the < operator injected in its own to avoid function calls while sorting). Not to mention one can write a macro to generate a funcrion. The only situations where functions are better than macros are recusivity (impossible with macros unless you build your own stack) and when you use 3rd party tools to analise performance (at least Vtune doesn't know how to unpack a macro). Edit: I had no idea about the "inline" keyword.
Can zig do multiple compilations in the same folder? For example I will write a zig program for Arduino (i.e. avr). I would like to use GTest or the zig equivalent for unit testing. And then Python (or ruby) to run automated tests against the Arduino. Does the "zig menu" thing intrude on this? Note CMake can't handle this. And C/C++ has it's own little twists e.g. what's an int (arduino vs UT)? and so on .
I won't be happy until there is a generalized notational language, like APL, that can be handwritten and executed by a computer, with a type language embedded within, able to run in any environment, including low resource embedded systems.
I dunno i’d probably use it mostly as cross compiler for C for a language i rather use Odin Zig code looks for me like a lot of noise basically like rust code looks like.
But is it true? c/c++ do pre processing ahead of compile, but rust does not? It‘s compile time and very hygienic? It is compile time meta programming, so compiler checks are included. But anyway i like zig, it looks great.
As a JS dev by trade hearing people calling C bloated will never not be hilarious to me
Except that JavaScript traditionally *was* a really bare bones language.
That's the entire reason why things like 8 billion npm packages per project and `left-pad` are jokes that ring true-cuz JavaScript used to come with an insanely minimal internal API, and people had to keep writing the same basic utility functions for each new project.
But yeah, you're right. C isn't bloated. Its compiler does do some truly magical shit, sometimes, though-especially w/r/t undefined behavior
JS is not bloated today. You are confusing libraries / frameworks with the language. Look at Java, or worse, PHP (yuk) with thousands of standard methods.
When he said c is bloated because it links in standard library, then said zig does the same.
By the time it gets to full release, the standard library will very likely be much bigger than it is now. The same as c standard lib is much bigger now than it used to be.
Well computers are bloat, we should just be using an abacus at this point XP
huh? I have never heard something like that before, you mean C++?
I was on there discord for a while, they are a good community and try their best to help anyone that ask. I’m personally waiting for 1.0 but is good that you give it a try!
I find the Zig and Rust communities on Discord are both great. Swift is a bit behind probably due to fewer users but still good.
NEVER EVER EVER wait for technology. When something is moving as fast as Zig jump on ASAP or look back with regret.
Exciting times we stand in where there are some genuine alternatives to C. They don't have the same pedigree and standing at crossroads is never fun but I am genuinely excited to see where this goes.
WTF are you talking about. Have you slept since C99?
Is here some mass delusion going on? There are enough "alternatives" through time and space already here.
Which doesn't impress systems or embedded programmers very much ... because THEY KNOW THEIR BUSINESS and don't need fancy BS, but RESULTS.
Sorry for the arrogant reply, which you deserved (you are obviously blind???). At least we share the love for the Mechwarrior-Universe:) But not for the history (and facts) about BCPL and Algol based computer programming languages ... which is a little bit sad.
True, and I guess languages like Zig, Rust, Go or Carbon are just temporary experiments. Currently we are only finding out how we can overcome design flaws of C/C++, and how to build a language that is (thread) safe and bounds checked, of consistent syntax, easy to parse, read and learn and which brings package management, testing and so forth with it. But I guess there will come even more languages after them, that will combine the individual strenghts of today's new languages, each of which will probably hit its limit at a certain point of complexity we don't know yet.
@You Tube C isn't going anywhere anytime soon, but especially as far as new code goes, it's getting less and less common to write it in C.
There will be a time where jobs involving C will be almost entirely maintaining legacy code -- similar to COBOL today. C is no longer the only realistic option for the embedded space, and some new low-level languages offer just as much freedom with safer code, better syntax and a lot of the time, faster runtime. Linux will be one of few reasons for anyone to write C in coming decades.
@@deNudge Rust solves the problems that C even doesn't try to solve, namely:
- safe low level memory access
- user defined safe abstractions
- type safe error handling
- safe multithreading and async
- complete CI and development toolchain
- cross-platform and C-interop
^^^ all this at the same time. So Rust is the unique technology right now, the only serious problem it has is the steep learning curve, because safety cannot be simple in principle.
@@linkernick5379 Rust is great but I wish it's syntax was more like Go or V. Instead it has unnecessary elements that make it feel bloated
I like that you are covering zig,
but you didn't mention some of best selling points:
comptime, the build system, the interoperability with existing c code, and error handling.
Because he does not seem that great of a low level programmer to begin with. So of course he won't go into the kind of depth, low level programmers would expect from him. Yet another programming channel that makes subpar content.
@@encapsulatio You judge his skills just because of ONE video? I bet you can't code for shit for how conceited you are.
@@stms999 No, all his videos are just "pump and dump more content hardly any quality" type videos.
@@31redorange08 Yeah it seemed to take a while to compile a simple script. Kinda makes me nervous to use it.
@@encapsulatio Make your own video's if you're that good. Also c-interoperability and error handling are not strong points compared to Rust, so I get why he didn't mention those.
3:11 "All your (code)base are belong to us"
I love that reference to the game Zero Wing, in which the space fighter craft you control is called... ZIG.
Oh man thats right! I bet thats where the lang name comes from!!!
I feel like out of all these new system languages, Zig is the closest in spirit to the good old C, but with some reasonable modernizations. It doesn't try to revolutionize too much about the way people program, like Rust does, instead it sticks to the good old structural, imperative programming with manual memory management, while bringing a lot of convinient features.
I think this might be the future language for a lot of embedded development and quite possibly the best alternative to C for kernel development.
Well said.
embedded is the perfect environment for zig, but for kernel development on x64 or arm, rust's ridiculous obsession with safety is pretty key.
@@ygypt I see your point. In my experience, Rust gets really awkward when you need to do a lot of unsafe stuff.
And you need to do a lot of unsafe stuff in kernel development.
I know it's possible to use Rust to create a kernel, but despite my love for that language, Zig would probably be my choice for this sort of thing.
Although, all my kernel development experience is in C, which is closer to Zig, so maybe I'm biased a bit.
As a complex language Rust also has BIG drawbacks for Kernel development.
Linux kernel team is very careful about Rust for this very reason.
Kernels need simple, minimalist language to avoid being clutered later.@@ygypt
why can't it be used for Web development and Backend services??
I love the simplicity of C, and the fact that Rust is so complex is a deal-breaker to me. Zig on the other hand might be something worth learning, as its simple and avoids making binaries that are massive in size. Its almost perfect for embedded.
C is my go-to, but I want something with some modern conveniences: no header files, better types, package management. Rust is complex, but I do like the way you handle iterators with high-order functions. I've been trying to learn some Zig as it says "A Simple Language" on the tin. It isn't simple, and there isn't much in the way of learning the idiomatic way to do things. I think I'll hold off for a while or just try banging my head against Rust some more, at least the compiler messages are understandable.
How is Zig less complex than Rust?
Zig the language is cool. But I find its build system to be really annoying. But maybe that’s because I’m used to cargo and cmake? Dunno. But I wasn’t a fan.
Rust complex? Not complex for me. Im not the best programmer out there but once you get the handle of the borrowing system and some smart pointers its fairly easy to do stuff. What is true is that it's annoying the fact that you have the compiler all the time complaining about stuff, but for me is a love hate relationship. And although I hate the compiler sometimes, in the end the truth is I love Rust.
Rust is memory safe; Zig has bounds checking but doesn’t prevent use-after-free or other types of temporal safety violations as far as I know.
Yeah, Zig’s great usually. It just shows it’s pre 1.0 status a good bit (I’ve reported a few internal compiler errors and dealt with some annoying problems while writing my Scheme implementation).
Definitely still needs work, but each patch it gets a little (or a lot) better.
I'm just glad it isn't one of those languages that rushes 1.0, then also has to rush a 2.0 and 3.0 to clean up
I tried it and really liked how it felt like c but better. Also I was blown away by the comptime feature and how it's used. And meta programmjng is nice too
I don't fanboy over much but Zig is pretty exciting. After weeks of frustration with debugging C, dealing with UB, etc. I thought that was just a part of lower-level programming.
Coming from Python and Go, Zig was a little frustrating at first but I literally had it down in a couple days.
@@mgord9518 Good to know. Same Python/Go/C# exp here and I think I’ll give it a try :)
In my head, I keep them in matrix: Zig being an alternative for C and Rust for C++.
This is how I've always viewed it too, which makes him comparing Zig to Rust instead of C a bit painful to watch
@@nibbletrinnal2289 They're all close to the metal systems programming languages, with C++ being fruther from the metal.
@@curio78 D doesn't catch on because it kept too many c++isms and tries to be everything for everyone causing it to suck for many of the same reasons cpp does. people don't want another cpp or yet another foray into failed '80s-'90s OO and RAII ideas, they want C done right now that we have 50+ years of hindsight. Rust was able to gain traction because it's "different enough" from cpp and provides a big idea feature (borrow checker) that appeals to the new breed of safe-space fisher-price programmers who have graduated from webdev kindergarten and want to do big-boy programming but are still scared of memory for some reason.
While it would probably be my perfect language in another world, many of the things it tries to do are just done better by other languages. Nim in particular comes to mind, since I feel it does things like c interop and compile-time evaluation much better, though it has much more hidden control flow and is very heavy on macros.
Really hope Zig matures though, it absolutely has a place in this world.
How will it mature when you have already dismissed it from the get go
@@weiSane there are people developing the language, aren't there?
yeah and calling nim new would be wrong, it’s like 15 years old or something. it’s had the time to be refined and had bugs fixed and packages written
@@morgan0 Well nim is relatively new compared to C or C++ which made me shout at the video author when he only mentioned them with Rust and, one language that may or may not exist in the future???
But also, Nim is also older then Rust, so not sure how long that history is, so the point stands. My first language was older then both me and Nim (Ruby). So yeah, no this is just semantics.
@@twenty-fifth420 nim is older than rust but not that much older.
It is the Zig programmer's responsibility to ensure that a pointer is not accessed when the memory pointed to is no longer available. Note that a slice is a form of pointer, in that it references other memory.
Cannot compare with rust
I sorta wish Zig stopped at being C's new Cargo utility, maybe bake in some safety passes for C.
Language is great, but we're reaching the point where there's a new language every 3 months again and I'd rather stop learning syntax and do some real work
you don't have to learn zig if your current set of languages work well for you, doesn't mean others who haven't already committed to C or Rust or whatever shouldn't have another possibly even better option to choose from.
New stuff can be useless/useful for each person, and more new stuff in the software space at least is generally always good. What is bad is potentially misleading marketing around said new stuff.
@@sadhlife it's more a concern of fracturing communities for me which we saw in the 80's-90's when lexx/bison made it easy to create languages (as LLVM does today)
We see the same thing in rust game dev where there are 50 engines and no games being developed. Research and learning are great but if all we wanna do is fracture into another language instead of solving issues with what we have then it'll never end.
Another eg: Someone is going to get mad at zig for not doing what they like so they make Zag, and then zig corrects those issues and now we have two communities building two sets of tools/libs.
I forgot about this language. It's really interesting. As someone who has an immense dislike for C++ and loves C, Rust and Go, I find Zig really interesting.
if only Jai publicly available, it will smoke all of these language out of the water.. maybe u can try Odin too
@@_slier I don't know about C or Zig, but Jai won't "smoke" Rust or Go "out of the water" because it's not intended to replace them. They're each intended to do different things, and differently.
Welcome from the same boat!
As someone who loves C, I can't keep up with all those hipster languages that nobody in the industry uses.
@@billigerfusel Exactly!
I'm skeptical about languages that try to avoid strong abstractions, macros and reflection. In the end programmers will always want to do metaprogramming. If you don't think about how that will fit into your language from the start, then it probably won't fit well and you will end up with something like tools that half-arse-parse your language and generate code or abusing other features (like c++ template programming).
I still prefer after 10 years, when go back to some code to know what exactly that function doing, instead User.findById monkey patching on the fly.
You really tried to sneak in reflections lol
@@vojtastruhar8950 it seems to me that reflection is a part of macros and metaprogramming. No?
@@maninalift Yes, definitely yes. I just think that reflection is to be avoided at all times at all cost. It's not something I can imagine anyone to be happy about.
I'm skeptical about C replacement languages that employ strong abstractions. Part of the appeal of Zig is that it does not.
I recommend that people start with C BECAUSE you need to be aware of how memory works. Avoiding it because beginner developers might write unsafe code just delays the inevitablity of using a linter to identify where there's a security issue.
I agree. Everyone should learn C, and probably at least try Rust.
Learning C made me better at Rust because it made me understand memory
That's where I'm at too, I'm learning C before learning languages that attempt to solve the problems with C
I used zig after using Rust for years and the thing that made me stop learning zig was the error messages. I found them really unhelpful. I understand that making good error messages is really hard but I think that it is the most important part of any new language. I also think it is very important when considering what language to learn first.
"One level above assembly, one level below c" is perhaps the strangest way I've seen Zig described to date. Apparently not loading a std library puts it below C (is C a level below itself when you don't load std library?), but what puts it above assembly? It's abstracted over the hardware, but no more or less than C is? What does it all mean!? :P But Zig is pretty dope, so onward!
Imo he misses the mark here. I didn't watch it all but it uses llvm so it translates to a virtual machine not assembly. So that's your one level above assembly. His statement one level below c is just flat out wrong. Any language like c that'll let you sneak assembly instructions into it is pretty damned low level. Regarding bloat you can address that in c real easy so that statement is complete nonsense.
I'd love to know your thoughts on Odin too. Both Zig and Odin set off with the same goal, a better C alternative systems language, without trying to be a memory safe language like Rust. But they both have entirely different philosophies.
I explored both of them a little bit a while ago, now sorta settled in with Odin. This may just be my personal taste, but I'm enjoying Odin a lot more than Zig, especially for game programming.
Can you explain why do you prefer Odin over Zig for game dev ?
@@quelkun Odin is a lot more simpler, and feels like it's more specialized for game dev and graphical programming. Zig shines more on the C interop and its drop in compiler.
Ultimately, it's just a personal taste. There's nothing more to it. You gotta try both to know more about both.
Surprisingly one of the most unique features of Zig is the lack of "bloatness" compared to other languages. You can make a very tiny, portable, statically linked executable that does just what's meant to do and you don't have to do dirty hacks (like unsafe or nostdlib) just for it to be small or fast. Rust and C++ can't do that because of their huge standard libraries embedded in every application.
Yeah it definitely would fill a good niche.
Why is the full library included in final compile? the compiler should notice that calls are not made to these functions and not included it.
I use IAR Workbench free limited and pretty sure it does just that.
Rust can do it with no_std development..pal
Doesn’t the Rust compiler automatically remove unused code from the output binary though?
You can get a Hello World! executable on Linux with C in 17KB easily
Zig is pretty cool! Learning about memory allocators opened up a whole new world for me.
As a Rust programmer who learned C, maybe I should learn Zig to see if it's a better fit to teach the basics of low-level programming (compared to C).
6:22 "why Zig?"
For Great Justice!
Rust also has integrated tests (even runs code snippets in doc comments when testing) and Rust also can do cross compilation. However, it has certain cross compilation limits. It is really difficult to cross compile to macOS in general because of all the macOS standard libraries you have to link and how to get them, but I heard Zig is doing that for you (increasing the download size of Zig, of course). So Zig is better in cross compilation, but if all you do is to cross compile to either other Linux hardware versions or to Windows then Rust (and C/C++) can do it easily.
The tests in Zig remind me of the built in tests in Dlang, its a lovely feature, im glad to see it included in the Zig compiler :^)
To be honest I kindof hope Carbon fails.
Difficult to describe it, it's just a lot of small things that don't fit right for me, and make me think it's not going to be good for us but will rather increase fragmentation without close to enough payoff.
As I said in my other comment Zig is nice and I believe and hope it has a niche.
Yeah, given the reliance on interoperating with all of C++ and it being a Google language I can only see it just having the C++ problem relative to C++ (being locked to whatever can work with it to avoid foreign interop limitations).
Yup. Carbon sounds to me like an attempt to make already overhelming C++ codebases reach new depths of hell.
I haven't looked _too_ deeply into, but it very much feels like a different dialect rather than a different language.
I don't like its coding style conventions. Should've stuck with ANSI C++.
I've never heard a *good* reason for Carbon to be developed. We already have D, and it's already in use. Good enough for me! And we also have Crystal, Zig (work in progress but already practical), Odin (maybe only for physicists and 3D graphics geeks), Vala, Rust and others providing more or less all the good features of C++ but safer, incorporating other modern ideas, and cleaner code. What can Carbon provide to be better then any of these languages?
As a javascript soy dev and someone who is learning rust, I'd really like to see where V language takes us with it's automatic memory management without garbage collection.
Vale is really interesting too! It uses generational references instead of reference counting.
But V is way behind, has a lot, really A LOT of bugs, and isn't well implemented yet. I think it is far from the 1.0.0 release
it has garbage collection for some objects (via reference counting)
V Lang doesn’t have automatic memory management yet. When you compile a v file to a C file it shows that it uses the most common garbage collector
@@awwastorpretty sure it just uses the standard Boehm GC, not ARC
C is bloated???
Over 20 keywords :/ takes hours to learn :/
it is
Neither C nor C++ require stlib/run-time, not even a dynamic memory allocation. You can program 8-bit AVRs with 2 kB of RAM (or less) without an OS of any kind in C or C++.
Please make a video on other new systems programming languages like Nim and V and how they compare with rust.
lighter than C ?
I wrote an empty main.zig and built it.
the statically linked executable size is 728k
running through `nm` shows 860 symbols.
hardly zero runtime overhead.
but then why do people say Zig is perfect for embedded systems?
@@turanamo didn't people say that about java in 2000 ?
Other things aside, Zig is a lot older than Carbon. To me it's a level above C. C is more like assembly. I'm finding Zig harder to learn than C but easier than Rust. Zig still has a runtime, still has code that runs before your main(). I believe you can also build without that stuff like you can in C and Rust for when you want to write close to the metal.
C also have code that run before main
@@seubmarine5347 It doesn't have to [have a code that run before main or even have a main for that matter].
@@sprytnychomik Does Zig has to have code that runs before main?
@@etodemerzel2627 I don't know.
@@sprytnychomikOnly if you’re targeting bare metal or DOS. If you’re targeting any other OS you have some setup code that runs before main(). Library loading, calling convention setup, and other stuff gets handled by that code.
Great video !
Glad you enjoyed it
It seems that a new language pops every day, this will not only kill other languages but the programmers who strive to learn them all.
I tried rust, then tried zig. I found zig to be more verbose and even more complicated. Might give it another try. Note, I have not done or liked C. So that might be a reason.
Honorable mentions in the systems space "Nim", " Beef"
vala, v, odin, red, pony
D
C doesn't have to do "do a bunch of stuff you're unaware of". This is especially true in embedded programming.
Yeah. Weird statement. C need not do anything at all before calling your main. It not need link in a ytbing.
The Windows PE format will add stuff to your binary, but that is Windows and has zilch to do with C.
Hmm, at least good to know about it. But so many new programming languages are continuously popping up, that my current choice isto look at what is currently worth learning when it comes to the combination of popularity and maturity of the language. And I believe Rust is just reaching the point where it is finally really taking over the world (it has started to the enter the Linux kernel).
So Rust is what I am currently very actively learning (but yep I cannot deny that it's definitely not my first language that I am learning, being a developer in many languages for about 20 years, I can see that the difficulty and learning curve of Rust can be a drawback to the newbies). When you have already seen everything about C#, a ton of C and C++ and also Java and JS, things are very different.
A drawback is also a benefit, keeps out noobs from competing for the same projects as you. Speaking as a retired non-coder who is also learning Rust (I know C, C++, Pascal, C#, Silverlight, ASP and SQL)
Rust, Zig, and Elixir are my main programming languages.
Rust and Elixir for the job market.
Zig for my personal operating system research. Of course, I first try to build a prototype in Rust, then port it to Zig in order to pad my resume/github.
1:47 Man actually called C bloated 💀
I still don't see a place for a new language like C was in 1967, suitable for large-scale projects.
There's a reason why C has become what it has become, and if Zig were to become a mature, production-ready project, they would have to develop a bunch of preprocessors, macros and whatever tools, such that they are indistinguishable from C, so what's the point?
it has comptime which is much more powerful than macros and preprocessors. the point is C but with over 50 years of hindsight.
I heard about this language for the first time about a week ago on Dave's Garage where it won the Code Drag Race (prime number sieve) against something like 100 other languages. It won by a massive margin.
From what I've seen that was largely because they cheated and did a lot of stuff during compile time instead of actually having the Zig program calculate it at run time. You really can't beat C and Rust by that much without cheating, because both are extremely close to the metal. It was basically similar to doing a constexpr in C++.
A use case I saw mentioned previously is that zig supposedly is a very good compiler of already existing c code. Haven’t looked into it so I could be way off, but that alone could make it worth while to check it out.
It does great with regular C code but can’t really handle macros sadly.
@@mithrandirthegrey7644How about writing a c code with macros and importing it in zig file???
@@mithrandirthegrey7644 oof. Every C code base ever laughing the corner with all the evil macros. Personally I can't do rust but zig looks interesting, however I think I'll hold off till a 1.0.0 release
Yeah, Zig does embedded/baremetal really well. You can't really compare it to Rust in this space as rust isn't viable for baremetal with its implicit allocations and non-portable standard library, both of which work great in Zig.
Zig has an edge in being easier to deploy on embedded, and yeah allocations are more explicit, and Rusts standard library is less portable.
Still though Zig is not at all as save as Rust. I don't know how LLL didn't manage to segfault zig, its not that difficult, especially if you don't use a "safe" allocator.
Zig will have the edge once it's mature, but id say it's a lot closer than you think it is, and big projects should probably prefer the higher memory safety guarantees Rust makes, IoT has a lot of safety issues currently.
@@9SMTM6 Yes segfaulting Zig is not hard, but at least you have to explicitly shoot yourself in the foot to do that. There is no unsafe marking in zig, but I don't see that as an issue.
The safety gurantees of rust really doesn't mean anything when you're running on baremetal though, as for example, two completely different regions of memory could reference the same DRAM, writing to an MMIO register a tiny bit wrong could just make your entire program invalid, there are DMA engines that have way higher privileges than any piece of your code etc. There is not much that "Rust safety" can do on baremetal, or to prevent logic bugs on any platform.
rust is perfectly viable for baremetal;
Wonder how you'd implicitly allocate something if you can't allocate
@@N00byEdge there's actually a lot that rust safety can do on baremetal, namely allowing to build safe abstractions around direct HW interop
This is not true of Rust in 2023. If you're writing embedded firmware you're most likely already using the allocator_api feature.
Idk how about you guys but Zig is more readable than Go or Rust.
Should I start my programming with zig? Just like people say tackle the hardest then else is easy lol
Edit : thanks for everyone in comments for suggestions :)
I say choose what sounds most interesting to you. I haven't used Zig, but it sounds like a great place to start, especially compared to languages like C++ or Rust
Start with C if ur intetested in system level programming
If you will choose C, I recommend to start with the "Beej's Guide to C".
Today I probably would choose Go (as it's stable enough + there is a lot of learning material around).
Then I would switch to Zig:)
You want to start programming or to get a job as a programmer?
Pretty sure that it's a second option, then, no.
Use C. It's the best. Teaches a lot. After that, learn python, java or js if you want jobs.
This is actually really exciting! Can't wait to learn this! Hopefully it catches on with more programmers
> MIPS processor running windows
> I know, that doesn't exist
NCommander would like to have a word with you
Could you make another video but using Nim ?
Came to ask this 🤣
Recently started experimenting with Nim for embedded. It's really nice and elegant, actually! Much prefer it to C/C++ for doing anything complex.
Zig is positioned as an alternative to C and C++, it's not higher or lower than them, it provides a different set of trade-offs and design choices.
Huuu.. it's certainly lower level than C++. C++ is full of high level abstractions which Zig has none of.
To me, Zig *feels* higher level than C(it's far easier to program in), but its actually able to do a lot more than C can, making it lower-level.
I've seen a few examples of kernels written entirely in Zig, without any handwritten assembly code. You simply can't write a kernel in C without handwriting at least a *few* lines of assembly, and a kernel in C++ requires even more non-C++ work to do. That's why he says its lower-level than C; Zig being advertised as a C alternative doesn't change the fact that Zig *is* lower level than C.
I've been putting off learning C in depth for a while because of the crazy errors it gives. I hope this language doesn't make you suffer for just trying to format strings.
Companies be already hiring people with 10+ years of experience in zig
00:02:10 ... We avoid the C bloat that comes from being forced to load the standard library.... By being forced to load the Zig library... then what is the difference? Then it is just a case of the standard library being written well, which is not a point for or against Zig...
PS: Bun is written in Zig, and I don't know if it is bun's fault or zig's fault, but Bun will segment fault under a heavy load.
I think you have to be careful about mentioning the standard library with C/C++. If you write Win32 code and use that API and the provided functionality, you don't need the standard library. Also the bootstrap code that you need before entering main/WinMain is really an operating system thing rather than a language thing. For some of the 4k demos I do, I've got my own startup code which is just the bare minimum of what you need to start a PE executable, which is greatly simplified if you understand what the startup code does and work without object orientation.
I think you forgot the most important part of zig unless I missed hearing you go over it.
Zig has C interop as a first class citizen, so any c headers etc can be imported in zig. And like 95% of all existing low level code is c or c++ and has documented c headers, so that makes porting to zig 10009834892348 times easier than porting to rust.
The real fit for this language is anyone that needs a system language that is easy to pick up because they already know some C++ (basic skills) and know Java or C# etc. Zig is way easier to pick up coming from an experienced dev view point than rust.
Zig is still young and not 1.0. Will see what it have in a couple of years. Currently much easier to use is D. Fast write and fast run. Love it
except nobody uses it, D lost from the start cuz of selfish developers made it closed source now it is too late , bye bye D
I tried to learn Zig but I keep getting turned off by the weird and special syntax. I find Hare to be more elegant and consistent that way.
But a simple "Hello World" program compiles to a 4MB executable.
I am looking for a way to program "hello world" really small, as in a maybe a 100 bytes or so. Even in assembly, which I am just trying to lear, it takes almost a kilobyte and that is after using "strip". But both ld and gcc produce executables way bigger.
It's still in beta and after trying to write game engine on top of SDL2 with Zig bindings and receiving illegal instructions error I gave up. It is still not mature enough, remember that.
Man... writing fn before every function is an instant turn off, why cant we just stick to the C like function declarations
greppability
Also keep in mind the longer / more cryptic keywords being used for that. Eg. `def` in Python or `defun` in Lisp:)
Better than void
@@saulius2 they aren't cryptic, you immediately can guess what it means
@@climatechangedoesntbargain9140: it's all subjective. To me `defun` says more "Default Unused" than "Define Function".
TIOBE Index for July 2023:
3) C++; 17) Rust; [unordered] 50-100) Zig
*No, thanks!*
I still don't see any sense of language like Zig. For teaching purposes, in first lessons you can use Python-like or Java-like subset of Rust, e.g. ignore advanced features like custom generics or "safe" memory management, and instead use e.g. Arc, which is essentially counting garbage collector (as the one in Python).
That's how C++ (even more complex than Rust in some aspects) was taught decades ago.
The best code (here: programming language) is the one that doesn't have to exist (and be bugfixed, maintained, etc).
The dependencies mess, macro, hidden code .etc… just because we need it, not a “defect” of any language. A new “simple” language sounds so naive to me because that not a problem to solve.
I'm currently learning Rust on the side while I learn Java... probably not the best choice, but it kind of helps me understand how things can be done differently in another programming language.
Hm.... you repeatedly mention "libc" as an example of a library that makes a C program "bloated" and may do stuff I'm not aware of.... but the first line in the example Zig program is an import of the Zig standard library. How is that any different from using the C standard library? How do I know what the Zig standard library does?
C is not bloated.
I currently can choose a language for a side project, a simple file server called JAM FS (Just A Messy FileServer). I want to use a new language, either Zig or Rust, booth are fast and get the job done.
Very interesting language! Thanks for having signalled it to us. I'll try it ASAP.
That "also subscribe" was really smooth. Take me a second to realise the video's over. Subscribed!
Idk, i really, and i mean REALLY like rust macros. You can recursively expand them in your editor with rust-analyzer so to me theres barely any hidden code. I suppose if you dislike macros zig could be useful but stuff like sqlx query macros that validate types for your queries at compile time (you can even do it without a dev database now using a optional feature) are really fucking neat.
idk about macro, but if you want to do something in compile time this can be easily done with comptime and std.meta. For example you can look at case study section of comptime in zig's doc
Maybe a zig or rust structured playlist for complete beginners?
As a numerics engineer even though this is a small community I could really see it adapted for very fast running simulation code - provided there will be libraries for it. Rust just feels too complicated for someone that wants to run some code that for the most part isn't really touched by anoyne. On the other hand though, people would also still use like Fortran66 and have all strange variable names...
you should do a video on nim. it’s on its second major version iirc, and has been out for a while and does the same sorta thing (except there’s a pretty powerful macro system, which has been used to make a python compiler and a cli interface generator among many many many things)
Ooh I very much like what I'm seeing already after reading the first few bullet points. I've missed this in new languages for quite a while.
Zig is the language for me after I learn how to code in Go. Go is an easier transition to pointers coming from JS than Zig is. After I get comfortable in Go, maybe I’ll Zig more of a go (no pun intended). Zig just feels like too much of a leap for me right now when Go pointers/references/strictor than TS types are still tripping me up. I’m very experienced with JS and TS though.
Just to mention you also have D and BetterC as system language which has been around for longer than Rust.
And D has a memory safe subset unlike zig.
Actually there where some obscure versions of Windows NT that ran on MIPS CPUs ;)
Precisely. It made me think about this video by Adrian's Digital Basement where he tests Windows NT 4.0 on a MIPS R4600-based PC:
th-cam.com/video/1n0kWWqQ0D8/w-d-xo.html
Since you've peeped Zig, have a look at Nim too -- a more mature, but less low-level systems language that compiles to C, C++, Obj-C (and somehow JS).
Has a bunch of _wacky_ features, like homoiconicity.
You could use Nim like C and just disable the GC entirely.
man i just love the way you explain.
What are your thoughts on how zig compares to Nim? I'm surprised nim isn't more popular when I see videos like this.
I think it is easier to pass "-nostdlib" to C linker, then invent / learn new lang. Maybe they should check all parameters before?
I'm old-school (not just old!). I believe that learning C as your first language is a good start. If you really learn to master it, programming in Rust, PHP, Java and Zig will be easy.
I found it really interesting how you recommended to write something simple like a web server to test drive a new programming language. I guess it makes sense for a person who's written a million web servers in the past, but to me this sounds like a daunting and an extremely boring task. Why would I write a web server for a test drive when I could write a cool simulation? Or a raytracer? Or a physics engine? Or a game? But this just really shows that to each their own.
4:43 i would disagree with that statement. We learn by making mistakes. The more we fuck up, the better we get. And C enables us to write unsafe code, from which we can learn.
As you say at 6:50 "You have to know what things are unsafe, to make things safer".
Since we're talking systems languages, have you looked into Nim?
I'm old enough to have been programming long before C was released (anyone else remember City and Guilds mnemonic code?) And there has hardly been a time since when people were talking about some language that was about to displace C. I'm not going to hold my breath for any of the current contenders.
Zig will come into picture for me when APIs of Azure, Amazon and Datadog support it and there is a decent IDE and ecosystem with tons of libraries are available so I don't have to reinvent the wheel again
Haven't tried it, but from just looking at the examples, I like the syntax a lot. The syntax looks like a normal C-style language with less of they uglyness of C. It looks a bit like if JavaScript/Typescript was turned into a systems language.
Before watching the video, I was asking myself where the name zig came from, but thankfully I think you managed to answer that. FOR GREAT JUSTICE!
Ouf, I'm not sur that I like Zig at all because of the absence of macro.
Macros can be used to to gain performance in certain case in critical components depending on some hardware configurations. It would be crazy not not use a preprocessor at this point 😅
comptime enables you to do most things that macros are used for, but it gets handled safely.
as a primitive example, you aren't forced in zig to use void pointers for ADT keys/values/elements. You use comptime and pass the type in, so you get the compile time checks and the performance benefits of having typed containers.
As an added benefit, comptime gives you powerful reflection capabilities as well, making lots of things essentially trivial in zig that would be complex or impossible in C macros (see MultiArrayList for example).
This is not a good review in my opinion as he's conflating run time size with level of abstraction (the latter is independent of the former). The standard library (most of the run time) is not part of the language. It is very useful so you don't have to implement your own system operational code such as allocators, io etc. But that makes it a useful UTILITY not part of the language!
For example, if you're developing for small microcontrollers you're not likely to use the standard libraries at all - you write your own allocators, io etc. The language standard (compiler implementation) is not the same as the standard library (standard utilities).
Zig is a young language and it's standard library will increase with time as the language matures. But again this does not affect its level of abstraction.
I've been writing C in a while and macros are a very handy thing when you want to write the same code in multiple places and can't afford the time cost to call a function (a function call is slower than comparing two numbers and that is what actually stings in the qsort function performance, unlike in the case of C++ sort which has the code of the < operator injected in its own to avoid function calls while sorting).
Not to mention one can write a macro to generate a funcrion. The only situations where functions are better than macros are recusivity (impossible with macros unless you build your own stack) and when you use 3rd party tools to analise performance (at least Vtune doesn't know how to unpack a macro).
Edit: I had no idea about the "inline" keyword.
function inlining hints do exist, though
@@yjlom Thank you. I had no idea about the keyword 'inline'. This will actually spare me a lot of pain in the future.
Surely making lightweight standard libraries for C is the better plan?
Is there any reason besides "I like it" using this colors in your terminal, such as "Doesn't hurt my eyes", etc?
Can zig do multiple compilations in the same folder? For example I will write a zig program for Arduino (i.e. avr). I would like to use GTest or the zig equivalent for unit testing. And then Python (or ruby) to run automated tests against the Arduino. Does the "zig menu" thing intrude on this? Note CMake can't handle this.
And C/C++ has it's own little twists e.g. what's an int (arduino vs UT)?
and so on .
I won't be happy until there is a generalized notational language, like APL, that can be handwritten and executed by a computer, with a type language embedded within, able to run in any environment, including low resource embedded systems.
I dunno i’d probably use it mostly as cross compiler for C for a language i rather use Odin
Zig code looks for me like a lot of noise basically like rust code looks like.
Zig is advertised as general purpose I don't see why you keep advertising it as systems level programming language
It's like Rust. Goes where it shouldn't and fucks over both forks and users because of how it was misused/overused.
@@MortCodesWeb stay mad rust is better than your crappy language 😂😂😂
But is it true?
c/c++ do pre processing ahead of compile, but rust does not? It‘s compile time and very hygienic? It is compile time meta programming, so compiler checks are included.
But anyway i like zig, it looks great.
I'm referring to the part what other system languages don't provide, but Zig does.
Also AFAIK they want to get out of LLVM, which is very interesting as it'll allow the community to iterate faster on what it wants to achieve