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

61–70 of 290 posts

Re: Problems of C, and how Zig addresses them

#61

Post by Night_Thastus »

matrix_overload wrote: post #43

It is nice and innovative, no doubt. But reinventing the syntax from scratch instead of introducing just the minimal amount of changes to the original C is a barrier that will deter 90% of possible adopters. The reason C# took off is that it's as close to C/C++ as possible. If there is a difference, it's due to a fundamental semantic change. E.g. it moved from painstakingly reinterpreting hundreds of small header fil…

I disagree, I argue that you've got it backwards.

C has a fair amount of kludge in its syntax. C cannot change its syntax because it would massively break backwards compatibility, which is bad.

New languages do not have this problem - they don't have to worry about backwards compatibility. Because they have that freedom, they should always opt for what they believe is the best possible syntax. I'd say they're obligated to do so. Otherwise, we're stuck with another 10-20+ years of dealing with bad syntax, for no good reason!

If the opportunity for improvement is there, and it's nearly close to free to do so, it should absolutely be taken.

Re: Problems of C, and how Zig addresses them

#62

Post by cellularmitosis »

matrix_overload wrote: post #43

It is nice and innovative, no doubt. But reinventing the syntax from scratch instead of introducing just the minimal amount of changes to the original C is a barrier that will deter 90% of possible adopters. The reason C# took off is that it's as close to C/C++ as possible. If there is a difference, it's due to a fundamental semantic change. E.g. it moved from painstakingly reinterpreting hundreds of small header fil…

In practice it only takes a weekend or two to pick up the syntax changes, and the benefits easily outweigh that investment.

Heck, the simple fact that type signatures can be read literally from left to right (instead of using the spiral rule) is enough for me to switch. https://zig.news/toxi/typepointer-cheatsheet-3ne2

Re: Problems of C, and how Zig addresses them

#63

Post by jstimpfle »

halayli wrote: post #49
PhilipRoman wrote: post #34

Earlier quoted context omitted.

It's true and false at the same time. The operations C gives you map 1-to-1 with assembly. Given some C code you can quite accurately predict which loads/stores will be elided by the compiler and what the resulting assembly will be. I can't name another language for which this is true. I get that you're hinting at the insane level of undefined behaviour enforcement by compilers, but I don't think it matters all that…

> The operations C gives you map 1-to-1 It does not. Implicit casting, inlining, volatile, args passed via registers vs stack etc can significantly change what you expect to be generated.

Pretty much a matter of optimization isn't it? Try disabling them. But I take it that this was never the point anyway. I think the point is that the representation of language objects and the runtime are rather straightforward compared to many other languages.

Re: Problems of C, and how Zig addresses them

#64

Post by Night_Thastus »

matrix_overload wrote: post #58
Joker_vD wrote: post #47

Earlier quoted context omitted.

Counterpoint: C itself invented lot of syntax compared to the contemporary ALGOLs and PL/I. Yet, it became immensely popular.

I would dare say, different combination of early adopters/pragmatists in your target audience. C/C++ these days is mostly legacy stuff, so if you want to cater to that audience, you deliver small incremental improvements. Many people that could be bothered to learn Zig syntax, jumped ship to Python/Java/whatever already.

Zig and Python/Java are completely different beasts. One is a low-level systems language on the order of Rust or C. The other two are much higher level, easier to work with languages more attuned to desktop, mobile applications and enterprise work.

I don't think anyone is seriously "jumping ship" from Zig to those.

Re: Problems of C, and how Zig addresses them

#65

Post by xigoi »

PhilipRoman wrote: post #34
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.

It's true and false at the same time. The operations C gives you map 1-to-1 with assembly. Given some C code you can quite accurately predict which loads/stores will be elided by the compiler and what the resulting assembly will be. I can't name another language for which this is true. I get that you're hinting at the insane level of undefined behaviour enforcement by compilers, but I don't think it matters all that…

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

Re: Problems of C, and how Zig addresses them

#66

Post by flohofwoe »

astrobe_ wrote: post #50

About macros and comptime: why is the compiler unable to detect that a function is a pure function, and if it is called with constants, the result can be computed ahead of time? At least in the simple cases such as the square example, which are I believe quite common, that would work. Maybe still add an annotation to make sure the compiler will do what the user expects, because humans are terrible compilers after all…

C/C++ compilers will do this when optimization is enabled (I guess the reason that's not done without optimization is to preserve "debuggability").

Notice how the add() function is completely 'disolved' into its result '5' here:

https://www.godbolt.org/z/q98svvacW

(the main difference to comptime is that this guarantees that the code is resolved at compile time, and if that's not possible you'll get an error).

The big downside of comptime is that it isn't debuggable, apart from what's essentially 'printf debugging' via the @compileError builtin).

Re: Problems of C, and how Zig addresses them

#67

Post by astrobe_ »

throwawaymaths wrote: post #57
astrobe_ wrote: post #50

About macros and comptime: why is the compiler unable to detect that a function is a pure function, and if it is called with constants, the result can be computed ahead of time? At least in the simple cases such as the square example, which are I believe quite common, that would work. Maybe still add an annotation to make sure the compiler will do what the user expects, because humans are terrible compilers after all…

Do you mean in zig? It's possible to do arbitrary, bounded computation (compiler quits if you expend "too many tokens") at comptime in zig, unless there is strange statefulness. This is sensible since you want changes in, e.g. your code tree to taint compiled resources. If your code can go read from the filesystem in an untracked way, you break the incremental compilation model.

This was sort of a general question, although Zig confused me a bit by placing the annotation at the call site rather than on the function declaration. I guess this choice was made to keep compilation times under control.

Re: Problems of C, and how Zig addresses them

#68

Post by pitaj »

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.

Can't they add a new header file?

Re: Problems of C, and how Zig addresses them

#69

Post by chc »

jstimpfle wrote: post #63
halayli wrote: post #49

Earlier quoted context omitted.

> The operations C gives you map 1-to-1 It does not. Implicit casting, inlining, volatile, args passed via registers vs stack etc can significantly change what you expect to be generated.

Pretty much a matter of optimization isn't it? Try disabling them. But I take it that this was never the point anyway. I think the point is that the representation of language objects and the runtime are rather straightforward compared to many other languages.

Only one of those (inlining) is an optimization. Two are language features (implicit casts and volatile) and the other is a calling convention (passing arguments on registers vs. stack).

Re: Problems of C, and how Zig addresses them

#70

Post by flohofwoe »

pitaj wrote: post #68
pavlov wrote: post #31

Earlier quoted context omitted.

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.

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)

Post reply on HN