Live data from Hacker News

Why is Zig so cool?

nilostolte.github.io

351–360 of 527 posts

Re: Why is Zig so cool?

#351

While some of the features the author references are really interesting, personally I don't see how any of that would justify creating a new memory unsafe language in 2016. I thought it was pretty obvious by now [1][2][3] memory safety is best left to tooling / compilers and not to programmers. [1] https://research.google/pubs/secure-by-design-googles-perspe... [2] https://www.microsoft.com/en-us/msrc/blog/2019/07/we…

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.

Re: Why is Zig so cool?

#352
post #115

Earlier quoted context omitted.

Adopted from go, first appeared in D, invented by one of its major developers, Andrei Alexandrescu.

I vaguely remember reading somewhere recently that Andrei left the D community / foundation. Do you know if that is true?

He's moved on: https://research.nvidia.com/person/andrei-alexandrescu

Re: Why is Zig so cool?

#353

I love systems programming language and have worked on the Ada language for a long time. I find Zig to be incredibly underwhelming. Absolutely nothing about it is new or novel, the closest being comptime which is not actually new. Also highly subjective but the syntax hurts my eyes. So I’m kind of interested by an answer to the question this articles fails to answer. Why do you guys find Zig so cool ?

It gets hyped by a few SV influencers.

Re: Why is Zig so cool?

#354
post #341

Earlier quoted context omitted.

Have you tried C23, especially its new Unicode support? It really surprised me after returning to C more than ten years later. You can now write wide and UTF-8 string literals directly: char8_t* s = u8"こんにちは"; char16_t* t = u"Привет"; char32_t* ustr = U"你好"; It just works across compilers, no special libraries or hacks needed. C still feels like C, but cleaner, safer, and more consistent.

I abandoned the goal of investing More time into C when they couldn't get defer into their latest version. 2 years later, already enjoying it in Zig `defer` is a lot less important to me now. But I still view it as a symptom of the death of the language. C isn't dead, by any stretch of the imagination, but it's no longer learning from it's mistakes, where as I still am.

I started learning C again for one simple reason: to understand the Linux kernel. You cannot do that without knowing C, and soon you end up learning about GCC, linkers, and how programs really run.

Once I spent time with it, I saw how many smart ideas from the kernel could be used anywhere. the initcall system that runs modules in order, the way structs with function pointers create flexible drivers, the use of macros to build type-safe lists and so on.

https://www.collabora.com/news-and-blog/blog/2020/07/14/intr...

For real work, though, life is short. I use Go.

Re: Why is Zig so cool?

#355

I love systems programming language and have worked on the Ada language for a long time. I find Zig to be incredibly underwhelming. Absolutely nothing about it is new or novel, the closest being comptime which is not actually new. Also highly subjective but the syntax hurts my eyes. So I’m kind of interested by an answer to the question this articles fails to answer. Why do you guys find Zig so cool ?

It’s hard to do something that is truly novel these days. Though I’d argue that Zigs upcoming approach to Async IO is indeed novel on its own. I haven’t seen anything like it in an imperative language.

What’s important is the integration of various ideas, and the nuances of their implementation. Walter Bright brings up D comptime in every Zig post. I’ve used D. Yet I find Zigs comptime to be more useful and innovative in its implementation details. It’s conceptually simpler yet - to me - better.

You mention Ada. I’ve only dabbled with it, so correct me if I’m wrong, but it doesn’t have anything as powerful as Zigs comptime? I think people get excited about not just the ideas themselves, but the combination and integration of the ideas.

In the end I think it’s also subjective. A lot of people like the syntax and combination of features that Zig provides. I can’t point to one singular thing that makes me excited about Zig

Re: Why is Zig so cool?

#356
post #254

Earlier quoted context omitted.

