Interview with Zig language creator Andrew Kelley 

Well it is really good content. The focus on concepts and how they manifest in the languages rather than just looking at the languages in isolation is super valuable. I think its a great learning resource for medium to more advanced programmers that want to learn and venture out of the one programming language they already mastered.

How about an interview on the Beads language?, which is a general purpose language that is designed to built web apps, mobile apps, and desktop apps with a single language. It is a higher level language than Zig, intended for making graphical interactive software. Certainly a very fresh break from OOP paradigm. Beadslang.com (don't have that 501c3 yet!)

He seems like a really cool, down to earth dude.

Thanks a lot for this video! Do you have in your agenda an interview with V language creator?

@@CristianMolina I haven't talked with him yet, but I'd like to coordinate something during this year with him. Also with Ginger Bill on Odin.

But why? C is a very simple language and comes without any sort of syntax sugar. That makes it ideal for learning low-level stuff because syntax sugar usually hide some "boring" details that could be important for understanding a topic.

Алексей - what syntax sugar does Zig have? Semantics is not “sugar”. As to why I’d like to learn with zig: because I’d actually make things with Zig. C might be good for learning, but I wouldn’t trust myself to make production software with it. There are too many “gotchas” with C.

@@aleksei5172 header file? no way jose!

C is probably a better way to start off, the things wrong with it can teach you a lot

@@jawad9757 Yeah man writing #define min(x, y) y > x ? x : y; is basically equivalent to getting a Ph.D!

Allocating stack frames in the heap is “business as usual” in some functional language implementations, e.g., I think SML/NJ. But of course there it is done magically by the runtime system, rather than in a programmer-controlled way as in Zig.

Well, that isn't so new a solution. Also, any recursive algorithm can be translated in a non-recursive algorithm, which is preferable.

Thanks for the feedback! I hope some recent inclusion of Haskell and F# has been interesting at least. I also want to spend some time learning Idris and Agda, but time is limited. Finding good balance isn't always easy. But I still appreciate the feedback. And I mostly avoid the coffee cup as a protest against Oracle.

you have never seen my browser... 3 windows, with over 100 tabs each... i want to die :/

@@itellyouforfree7238 same

Heap allocations just became safety-checked if you use the std lib GeneralPurposeAllocator. There is a plan to make stack allocations safety checked as well. You can follow this issue if you want updates: github.com/ziglang/zig/issues/3180 Once that's done, Zig will be roughly as safe as Go, with some caveats.

Static verification... say no more: Ada/SPARK.

the lack of two features described by you is probably main reason why I considered Zig and not Rust. So, please, don't make Zig to be Rust. If someone like Rust features, just use Rust.

So, for one, I don't mind having static analysis even outside of the language, or using existing features to implement it (in fact, the second one would be pretty great). And dereferences in pattern matching could be marked, to show that they are exactly that - though that seems hard given how the syntax works currently. Though, with better anonymous functions, this one could very easily be implemented in Zig code as opposed to the compiler. That said, having such features (that each don't really have any harm, if you differ I'd like to hear the reasons for it), especially optionally, is not a bad thing, I think. My comparison here is Rust only because it's the language I know that does have those features - so just arguing that you wouldn't want it to be closer to Rust doesn't really address the issues I personally have. That said, the best case scenario would be if both could be somewhat painlessly done without special features in the compiler for them, but with the necessary compile time machinery to achieve them to a satisfactory level. And I don't think that extending what makes Zig stand out so much (among very coherent design & general simplicity that is honestly surprising given the power Zig gives you - and I don't mean the power to do anything, but the power to be expressive here) is a bad idea at all.

@@codenamelambda > And I don't think that extending what makes Zig stand out so much is a bad idea at all. I have no enough motivation to elaborate. But I would like to say the gist. Every language feature impact the way you write code, enforces different patterns, trade off and style. And even if some feature is like "it useful, Rust have it, it's easy to add, you not obligated to use it". And it seams like okay, eventually it impacts how developers write code. And it impacts you, even if you not obligated use this feature. For example I'm not obligated to use Rust macros, but eventually I enforced to deal with its complexity because other developers write it! And also it impacts compilation speed, IDE responsiveness, etc ... so, I't impacts my language user experience. So, as you can see, even If I don't personally write any single macro in Rust , it impacts me as Rust developer. And so happen with every "cool feature".

but you can use mutable pointers. creating those is not undefined behavior. it's UB only if you use them wrongly, just like in C

​@@itellyouforfree7238 Yes, that's true. What's different is that there are some things that are UB in Rust but not in C. For example, creating two pointers to the same memory location is fine in C and you can write to either (unless you write to them concurrently). But creating two mutable pointers to the same memory location in Rust is UB even if you use the 'unsafe' keyword and only access them in sequence.

