วีดีโอ

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.

you're not alone. yes, zig is a difficult language indeed.

I don't think the language has a formal name. I think the syntax is for LLVM's AArch64/ARM64 assembler.

It’s generally just called A64 assembly. There’s a minor variant Apple made but it’s not very different (it just moves types on SIMD operations from the registers to the instruction mnemonic). The syntax is defined officially by Arm themselves, so there’s no confusion, unlike with x86.

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.

Reflection is useful, and it would be great to have it in C++, but I wouldn't go as far as a separate build step with libclang and code generation. I'm using magic_enum, concepts, metaprogramming and occasionally macros to achieve some level of reflection in C++20. I used to occasionally use reflection when doing Java. I think it's the best tool for some problems.

@@szaszm_ I am not just talking about his solution to the problem I am also talking about the problem he describes itself. In all ways this dude is thinking of C++ as if it was Java, in the same way that much of the C++ design committee has done for "modern" C++. Sure reflection is useful and there are ways to do it in C++ but C++ is also a multi-paradigm language OO is a tool not the only thing in the toolbox. I know the example he was working was "just complex enough to warrant this response" but it speaks to how much people just want to be coding java. This example should just be a function that takes in the error severity and a string of the error message, maybe some ifdefs. You dont need to make things needlessly complicated for the people you work with.

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

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.

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!!!