Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Problems of C, and how Zig addresses them

avestura.dev

Post reply on HN
Print view View original

131–140 of 290 posts

Re: Problems of C, and how Zig addresses them

#131

Post by kristoff_it »

andrewedstrom wrote: post #112

I remain confused about how Zig makes it to the front page of Hacker News so often. As far as I know, no one is using it in production after 7 years of development. Are people just really excited about this project? Are the people behind it just really good at marketing? Honest question: why do we all keep talking about Zig?

> As far as I know, no one is using it in production after 7 years of development.

- Uber uses Zig to produce hermetic builds of their backends and was able to move their C/C++ codebases to arm64 thanks to Zig's C/C++ cross-compilation support.

https://www.uber.com/en-US/blog/bootstrapping-ubers-infrastr...

- Bun is written in Zig and its sudden success was big enough to cause Deno to have an identity crisis.

- TigerBeetle is written in Zig and it's probably the most promising upcoming database company out there.

- There are a few more notable examples, but I haven't been given permission to talk about them publicly yet.

> Honest question: why do we all keep talking about Zig? > Are the people behind it just really good at marketing?

The project is simply inherently interesting. For one reason or another, nobody figured out a proper build & cross-compilation experience for C/C++ before Zig did it, just like nobody has figured out a good package manager yet for C/C++ and we're about to do it.

When Apple Silicon came out Zig was the first compiler able to cross-compile for it (way before LLVM btw) thanks to our custom linker, and thanks to it and the fact that we're working on our own custom backends, we're also going to achieve incremental compilation with in-place binary patching, ultimately reducing linking time to basically zero for incremental rebuilds.

Zig is also the only language that has async/await but that doesn't have an ugly & wasteful split between blocking and evented versions of the same networking library.

I'm stopping here with technical arguments, but there would be more to talk about.

Lastly and most importantly, the project has an interesting approach to finances and governance: we've had a non-profit foundation for longer than Rust and we have made a point to never, ever, let big tech companies influence the governance of Zig.

The Zig Software Foundation pays its developers (instead of hiring copywriters & marketing people) and 90+% of what we make through donations or support contracts goes to developers. The rest is infrastructure and administrative costs (eg CI, accountant).

I'm the guy who's most in charge of marketing and I'm currently working on the automated documentation system because Zig pretty much markets itself.

Re: Problems of C, and how Zig addresses them

#132

Post by menaerus »

jorangreef wrote: post #48
sfpotter wrote: post #38

C is standardized and is one of the most (the most?) widely used programming language on the planet. If you write code targeting a C standard and don't include many unstable dependencies, it has a good chance of running correctly for a very long time. If you move from C to Zig, you lose that stability. Are Zig's convenience features really enough to compensate for this loss?

One of the main reasons, in fact, that we picked Zig for TigerBeetle (over C, which was the alternative, given we needed to handle memory allocation failure), was because of Zig's excellent interoperability with the C ABI. For example, we write the reference TigerBeetle client implementation completely in Zig, then wrap this with the C ABI, and then bind to this C ABI from all target languages, to increase our veloci…

> given we needed to handle memory allocation failure

Isn't it that the OOM killer is likely to be a much bigger problem? With the overcommit enabled and OOM enabled I don't think I can envision the case where you would run into a failed allocation - allocations on Unices practically never fail. It is the OOM-killer that will likely kill your process once it detects that the pressure on your ram+swap is high so you won't even have a chance to run into the OOM.

OTOH if you disable the OOM-killer there's another and much bigger problem to solve - a kernel panic. I guess that's not the condition you want your system to run into.

So, I think that the only combination where you can deterministically detect and run into allocation failures is when both OOM-killer and overcommit are disabled. That's what I think Windows is doing by default.

Re: Problems of C, and how Zig addresses them

#133

Post by xgkickt »

flohofwoe wrote: post #86
pixelpoet wrote: post #83