@@OMGclueless That's incorrect. It's UB to create two aliasing mutable references (&mut). It's not UB to create two aliasing raw pointers (*mut), just like in C. Using them incorrectly (like dereferencing when you can't) can cause UB.

@@OMGclueless You have a misunderstanding. Think it this way, a reference in Rust is a restricted raw pointer in C. A raw pointer in Rust is just a raw pointer in C. And there is also UnsafeCell that allows you to bypass some aliasing requirements by disabling some optimizations (note that using UnsafeCell in Rust is equilivant to using raw pointers in C, so even if you lose some optimizations it is equilivant to the "idiomatic C")

It's just a cheap Amazon Basics mouse. And I've often used cheap Logitech or Microsoft keyboards. Nothing fancy.

He gets an income these days, but not a huge one.

I'm not fresh on the Ackermann function, although I expect determining stack size statically and perfectly in the general sense would likely be equivalent to the halting problem. I already forget the specifics of Andrew's answer here, though.

Recursion can only be used in special cases where the maximum recursion depth is well defined. Like in merge sort, the max recursion depth is log_2(n) where n is the number of elements.

This is so accurate lol!

The more you write Zig, the less you miss RAII. I think there are two main reasons for this: 'defer' and arenas. Zig has a 'defer' statement, which can be used to run code whenever a scope is exited. In practice, this is very useful for resource deallocation, because you can do e.g. 'var f = try std.fs.cwd.openFile("file.txt", .{})', and then immediately after 'defer f.close()'; since you write it immediately after it's pretty much impossible to forget (you quickly get into the habit of deiniting any 'init' or 'open' or 'create' call do), and you don't have to deal with the C issue of making sure every damn return path frees your resource. The second (and imo most important) thing is arenas. Of course, one of the most common RAII use cases is freeing memory: in C++ I can make a massive nested datastructure and know it'll all go away once it goes out of scope. Handling this whole thing with 'defer's and explicit deinit functions would definitely be inconvenient. However, there's a solution! Zig doesn't have a "default" heap allocation function (like C's 'malloc' or C++'s 'operator new'); instead, you explicitly create an allocator (there are a few common options in the standard library) and pass a pointer to it through function calls that need to allocate memory. A consequence of this is that mixing and matching types of allocator becomes very natural. In particular, Zig has really good support for arena allocators. These are allocators which allocate memory in a big block (never freeing individual allocations even when you ask), but which you can then deinit to free all the memory at once. Zig has one in the standard library, called 'std.heap.ArenaAllocator' - it wraps another allocator to acquire the underlying blocks of memory, and provides the standard allocator interface so you can use it as normal. It's very standard in Zig code, when you're working with big datastructures, to allocate everything into an arena, and simply deinit that arena when you're done; for instance, if you're parsing a huge datastructure, you would just allocate each individual struct into one big arena so you can free them all in one go. Not only does this solve the problem, it also has the benefit of being (sometimes significantly) faster! Traversing huge datastructures to free them can take a while - this is particularly unpleasant under RAII, because you can't even see the control flow but it could make exiting some scopes quite expensive. Deinitializing an arena is relatively fast, since all it has to do is free the underlying memory, which just consists of a handful of blocks. So the lack of RAII here actually ends up encouraging a pattern which is easier (you don't even need to think about whether the RAII will work!) and faster.

answer: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-ZvskDoP09Ao.html :)

I'd say Zig is a lot less high level than Rust, it tries more to be a C instead of a C++ like Rust does. Compared to V? Well, V is pretty much a known scam at this point, you should treat it more like a curiosity than a serious programming language

He does if he gets paid by the Foundation, just like getting paid by anyone.

C++ has constexpr but also supports macros. Thus any IDE supports c++ must support work with macros. Having an alternative doesn't solve the problem.

@@onursahin7970 I am not talking about the IDE support but rather the language design. You can use pointers ad integer types but that is not what pointer are designed for. Same goes for macros in modern C++. You can use macros for conditional compilation, but that is not the C++ way of doing things.

It is not the c++ way but they are allowed in c++. Thus you need to take them it into account when you develop static analyzers. Having alternative doesn't remove the problems of the older solutions if you have to support it too. Therefore they are also problem of c++.

the existence of constexpr does not mean you can escape macros. Legacy older than 2011 and anything trying to be portable beyond compilers that actually support c++11/constexprs will use macros. Zig is written in C++. He's well aware of what features exist in c++, but 'modern c++' is not most of c++. You do not escape bad legacy by just piling on more features.

@@psychotherapeuticprogrammi4619 I don't like C++ because it gives you more ways to do something, and has to trust the programmer to do the right thing.