Not sure it's helpful.. but the roadmap video with Andrew from late Jan 2024, talks in detail about how LLVM is a roadblock to faster compilation, and after the 0.12.0 release his/their primary focus is replacing LLVM with their own back end generators, which will greatly speed up compilation speed. That should be a big improvement overall.
Allocator passing is in no way enforced by the language. Its simply a convention for the standard library to be able to negotiate allocation strategies with user code. You can can also just use malloc and not ask anyones permission or advice about what to do.
I think we're meant to read the source code, which seems exponentially harder than a simple write up to get people going. In recent versions the build.zig file is LOADED with comments that are somewhat enlightening, but also some code for optionally generating a library which obfuscates the intent.
Finally somebody other than me says Zig is not as easy as everybody else says. I like Zig and play with it at roughly yearly intervals but each time I run into frustrations very quickly, second only to Rust. I'm used to both lower and higher level languages. It's definitely easier than C++ or Rust but much harder than Kotlin, Swift, TypeScript, Go, Dart. I haven't played with Haskell-type languages so can't compare with those.
@@gregandark8571 Zig is nothing like JavaScript. It is a low-level systems language. Closer to C than JavaScript. It is a compiled language with minimal runtime and manual memory management. Is it syntactically similar to JavaScript? A little bit but not really.
Great presentation! Although you outlined not to be a c++ developer. Talked about the pros and cons. I think developers nowadays just need to remember that current Zig toolchain is pure LLVM for C and C++, specifically c++ because it uses llvm-libcxx + llvm-libcxxabi + llvm-libunwind + [custom] libcompiler-rt (static libraries) in almost all targets. Unique C++ ABI!! (addendum)
@@gregandark8571 , Yes and no. It doesn't mean it will leave LLVM entirely. Only the main executable will be separated, making it optional. So far when using the Zig toolchain, we have used by default the flags `-fLLVM`, `-fClang` (for C and C++) and `-fLLD`, except for MacOS which replaces it with zld (`-fno-LLD`). The interest is to make the flags default `-fno-LLVM`, `-fno-Clang` and `-fno-LLD` (replacing with the Zig backend) especially for ziglang projects.
First, it is worth remembering that the Zig project is BDFL. I think it will pay off in ziglang development and possible compiler stability in the allotted time. Now it is infeasible to resolve and distinguish bugs of LLVM and the compiler itself. If you observe the zig project has few compiler developers, there are many contributions in the stdlib. Is it worth extending the time from pre-1.0, using LLVM by default? It was never the goal to maintain compatibility with C++, only C (arocc intended to replace clang, no C++ support). However, the possibility of complementing it with a zig-cc/zig-c++ plugin will not be ruled out. There will be a certain amount of time until the preview of releasing 1.0 appears, which is being worked out slowly.
Bun is reallly revolutionary for the JS runtime after the last big thing of node js in 09 And also the other language that want to replace c++ for game dev zig will be in the top cause of that build system
I found that funny.. cause zig is very much production capable with its quality compiled code. I think the purpose of saying that is that the language itself is still malleable.. so don't put something in production and then get mad if the next version breaks something you did.. and you have to spend time updating/fixing to stay current. But the binary output is very much on par with if not better than other compiled language options.
Not sure it's helpful.. but the roadmap video with Andrew from late Jan 2024, talks in detail about how LLVM is a roadblock to faster compilation, and after the 0.12.0 release his/their primary focus is replacing LLVM with their own back end generators, which will greatly speed up compilation speed. That should be a big improvement overall.
Allocator passing is in no way enforced by the language. Its simply a convention for the standard library to be able to negotiate allocation strategies with user code. You can can also just use malloc and not ask anyones permission or advice about what to do.
Is it a “convention”? I thought zig doesn’t have Malloc, if you’re using it you’re using stdlib from c, not from zig?
@@Diamonddrake zig doesn't have malloc, no, but it can import it from libc, just like any other c code, yes
You can also create a global allocator and access it from anywhere.
@@N00byEdgeI believe std.mem.c_allocator exists and it's malloc
While all this sounds great. The zig build system is very underdocumented and there are no structured materials to learn it.
Absolutely spot on
I think we're meant to read the source code, which seems exponentially harder than a simple write up to get people going. In recent versions the build.zig file is LOADED with comments that are somewhat enlightening, but also some code for optionally generating a library which obfuscates the intent.
Finally somebody other than me says Zig is not as easy as everybody else says. I like Zig and play with it at roughly yearly intervals but each time I run into frustrations very quickly, second only to Rust. I'm used to both lower and higher level languages.
It's definitely easier than C++ or Rust but much harder than Kotlin, Swift, TypeScript, Go, Dart. I haven't played with Haskell-type languages so can't compare with those.
you're not alone. yes, zig is a difficult language indeed.
zig beat fortran in popularity this year!? Thats a 'why, yes!' in my book, not a 'why not?'.
Isn't zig just a parody of javascript ???
@@gregandark8571 is it? How?
@@homelessrobot bcz it looks like javascript.
@@gregandark8571 lol compared to what? haskell? Yeah, of course. Everything does.
@@gregandark8571 Zig is nothing like JavaScript. It is a low-level systems language. Closer to C than JavaScript. It is a compiled language with minimal runtime and manual memory management. Is it syntactically similar to JavaScript? A little bit but not really.
Great presentation!
Although you outlined not to be a c++ developer. Talked about the pros and cons.
I think developers nowadays just need to remember that current Zig toolchain is pure LLVM for C and C++, specifically c++ because it uses llvm-libcxx + llvm-libcxxabi + llvm-libunwind + [custom] libcompiler-rt (static libraries) in almost all targets. Unique C++ ABI!! (addendum)
Zig is actually divorcing from llvm..
@@gregandark8571 , Yes and no.
It doesn't mean it will leave LLVM entirely. Only the main executable will be separated, making it optional.
So far when using the Zig toolchain, we have used by default the flags `-fLLVM`, `-fClang` (for C and C++) and `-fLLD`, except for MacOS which replaces it with zld (`-fno-LLD`).
The interest is to make the flags default `-fno-LLVM`, `-fno-Clang` and `-fno-LLD` (replacing with the Zig backend) especially for ziglang projects.
@@MatheusCatarino
Ok,so at this point.
Is this good that zig wants to divorce from llvm or it is not?
If yes,then why?
First, it is worth remembering that the Zig project is BDFL.
I think it will pay off in ziglang development and possible compiler stability in the allotted time.
Now it is infeasible to resolve and distinguish bugs of LLVM and the compiler itself.
If you observe the zig project has few compiler developers, there are many contributions in the stdlib.
Is it worth extending the time from pre-1.0, using LLVM by default?
It was never the goal to maintain compatibility with C++, only C (arocc intended to replace clang, no C++ support).
However, the possibility of complementing it with a zig-cc/zig-c++ plugin will not be ruled out. There will be a certain amount of time until the preview of releasing 1.0 appears, which is being worked out slowly.
@@MatheusCatarino Ok,thanks you very much!!!
Bun is reallly revolutionary for the JS runtime after the last big thing of node js in 09
And also the other language that want to replace c++ for game dev zig will be in the top cause of that build system
Don t use zig in production, also Bun released 1.0
Well - he's quoting the advice of the development team, which seems fair enough to me.
Don't use bun in production as well 👀
@@khanra17 😂😂
I found that funny.. cause zig is very much production capable with its quality compiled code. I think the purpose of saying that is that the language itself is still malleable.. so don't put something in production and then get mad if the next version breaks something you did.. and you have to spend time updating/fixing to stay current. But the binary output is very much on par with if not better than other compiled language options.