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

231–240 of 290 posts

Re: Problems of C, and how Zig addresses them

#231

Post by WalterBright »

vore wrote: post #212
WalterBright wrote: post #206

Earlier quoted context omitted.

The size of `byte` is fixed at 8, `short` 16, `int` 32, `long` 64. There is no ambiguity or uncertainty about it.

At that point, why not just call them i/u8/16/32/64? If the sizes are fixed anyway, why come up with different names for them, especially when almost all of the times you would want to select a different integer type is specifically because of how many bits wide it is? (otherwise, surely you would just use the machine word size?)

Good question.

1. After 5 minutes, you know what sizes they are, and don't need reminding.

2. Easier to touch type.

3. They're just aesthetically more pleasing to the eye.

4. The names aren't really different, they follow the most-used (by far) sizes on C.

5. It's easier to say and hear them. I can say "int" when talking code with someone, instead of "eye-thirty-two".

6. I'm guessing it may be easier for a visually impaired coder with a screen reader.

Re: Problems of C, and how Zig addresses them

#232

Post by anon-3988 »

Dwedit wrote: post #97

One thing Zig is missing is Exception Handling. Now before you complain about exception handling grossly bloating the size of a program, know that there are ways to trigger exceptions that do not involve the "throw" keyword. You get processor exceptions when you access a bad pointer, divide by 0, etc. If you don't want the program to instantly terminate, you need to be able to handle those exceptions. So far, it seem…

I am curious why anyone still thinks that exception is superior/better/desirable than a simple typed functions (like Result or Option).

> You get processor exceptions when you access a bad pointer, divide by 0, etc. If you don't want the program to instantly terminate, you need to be able to handle those exceptions.

The processor does a lot of other things too, all of these functions can simply be wrapped with the appropriate Result and Option. Hell, I'd argue that for a system programming language all mathematical operations should return Result.

How is a try/catch better than a pattern match on the exact errors that you care about? inb4 checked exception, which is just an inferior version of algebraic data types.

Re: Problems of C, and how Zig addresses them

#233

Post by brabel »

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

Groovy has had that syntax for much longer than Swift has existed... Groovy normally copies features from Ruby/Python/SmallTalk so I would think one of those are the source for this syntax.

Re: Problems of C, and how Zig addresses them

#234

Post by brabel »

WalterBright wrote: post #103
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.

D uses byte, short, int, long for i8, i16, i32, i64, and ubyte, ushort, uint, and ulong for the unsigned versions. After 5 minutes with the language there is no longer any point to emphasizing the number of bits. Besides, they're just easier to touch type.

But Zig lets you use arbritary number of bits... you can write `i4` for example, or `u120` or whatever, which is a pretty great advantage.

Re: Problems of C, and how Zig addresses them

#235

Post by Klonoar »

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?

One thing nobody has pointed out yet - and this is not a knock on any language whatsoever but moreso a commentary on HN itself, so take it with a grain of salt, but: if you've followed this site since the beginning, programming languages cycle through here with a hype phase every few years like clockwork.

The one most people jump to from the past few years is Rust and/or Go, but we've experienced this with other languages like Lisp (& variants), Haskell, Scala had a small window, etc. Zig will no doubt have its own moment like this (if it's not already), and then the hype cycle will settle into wherever Zig is used best.

Think of it like a magnifying lens on overall programmer sentiment/interest.

Re: Problems of C, and how Zig addresses them

#236

Post by pjmlp »

renox wrote: post #145
pjmlp wrote: post #129

Earlier quoted context omitted.

The problem is that Zig is basically Modula-2 for C syntax lovers, plus metaprogramming. It is hardly safer than Modula-2 already was over C already in 1978. We are in 2023 now.

You're right, but it doesn't matter: Modula-2 didn't catch up, Zig has a small chance to succeed thanks to its focus on embedded and on its good tooling for cross-compilation.

Only makes sense if they fix the remaining security flaws, otherwise it hardly changes the stance that S stands for security in IoT.

Re: Problems of C, and how Zig addresses them

#237

Post by pjmlp »

pavlov wrote: post #31
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.

The C standard effectively can’t add new types without the “_t” suffix, so they’re stuck with limitations that a brand new language won’t have.

They added new keywords just fine, even if it needs a trasition phase to go through them.

Re: Problems of C, and how Zig addresses them

#238

Post by pjmlp »

flohofwoe wrote: post #70
pitaj wrote: post #68

Earlier quoted context omitted.

Can't they add a new header file?

What if a library API needs to include this new header because it wants to use the new typedefs in its API declarations but your own code (which needs to include the library header) also has its own 'u8' typedefs? (PS: it's probably ok because C compilers seem to accept redundant typedefs)

Same reasoning applies to new keywords.

Re: Problems of C, and how Zig addresses them

#239

Post by vanderZwan »

rixed wrote: post #216
matklad wrote: post #28

Earlier quoted context omitted.

As counter point, the way that Zig implements hash maps is absolutely instrumental for TigerBeetle. Zig hashmaps _are_ quite a bit more cumbersome than, eg, in Rust --- you need to decided whether you want the allocator to be bundled with the hasmap, and its also up to the user of the hash map to provide equality and hash code (and, of course, there's manual defer instead of RAII). However, this flexibility and verbo…

The hash map I'm used to in C uses intrusive lists so it's pretty much allocation free. Would they fit the bill?

"Pretty much" is great in most contexts, but in this one I think GP is pretty darn strict about having absolutely zero dynamic allocations

Re: Problems of C, and how Zig addresses them

#240

Post by pjmlp »

saagarjha wrote: post #204
kristoff_it wrote: post #131

Earlier quoted context omitted.

> 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…

Apple shipped a LLVM cross-compiler for Apple silicon on day one? Not entirely sure what you mean here.

Somehow no one managed to make cross-compilers work, even though it is the standard way of working in embedded and game consoles for decades.
Post reply on HN