Live data from Hacker News

Why is Zig so cool?

nilostolte.github.io

461–470 of 527 posts

Re: Why is Zig so cool?

#461
post #396

Earlier quoted context omitted.

> Calling into malloc () is writing C in C++, and should only be used for backwards compatibility And this is exactly the stance I am arguing against. C++ is not the newer version of C. It forked of at some point and is a quite different language now. One of the reasons I do use malloc for, is for compatibility with C. It is not for backward compatibility, because the C code is newer. In fact I actively change the co…

So it would fail to compile when configuring static analysis to build on error when using C with C++ compiler. Finally, people like to argue between C and C++ when it convenient to do so, yet the compiler language switches to use C extensions in C++ mode keep being used across many projects.

You can write Objective-C and C++ in the same source file, even mixing them in the same line of code, and it compiles together, but no one can say these are not two very different languages.

Re: Why is Zig so cool?

#462
post #458

Earlier quoted context omitted.

It violates one of zigs principle of no hidden control flow

If exceptions count as hidden control flow because suddenly a function call can jump to a `catch` block, then defer absolutely counts as hidden control flow because suddenly the end of your function jumps to a `defer` block defined at an arbitrary point higher up. If Zig wanted to be consistent with its own philosophy, it would require some sort of keyword at the end of every scope to indicate that a defer was happen…

It's not the same, defer does not conditionally interrupt the flow of execution, it will always run at the end of a block. If I see a defer, I am absolutely certain that whatever is deferred will run. The same is not true for exceptions. If I am not mistaken defer just moves the code at the end of the block, no jumping is involved.

Re: Why is Zig so cool?

#463

In my opinion the biggest issue of Zig is that it doesn't allow attaching data to error. The error can only be passed via side channel, which is inconvenient and ENOURAGES TOOL DEVELOPERS TO NOT PASS ERROR DATA, which greatly increase debugging difficulty. Somethings there are 100 things that possibly go wrong. With error data you can easily know which exact thing is wrong. But with error code you just know "somethin…

Yeah, every single newbie programming language designer starts with a maximalist position of "exceptions are hard, just return an error code", and then end up inventing their own shitty, ad-hoc and malfeatured exception handling system. I want off this ride.

Go seems to do alright without exceptions. It’s just a convention to return errors, which seems fine as a practice.

Re: Why is Zig so cool?

#464
post #373

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…

Thanks for sharing your thoughts. I have never deployed any production C code and I would not choose C for professional work either, but learning it, with all its rough edges, has made me a better engineer. It helps me understand how things really work under the hood. No pain, no gain. Maybe I am biased, but for professional work, I stay with Go. I have built large distributed data systems that handle hundreds of mil…

> I still write about C anyway. It may not trend, but it lasts.

> I have never deployed any production C code and I would not choose C for professional work either

What do you write about C, if not for practical usage in the industry? Can you post some links?

FWIW, since you seem interested, here are some blog posts of mine specifically about practical usage of C, some of which got a little discussion here on HN in the past:

https://www.lelanthran.com/chap13/content.html

https://www.lelanthran.com/chap9/content.html

https://www.lelanthran.com/chap5/content.html

Re: Why is Zig so cool?

#465
post #374

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…

> It sounds like you have worked with C for a long time, and that kind of insight is hard to find now.

I've already replied to you in a sibling post, but I have been writing in C since the mid-90s; there's really not that much insight you get specifically to C.

Re: Why is Zig so cool?

#466

Earlier quoted context omitted.

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'm assuming you're talking about the "managed" pattern you'd see in stuff like Hashmaps and ArrayLists. To my knowledge that style is falling out of favor, and I think the managed versions will be removed from the standard library. 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 pa…

If you're a library writer, then don't make a global allocator. If you aren't, then do whatever you feel like.

Re: Why is Zig so cool?

#467
post #256

Earlier quoted context omitted.

TigerBeetle has a clear purpose and needed those brilliant optimizations. Do you think Zig is suitable as, say, a Go replacement for prod network services and such? Aside from the fact that Zig is still a bit immature in its std library and ecosystem, I mean. Is it a suitable systems language going forward?

Thanks! Zig is actually perfect for production network services (that’s all TB is essentially, or how I see it, and what I was looking for in Zig—how to create something with explicit limits that can handle overload—it’s hard to build anything production-grade if it’s not doing NASA’s Power of Ten and getting allocation right—GC is not a good idea for a network service). I wouldn’t say Zig’s std lib is immature. Or i…

That's great feedback. Many of us are looking at the next 5-10 years of building network services. Go has its share of issues that simply won't go away. Rust is overly complex ("concept fatigue"). Python will remain slow. So here comes Zig with massive potential and the ecosystem and community is really engaging.

Re: Why is Zig so cool?

#468
post #33

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…

Yeah, the real strength of Zig isn't what's there, but what isn't.

OK, but this is true for most younger languages. The older they get, the more they tend to accumulate.

Check back in on Zig after another decade.

Re: Why is Zig so cool?

#469
post #351

Earlier quoted context omitted.

This sound a bit like Tanenbaum's rejection of Torvals' project, because monolithic kernels are obsolete.

Most OSes use either hybrid kernels, or type 1 hypervisors, which are microkernels by another name.

If 10% of your OS code is in a small piece that might be called a microkernel, and 90% is in one huge blob that implements everything else, then you don't really have a microkernel OS.

Or to phrase that more directly at the point: for monolithic kernels to be obsolete you have to break up the monolithic part, not just shim a microkernel hypervisor on top of it.

Re: Why is Zig so cool?

#470
post #312

Earlier quoted context omitted.

Went to have a look to the (beautiful and informative) website for the raku language to refresh my memory, and looking at the examples I though "Oh god, those sigills, those criptic short keywords... it looks like a modern perl, I doubt we would be happy together", then I went to wikipedia to check and yes indeed, that's perl 6! I'll pass. :)

Thanks for the feedback on the raku.org site. We like sigils $ for one thing (scalar), @ for many things (array) and % for dictionaries (hash). The linguistic idea is that such words stand out as “nouns” in contrast to all the routine names which are “verbs”. In practice, after you get familiar, it really helps code to be written in an expressive way to better convey the intent. Sure, if sigils makes you glaze over t…

Sigils are just one of the things that concern me (use of UTF-8 character for keywords is another one).

The problem with sigils is that they compose poorly when casting (refs, counts), and do not generalize to other types.

Plus, they seem to encourage the language designers to implement semantic that is "context aware" which would have been another billion dollars mistake if perl had become more popular.

In other words, that's unnecessary complexity bringing the attention to a poor type system. A bad idea that deserves to die, in my opinion.

Post reply on HN