441–450 of 527 posts
This is a very confusing blog post. I found myself looking for ChatGPT markers because it doesn't make sense to say: omg zig is so much cooler than C here's why, then start listing the absolute basics of the language that are identical in most modern languages without any actual reflection why writing the same thing in a different syntax somehow makes zig superior?
Earlier quoted context omitted.
But Zig doesn't need a keyword to trigger it either? If it's possible at all, it will be done. The keyword should just prevent run-time evaluation. (Unless I grossly misunderstood something.)
I'm no expert on Zig, but "comptime" is the keyword to trigger it.
Earlier quoted context omitted.
I had to dig farther on the compile time execution stuff. It's actually pretty cool-looking. Recommend digging into it. I don't know that it's a killer enough feature to draw me away from Rust's guarantees, but it is interesting.
It is difficult to overstate how useful compile-time execution is in practice. I can't imagine using a systems language without it now. The term "modern C++" largely denotes when compile-time execution was added to that language. I would love to see Rust get compile-time execution that is as capable as Zig or C++20.
Isn't that just macros which are way more powerful than what Zig or C++20 offer?
Earlier quoted context omitted.
If they want to keep to the error/diagnostic pattern I think they're gonna have to adopt some kind of standard context object that gets passed around. Passing an allocator, an IO implementation, and a diagnostic object all over your code base is going to get really fucking old.
if it helps: it's pretty typical to attach the allocator to the object directly, so you dont have to pass it everywhere. for library consumers, just build a global allocator and use that. io will just "have to be passed the annoying way" in libraries (but a consumer can also also easily globalize that).
I haven't seen anyone use a global allocator in the way you're talking about, and if you did I feel like it goes directly against the Zig ethos. Part of the benefit of allocators being passed around is that all allocation are explicit.
Earlier quoted context omitted.
I was also curious what direction the article was going to take. The showcase is cool, and the features you mentioned are cool. But for me, Zig is cool is because all the pieces simply fit together with essentially no redundancy or overloading. You learn the constructs and they just compose as you expect. There's one feature I'd personally like added, but there's nothing actually _missing_. Coding in it quickly felt…
out of curiosity, what feature do you want?
The need for this jumped out at me during Writergate. People had alot of trouble understanding exactly how all the pieces fit together, and there was no good place to document that. The documentation (or the code people went to to understand it) was always on an implementation. Having an interface would have given Zig a place to hang the Reader/Writer documentation and allowed a quick way for people to understand the expectations it places on implementations without further complications.
For Zig, I don't even want it to automatically handle the vtable like other languages...I'm comfortable with the way people implement different kinds of dynamic dispatch now. All I want is a type-level construct that describes what fields/functions a struct has and nothing else. No effect on runtime data or automatic upcasting or anything. Just a way to say "if this looks like this, it can be considered this type."
I expect the argument is that it's unnecessary. Technically, it is. But Zig's biggest weakness compared to other languages is that all the abstractions have to be in the programmer's head rather than encoded in the program. This greatly hampers people's ability to jump into a new codebase and help themselves. IMO this is all that's needed to remedy that without complicating everything.
You can see how much organizational power this has by looking at the docs for Go's standard library. Ignore how Go's runtime does all the work for you...think more about how it helps make the _intent_ behind the code clear.
Earlier quoted context omitted.
I'm sure I'm not alone - after decades - already knowing far too much about C, so that any article I'm likely to read either I'm like "No, that's wrong and I even understand why you thought that, but it's still wrong" or I just nod along and sigh. I spent a substantial fraction of my professional career writing C, and I remain interested in WG14 (the language committee) and in several projects written in C though I a…
> I'm sure I'm not alone - after decades - already knowing far too much about C, so that any article I'm likely to read either I'm like "No, that's wrong and I even understand why you thought that, but it's still wrong" or I just nod along and sigh. If you have some spare time, I would really like to hear more about your experiences. It sounds like you have worked with C for a long time, and that kind of insight is h…
Am I old? I am 31, and I started with C around age 14 (writing mods for ioquake3 forks), been my most used programming language ever since.
Earlier quoted context omitted.
I'm no expert on Zig, but "comptime" is the keyword to trigger it.
I'm pretty sure the "comptime" keyword only forces you to provide an argument constant at compile time for that particular parameter. It doesn't trigger the compile time evaluation.
Earlier quoted context omitted.
D's `write` function is generic: write(1,2,"abc",4.0,'c'); write is declared as: void write(S...)(S args) { ... } where `S...` means an arbitrary sequence of types represented by `S`. The implementation loops over the sequence, handling each type in its own individual fashion. User defined types work as well.
If D has a separate feature for one of: generic types, interfaces and macros, then obviously it doesn't use partial evaluation similarly to how Zig does. It seems to me that it has all three: templates, interfaces, and string mixins. So if Zig uses its unified partial evaluation feature to eliminate these three separate features, why bring up D, which clearly does not eliminate any one of them? It's like saying the t…
Earlier quoted context omitted.
If D has a separate feature for one of: generic types, interfaces and macros, then obviously it doesn't use partial evaluation similarly to how Zig does. It seems to me that it has all three: templates, interfaces, and string mixins. So if Zig uses its unified partial evaluation feature to eliminate these three separate features, why bring up D, which clearly does not eliminate any one of them? It's like saying the t…
If you have an example of what you're talking about, I'd like to see it.
> Zig for ( 0..9 ) |i| { } > C for (i = 0; i I know an open interval [0..9) makes sense in many cases, but it's counterintuitive and I often forget whether it includes the last value or not. It's the same for python's range(0, 9).
I completely agree. One of Zig's big competitors, Odin, has a more explicit syntax for this where `0..<5` is an open interval and `0...5` is closed.