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

211–220 of 290 posts

Re: Problems of C, and how Zig addresses them

#211

Post by coliveira »

IshKebab wrote: post #139
coliveira wrote: post #98

Earlier quoted context omitted.

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.

History says otherwise: C was so successful it is still widely used.

Re: Problems of C, and how Zig addresses them

#212

Post by vore »

WalterBright wrote: post #206
saagarjha wrote: post #201

Earlier quoted context omitted.

Sure there is: when I’m parsing or serializing something it’s pretty important I know what size something is.

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?)

Re: Problems of C, and how Zig addresses them

#213

Post by avgcorrection »

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…

Mathematics is such an unprincipled mess of DSLs. I wonder why math domains always come up as the sticking point with the caveat of “but not operators for anything else, though”.

It would be nice, for sure, to be able to define some infix combinators.

Anyway, it’s bad enough that arithmetic has pressured almost all programming languages to adopt operator precedence. (No operator precedence other than either go-left or go-right is so much simpler. Which would also mitigate some of the complaining about custom operators since then they just become infix functions.)

Re: Problems of C, and how Zig addresses them

#214

Post by throwawaymaths »

kps wrote: post #192
throwawaymaths wrote: post #190

Earlier quoted context omitted.

You sure the compiler doesn't inline it? That an operator might take more than one opcode I think is uncontroversial

Multiplication takes more than a handful of instructions if the hardware doesn't do it. https://godbolt.org/z/ccYPaz1Pj For this example (AVR), this is the int multiply function __mulhi3: 00: 00 24 eor r0, r0 02: 55 27 eor r21, r21 04: 00 c0 rjmp .+0 06: 08 0e add r0, r24 08: 59 1f adc r21, r25 0a: 88 0f add r24, r24 0c: 99 1f adc r25, r25 0e: 00 97 sbiw r24, 0x00 10: 01 f0 breq .+0 12: 76 95 lsr r23 14: 67 95 ror r2…

I mean, pedantically speaking the normal zig operators do control flow in their operators, in checked mode they panic on overflow, etc (you're not supposed to recover from them but I suppose it's possible). There's probably (internal) control flow in the saturating operators, etc.

Re: Problems of C, and how Zig addresses them

#215

Post by avgcorrection »

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)

An operator is either a function call or some simple built-in operation.

Thus not hidden.

That syntactic elements that consist of symbols rather than alnum and that are used as prefix or infix operators are necessarily “not a function call” is just a rule that can be changed.

Re: Problems of C, and how Zig addresses them

#216

Post by rixed »

matklad wrote: post #28
bodge5000 wrote: post #7

I'm no expert on either languages, but I tried Zig for the first time properly the other day. I really liked it up until I hit hashmaps. One thing that I think goes under-appreciated about C (and other languages with a similar paradigm) is thats its pretty upfront and clear about what it can and can't do out of the box. If you want hashmaps in C, you need to create your own implementation, otherwise think of a way ro…

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?

Re: Problems of C, and how Zig addresses them

#217

Post by avgcorrection »

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…

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

VP of Community strikes again.

Re: Problems of C, and how Zig addresses them

#218

Post by [deleted] »

throwawaymaths wrote: post #190
spc476 wrote: post #187

Earlier quoted context omitted.

Some CPUs don't have a MUL or (like some 32-bit RISC architectures) DIV instruction, and on these, the C compile has to fall back to a function call.

You sure the compiler doesn't inline it? That an operator might take more than one opcode I think is uncontroversial

[deleted]

Re: Problems of C, and how Zig addresses them

#219

Post by apatheticonion »

staunton wrote: post #175
apatheticonion wrote: post #171

For me as a high level application developer, I liked C but felt that it needed a rational module system, generics and structural types. The addition of methods on structs would be nice too (no need for inheritance). The only reason I thought about it is because I have been trying (and failing) to contribute to open source Linux projects - which are practically all written in C and the C++ projects are impossible to…

C++ has all the things you "felt that C needed". So there must be something more that you dislike.

Due to my lack of experience, I definitely have no business criticising the language design of C or C++ haha but it's fun to talk about.

The issues I faced with C++ were that it has too many features. I feel that makes it difficult to carry experience in one project to another due to the variety in styles afforded by that design choice.

I once saw a C++ tutorial that rewrote a verbose for loop into a functional chain and it was practically unreadable for anyone lacking considerable C++ knowledge.

I'm also not a big fan of the way the module system in C++ works (similarly to C#, Java, Rust) where you import a namespace and then things are just available or extended.

Probably an unpopular opinion but, when evaluating the language semantics alone, I quite like the approach TypeScript takes to modules. You import a "thing" from a "relative filepath" explicitly and there is no ambiguity as to its origin (even when just groking a file in a low-tech text editor). For me it makes the process of tracing and understanding circuits easier than sorta guessing which namespace a function or method comes from. This also makes it easier for compilers to optimise binaries as they can statically determine what code is used, excluding unused code from a build.

I guess I could probably say the build system for C is difficult to grasp. In the high level world, I'm used to simply saying "compiler build main.xyz" - where C has makefiles, configure scripts and I find it a bit much.

But what do I know, haha

Re: Problems of C, and how Zig addresses them

#220

Post by sweetjuly »

flohofwoe wrote: post #81
chc wrote: post #71

Earlier quoted context omitted.

Many features of C do not directly correspond with most modern assembly languages. You cannot predict the exact assembly it will generate without knowing a lot of details about your compiler and platform, and even then it's often iffy. It seems like a bit of a leap to call something "a minimal abstraction" if you can't even correctly describe how an operation in the abstraction corresponds to operations in the lower…

That's mainly the result of optimizer passes, C itself doesn't have much to do with it. Assembly languages actually haven't changed all that much since the 70's, but compilers have improved a lot. The output of early C compilers did indeed match the source code quite closely (and not just on the PDP-11), but even today that's true if you disable optimizations (and even with optimizations is usually pretty straightfor…

C has everything to do with optimizer passes, the language definition is what allows them to happen! The fact that you get about what you'd expect on -O0 is merely incidental, the specification does not afford you this.
Post reply on HN