Problems of C, and how Zig addresses them • Hacker News Board

Re: Problems of C, and how Zig addresses them

#31

Post by pavlov » Mon, Jul 03, 2023, 4:33 PM UTC

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.

Re: Problems of C, and how Zig addresses them

#32

Post by pavlov » Mon, Jul 03, 2023, 4:34 PM UTC

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.

I’m just old enough to remember when C and Pascal were called high-level languages.

“C is actually assembly” was quite a plot twist from there.

Re: Problems of C, and how Zig addresses them

#33

Post by quirino » Mon, Jul 03, 2023, 4:42 PM UTC

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.

Could you specify the main ways it isn't? I have limited experience in both but I haven't seen much that suggests otherwise

Re: Problems of C, and how Zig addresses them

#34

Post by PhilipRoman » Mon, Jul 03, 2023, 4:42 PM UTC

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 much once you understand how optimizing compilers work.

Re: Problems of C, and how Zig addresses them

#35

Post by cconroy » Mon, Jul 03, 2023, 4:42 PM UTC

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.

C is an abstraction over assembly. It is also minimal compared to prolog.

Re: Problems of C, and how Zig addresses them

#36

Post by augustk » Mon, Jul 03, 2023, 4:45 PM UTC

Does Zig have a formal grammar (like C)?

Re: Problems of C, and how Zig addresses them

#37

Post by quelsolaar » Mon, Jul 03, 2023, 4:49 PM UTC

Technically there is no "compile time" in C. Any part of the program can be computed at compile time or at runtime. Its entirely up the the implementation. The AS-IF rule in the C standard lets implementations do whatever they want as long as the program outputs the same things. The pre-processor, const expressions, constexpr (a for this reason compliably broken feature in my opinion), even text parsing and tokenization can happen at run time.

Not having the standard define what is compile time and not is a feature not a bug, and one of the reasons that C continues to enjoy healthy compiler development. (I'm not taking a stand for or against Zig, other then that i support the development of new languages)

Re: Problems of C, and how Zig addresses them

#38

Post by sfpotter » Mon, Jul 03, 2023, 4:50 PM UTC

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?

Re: Problems of C, and how Zig addresses them

#39

Post by throwawaymaths » Mon, Jul 03, 2023, 4:50 PM UTC

sgeisenh wrote: post #11

revskill wrote: post #5

OK, so Zig to C is like Typescript to Javascript.

I don't think I fully understand the analogy. Typescript has almost identical semantics to Javascript but adds typing syntax to improve developer experience and make it easier to manage a large-scale JS codebase. Zig is a fundamentally different language than C that has a lot of new features. Two great examples are comptime and allocators which have complements in C, but are really very different from what C provides…

Typescript also compiles to C, zig explicitly seeks to replace C

Re: Problems of C, and how Zig addresses them

#40

Post by esrauch » Mon, Jul 03, 2023, 4:50 PM UTC

sgeisenh wrote: post #11

revskill wrote: post #5

OK, so Zig to C is like Typescript to Javascript.

I don't think I fully understand the analogy. Typescript has almost identical semantics to Javascript but adds typing syntax to improve developer experience and make it easier to manage a large-scale JS codebase. Zig is a fundamentally different language than C that has a lot of new features. Two great examples are comptime and allocators which have complements in C, but are really very different from what C provides…

Zig has more things for C interop than you're suggesting though, namely the extern keyword, calling convention, etc. Like ts/js, zig/c seems first class designed be used together in one codebase, compared to eg Rust where is obviously possible but more deliberately discouraged (since it breaks the safety guarantees, which Zig never claimed to begin with)