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

221–230 of 290 posts

Re: Problems of C, and how Zig addresses them

#221

Post by rixed »

tialaramex wrote: post #123
flohofwoe wrote: post #74

Earlier quoted context omitted.

Technically that's true because of the "C virtual machine", but pragmatically, C is still the "lowest-level high-level programming language" at least among the popular programming languages (arguably only Forth is lower level, but Forth isn't exactly mainstream). (and I'd argue that C is closer to assembly than assembly is to what's actually happening inside the CPU, e.g. assembly itself is a high-level abstraction l…

You're thinking of the C abstract machine, not a virtual machine. Abstract art is when this is a painted blue circle but it's about the feeling of sadness when losing somebody close to you - virtual art is when somebody persuades you a crappy GIF of a monkey is worth a million dollars. And no, it's just not usefully true to model things this way. The C abstract machine is pretty weird even compared to a PDP-11, and y…

Assembler has types : bytes, words, floats, addresses, even strings and "functions". They are easily worked around by design though, in similar ways in assembler and C.

Re: Problems of C, and how Zig addresses them

#222

Post by earthboundkid »

Cloudef wrote: post #207
travisgriggs wrote: post #18

Tangentially... I'm grateful that these new batches of systems languages have chosen to use the u8, i32, etc, style integer types. Rather than the uint8_t and int32_t style. First thing I do in any of my low level embedded C projects is put in the various uNN/iNN types.

What I'm really waiting for is zig support for custom range ints https://github.com/ziglang/zig/issues/3806 Also minor nitpick I have is that the interval/range syntax in zig is pretty confusing as it can be both inclusive and exclusive depending on context. Swift does it imo better by ... being inclusive and ..< exclusive

I was surprised they didn’t copy Swift on this. It seems just obviously better than two dots.

Re: Problems of C, and how Zig addresses them

#223

Post by manicennui »

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?

Because this is Hacker News, not corporate blub news. JFC

Re: Problems of C, and how Zig addresses them

#224

Post by naasking »

staunton wrote: post #177
naasking wrote: post #150

Earlier quoted context omitted.

A prefix and a namespace aren't really that different in practice.

They are different. Namespaces are syntactically enforced and you can opt-in or out to names. To have syntactically validated qualified access. Naming might go well and have the same utility, but you never know what evil things are going on in all those headers, redefining each other's symbols and yours.

You seem to be focusing on specific problems with C/C++. I don't really care about that, all I'm saying is that prefixing names are equivalent to placing them within a namespace, in practice, and theoretically come to think of it. You can easily define a bijection between namespaced symbols and prefixed symbols. Requiring the full prefixes are simply a tad more verbose, essentially equivalent to using a fully qualified name for symbol.

Re: Problems of C, and how Zig addresses them

#225

Post by naasking »

justinpombrio wrote: post #168
naasking wrote: post #148

Earlier quoted context omitted.

I think operator overloading should be fine even for puritans, as long the language requires the type to be numerical in a strict sense, and so they have a well defined semantics. So integers, floating point, complex numbers, vectors, matrices, etc.

How would the language require it to be numerical? For example, if you're defining complex numbers in a library, what would the compiler be checking about your ComplexNumber type before allowing you to define `+` for it?

A few ways. The compiler could enforce commutativity, associativity and other properties of those operators.

Another possible route is to require that all types contained within the exported types are also numerical, or have some specific set of operators defined.

Re: Problems of C, and how Zig addresses them

#226

Post by naasking »

throwawaymaths wrote: post #184
naasking wrote: post #148

Earlier quoted context omitted.

I think operator overloading should be fine even for puritans, as long the language requires the type to be numerical in a strict sense, and so they have a well defined semantics. So integers, floating point, complex numbers, vectors, matrices, etc.

The problem with operator overloading is not really numericity, IMO. The problems are: - hidden control flow (function calls should look like function calls, an operation should never mask a function call) - global weirdness. If a library changes the language, how does that affect some other code you're pulling in? Where do you effect those changes?

> - hidden control flow (function calls should look like function calls, an operation should never mask a function call)

You can restrict operator definitions to expressions containing other operators. Operators are now guaranteed to expose only as much control flow as the underlying operators would already expose.

> - global weirdness. If a library changes the language, how does that affect some other code you're pulling in? Where do you effect those changes?

I'm not sure what you mean. Behaviour depends on language semantics. You don't specify why operators are uniquely weird on this compared to literally any other function call when language semantics or library behaviour changes.

Re: Problems of C, and how Zig addresses them

#227

Post by kevin_thibedeau »

pornel wrote: post #195
pavlov wrote: post #125

Earlier quoted context omitted.

The preprocessor doesn’t know that u32 defined in foo.h is the same type as u32 defined in bar.h. So you’ll get an error when importing both.

If C made this change, it could also make it legal to redefine u32 etc as appropriate integer types any number of times without erring.

This would break legacy code. I had one employer with a bool type that was a 32-bit integer because of obscure alignment issues. This is why _Bool exists and the bool typedef has to be brought in explicitly with stdbool. You can't just go and usurp popular short type names. The standard reserved *_t and _[A-Z].+ for this purpose. People have been writing portable code with the expectation that future standards aren't going violate that promise and break things.

Re: Problems of C, and how Zig addresses them

#228

Post by thayne »

> Nothing allocates on the heap, without you knowing it and letting it happen. Zig utilizes the Allocator type to achieve this. Any function that allocates on heap receives an Allocator as parameter. Anything that doesn't do so won't allocate on heap, guaranteed.

That might be true for the standard library, but it is definitely possible for a function to use an allocator from a struct or a global. Not to mention calling a c function that allocates.

> Safety tools to avoid memory leaks e.g. std.heap.GeneralPurposeAllocator

Maybe I'm missing something, but AFAICT, that doesn't prevent memory leaks, it just has the ability to log if there were leaks. Like a built-in valgrind.

> [Zig] helps your remain safe and avoid leaks

So it talks a little about how to _identify_ memory leaks, at runtime. Which is also possible in C with tools like valgrind. But it doesn't mention defer, which is an advantage zig has over c (at least portable c) for memory management. And it doesn't talk about the "safe" part at all, which I would take to mean protections against use-after-free, double-free, unitialized variables, invalid free, etc.

Re: Problems of C, and how Zig addresses them

#229

Post by [deleted] »

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?

[deleted]

Re: Problems of C, and how Zig addresses them

#230

Post by throwaway17_17 »

kristoff_it wrote: post #131
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. - Tiger…

Do you know of any in depth reviews of Zig’s async implementation? It would be great to see a walk through of the choices and decisions made along the road to the final version.
Post reply on HN