I'm super sold on Zig except that it doesn't make graphics/vector coding with operator overloading possible :( I've heard what Andrew Kelley has to say about it ("that ONE little feature from C++...") but it's just a very sad situation for what otherwise looks like a lovely basis for graphics coding. Actually, I don't even want operator overloading in general (leading to stuff like the C++ stream API), it's JUST for…

+1 (don't want general operator overloading, but a more powerful @Vector builtin type, basically Clang's ext_vector_type: https://clang.llvm.org/docs/LanguageExtensions.html#vectors-... ), plus maybe a similar @Matrix builtin up to 4x4.

Are Clang’s builtin types interoperable with __m128 intrinsics?

Re: Problems of C, and how Zig addresses them

#134

Post by v4vvdq »

LexiMax wrote: post #78

One thing that was unclear to me based on my prior noodling with Zig was what the plans were for supporting interface or trait-based polymorphism. I've been falling in love with C++'s std::experimental::is_detected and am looking forward to being allowed to use C++20 in my environment since it will bring Concepts, but in my cursory examination it seems Zig seems to prefer vtable abstractions like Allocator.VTable.

Zig does have some kind of interfaces, check [1]. I am interested to learn, how Traits in Rust and Interfaces in Go behave differently from this concept.

[1] https://github.com/ratfactor/ziglings/blob/main/exercises/09...

Re: Problems of C, and how Zig addresses them

#135

Post by quic5 »

pixelpoet wrote: post #83

I'm super sold on Zig except that it doesn't make graphics/vector coding with operator overloading possible :( I've heard what Andrew Kelley has to say about it ("that ONE little feature from C++...") but it's just a very sad situation for what otherwise looks like a lovely basis for graphics coding. Actually, I don't even want operator overloading in general (leading to stuff like the C++ stream API), it's JUST for…

Not all that useful but fun: you can implement swizzling with comptime

Re: Problems of C, and how Zig addresses them

#136

Post by Gibbon1 »

flohofwoe wrote: post #86
pixelpoet wrote: post #83

I'm super sold on Zig except that it doesn't make graphics/vector coding with operator overloading possible :( I've heard what Andrew Kelley has to say about it ("that ONE little feature from C++...") but it's just a very sad situation for what otherwise looks like a lovely basis for graphics coding. Actually, I don't even want operator overloading in general (leading to stuff like the C++ stream API), it's JUST for…

+1 (don't want general operator overloading, but a more powerful @Vector builtin type, basically Clang's ext_vector_type: https://clang.llvm.org/docs/LanguageExtensions.html#vectors-... ), plus maybe a similar @Matrix builtin up to 4x4.

Maybe I'm small brained but built in vector types align with heavily platform optimized libraries. Meaning you don't want this stuff implemented in the compilers front end. You want it handled in the compilers back end.

Re: Problems of C, and how Zig addresses them

#138

Post by 8n4vidtmkvmk »

menaerus wrote: post #111
matklad wrote: post #59

Earlier quoted context omitted.

That's not quite it: with heapless, memory is fully static, the size of hash map is a compile-time parameter, which is a part of HashMap's type. In Zig, the map could be initialized and sized at runtime, but you still can enforce, statically, that it doesn't do any allocations after that. In both nightly Rust and Zig, heapless version can be expressed by passing a fixed-buffer-backed allocator to the standard hash ma…

I don't quite understand how do you change the size of a zig hashmap in runtime by, for example, inserting 1M items at some point but at the same time being able to enforce in compile-time that such operation will not result with dynamic allocation?

I don't know, but you could avoid resizing the hashmap and allow the collisions but then your buckets would still need resizing

Re: Problems of C, and how Zig addresses them

#139

Post by IshKebab »

coliveira wrote: post #98
xigoi wrote: post #65

Earlier quoted context omitted.

In C, unlike pretty much every other language, you can't even know how big an integer is.

Of course you can, but this is implementation defined. So you need to create code that does different things based on the underlying implementation. Every reasonably large C code base checks the current implementation to define what type of integers, pointers, etc. they're dealing with. This is by design, because C was created do deal with disparate processors and OSs. When it was crated it would be difficult and unw…

> When it was crated it would be difficult and unwise to assume that an integer has size of 2 bytes

It was still a bad design. Of course this is in hindsight, but history has taught is it would have been much better if the default was for specific sized integers, with an option to use `uint_fast32_t` or whatever.

Re: Problems of C, and how Zig addresses them

#140

Post by square_usual »

jstimpfle wrote: post #56
square_usual wrote: post #27

You can repeat "C is a minimal abstraction over assembly" as many times as you want, it doesn't make it true.

May I suggest you give arguments why it is not (and why we should care about those arguments from a practical standpoint), and what language should better earn the title?

Others have already made a few in response, but for reference, this ACM queue article [1] is a good place to start. It has been widely discussed both on HN and elsewhere, and a simple search of the title can bring up several counter-arguments etc. if you're interested and want to know more.

> what language should better earn the title?

None.

1: https://queue.acm.org/detail.cfm?id=3212479

Post reply on HN