> Also, a line number is often helpful That's not error data, that's (one level of) a stack trace. And you can do that in zig, but not by putting call stack data into error return codes. The conflation between exception handling and error flagging (something that C++ did largely as a mistake, and that has been embraced by managed runtimes like Python or Java) is actually precisely what this feature is designed to unt…

> That's not error data, that's (one level of) a stack trace. They're not talking about the stack trace, but about the common case where the error is not helpful without additional information, for example a JSON parsing library that wants to report the position (line number) in the string where the error appears. There's no way of doing that in Zig, the best you can do is return a "ParseError" and build you own, non…

Another way to look at this example is that, for the parser, this is not an error. The parser is doing its job correctly, providing an accurate interpretation of its input, and for the parser, this is qualitatively different from something that prevents it doing its job (say, running out of memory).

Re: Why is Zig so cool?

#357
post #8

A neat little thing I like about Zig is one of the options for installing it is via PyPI like this: https://pypi.org/project/ziglang/ pip install ziglang Which means you don't even have to install it separately to try it out via uvx. If you have uv installed already try this: cd /tmp echo '#include int main() { printf("Hello, World!"); return 0; }' > hello.c uvx --from ziglang python-zig cc /tmp/hello.c ./a.out

That's a nice trick!

Re: Why is Zig so cool?

#358

Earlier quoted context omitted.

The Rust standard library in its default config should not be used if you care about code size (std is compiled with panic/fmt and backtrace machinery on by default). no_std has no visible deps besides memcpy/memset, and is comparable to bare metal C.

I understand this, but that is a pain that you don't get with Zig. The no_std constraint is painful to deal with as a dev even with no dependencies and also means that if you're working on a target that needs small binaries, that the crates.io ecosystem is largely unavailable to you (necessitating filtering by https://crates.io/categories/no-std and typically further testing for compilation size beyond that). Zig on…

Rustc does a good job of removing unused code, especially with LTO. The trick is to make sure the std library main/panic/backtrace logic doesn't call code you don't want to pay for.

IIRC there's also a mutex somewhere in there used to workaround some threading issues in libc, which brings in a bespoke mutex implementation; I can't remember whether that mutex can be easily disabled, but I think there's a way to use the slower libc mutex implementation instead.

Also, std::fmt is notoriously bad for code size, due to all the dyn vtable shenanigans it does. Avoid using it if you can.

Regardless, the only way to fix many of the problems with std is rebuilding it with the annoying features compiled out. Cargo's build-std feature should make this easy to do in stable Rust soon (and it's available in nightly today).

Re: Why is Zig so cool?

#359
post #328

Earlier quoted context omitted.

I mostly write C, but yes even a simple call to e.g. malloc has different semantics in C++ (you need to cast).

Proper C++ should use new , delete , custom allocators, and standard collection types. Even better, all heap allocations should be done via ownership types. Calling into malloc () is writing C in C++, and should only be used for backwards compatibility with existing C code. Additionally there is no requirement on the C++ standard that new and delete call into malloc() / free() , that is usually done as a matter of co…

> 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 code, when it needs a rewrite anyway, from C++ to C.

The other reason for using it even when writing C++ is, that new alone doesn't allow to allocate without also calling the constructor. For that I call malloc first and then invoke the constructor with placement new. For deallocating I call the destructor and then free. This also has the additional benefit, that your constructor and deconstructor implementation can fail and you can roll it back.

Re: Why is Zig so cool?

#360
post #333

Earlier quoted context omitted.

I've learnt this the hard way. The most important thing is to get you to click. Sometimes I'll first iterate over the title before even writing on substack.

I have learned that too. If you write about C, almost no one clicks. It is not new, it is not flashy, and it does not promise easy results. Yet almost everything still runs on it. The quiet parts of computing rarely get attention, even though they keep everything working. I still write about C anyway. It may not trend, but it lasts.

An alternative view of "not new and flashy" is "known and expected", which not 100% of C conversations have to be. Just look at the excitement around Fil-C lately!
Post reply on HN