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

Re: Problems of C, and how Zig addresses them

#281

Post by kaba0 » Wed, Jul 05, 2023, 6:49 AM UTC

WalterBright wrote: post #231

vore wrote: post #212

Earlier quoted context omitted.

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

Just be honest with yourself and say that you subjectively like it better that way, as it grew on you.

There is nothing wrong with that reasoning. Also, there will never be a language which is perfect in every conceivable way, this is such a minor difference that if someone chooses a language over this alone, they are not being reasonable.

Re: Problems of C, and how Zig addresses them

#282

Post by kaba0 » Wed, Jul 05, 2023, 7:42 AM UTC

avgcorrection wrote: post #213

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

I agree with you on a theoretical level, but arguably we should not be the ones to bear the complexity of that decision — the representation of a given data is very important for our “limited” human brains.

I think the major problem here is shoehorning everything into a “symbol soup” on a 2D matrix. I do get that it has plenty advantages (can be typed without special program, easier version control, etc), but I would like to see a resurrection of interest in visual language. I’m not meaning something as visual as scratch or so, but some special blocks could come in handy.

Re: Problems of C, and how Zig addresses them

#283

Post by coliveira » Wed, Jul 05, 2023, 11:52 AM UTC

IshKebab wrote: post #279

coliveira wrote: post #275

Earlier quoted context omitted.

Yes it did and continues making it possible. Several of the largest codebases in the world are written in C.

To reiterate, C didn't make it possible to write those codebases just because they happen to be written in C.

Yes, it did. Just check how they created UNIX.

Re: Problems of C, and how Zig addresses them

#284

Post by WalterBright » Wed, Jul 05, 2023, 5:44 PM UTC

kaba0 wrote: post #281

WalterBright wrote: post #231

Earlier quoted context omitted.

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

Just be honest with yourself and say that you subjectively like it better that way, as it grew on you. There is nothing wrong with that reasoning. Also, there will never be a language which is perfect in every conceivable way, this is such a minor difference that if someone chooses a language over this alone, they are not being reasonable.

A language is nearly all about subjective choices.

Re: Problems of C, and how Zig addresses them

#285

Post by saagarjha » Thu, Jul 06, 2023, 7:27 AM UTC

kristoff_it wrote: post #252

saagarjha wrote: post #204

Earlier quoted context omitted.

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

Apple shipped a compiler with the M1 Mac, yes, but if you wanted to compile for Apple Silicon from say a Linux x86_64 machine, there was no toolchain that was able to do it other than Zig.

Theos has supported Linux and Windows for many years.

Re: Problems of C, and how Zig addresses them

#286

Post by avgcorrection » Thu, Jul 06, 2023, 10:34 AM UTC

kristoff_it wrote: post #258

avgcorrection wrote: post #217

Earlier quoted context omitted.

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

You feel it's an unfair statement?

It’s got nothing to do with that.

Re: Problems of C, and how Zig addresses them

#287

Post by cancername » Thu, Jul 06, 2023, 6:37 PM UTC

WalterBright wrote: post #254

brabel wrote: post #234

Earlier quoted context omitted.

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.

True, but can you create a pointer to a 4 bit type? I tried to make that work in D at one point, and wound up abandoning it. D allows 4 bit types using conventional bit fields (but you can't take a pointer to them).

Yes:

    const std = @import("std");
    const expectEqual = std.testing.expectEqual;

    test "u4 is 1 byte" {
        try expectEqual(1, @sizeOf(u4));
    }

    test "u4 is 4 bits" {
        try expectEqual(4, @bitSizeOf(u4));
    }

    test "u4 is 1-byte-aligned" {
        try expectEqual(1, @alignOf(u4));
    }

    test "pointers to u4 work like any other pointer type" {
        var foo: u4 = 10;
        const foo_p = &foo;
        try expectEqual(@as(u4, 10), foo_p.*);
        foo_p.* = 7;
        try expectEqual(@as(u4, 7), foo);
    }

Packed structs are Zig's replacement for bit fields:

    const std = @import("std");
    const expectEqual = std.testing.expectEqual;
    
    test "bool has a bit size of 1 bit, a size of 1 byte, and an alignment of 1 byte" {
        try expectEqual(1, @bitSizeOf(bool));
        try expectEqual(1, @sizeOf(bool));
        try expectEqual(1, @alignOf(bool));
    }
    
    test "in a regular struct, fields are aligned to their natural alignment..." {
        const Natural = struct {
            read: bool,
            write: bool,
            exec: bool,
        };
        try expectEqual(3, @sizeOf(Natural));
        try expectEqual(1, @alignOf(Natural));
    }
    
    test "...unless otherwise specified" {
        const TwoByteAligned = struct {
            read: bool align(2),
            write: bool align(2),
            exec: bool align(2),
        };
        try expectEqual(6, @sizeOf(TwoByteAligned));
        try expectEqual(2, @alignOf(TwoByteAligned));
    }
    
    test "in a packed struct, fields occupy exactly their bit size" {
        const Packed = packed struct {
            read: bool,
            write: bool,
            exec: bool,
        };
        try expectEqual(3, @bitSizeOf(Packed));
        try expectEqual(1, @sizeOf(Packed));
        try expectEqual(1, @alignOf(Packed));
    }

Re: Problems of C, and how Zig addresses them

#288

Post by alexvoda » Fri, Jul 07, 2023, 3:19 PM UTC

kevin_thibedeau wrote: post #227

pornel wrote: post #195

Earlier quoted context omitted.

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…

This is just one of the reasons that new languages that dispense with outdated assumptions and insted make assumptions more suitable to our times are a good thing. C and C++ are really old and some things can not be fixed with libraries.

Re: Problems of C, and how Zig addresses them

#289

Post by lerno » Sun, Jul 09, 2023, 6:46 PM UTC

tayistay wrote: post #124

From the article: const result = comptime square("hello"); // compile time error: type mismatch ok, cool. But if the error occurs deep in some hierarchy of comptime calls, do you get the same kind of long errors that you do with C++ templates? Does zig have a way of achieving better ergonomics? One nice thing about generics in Rust and Swift is they are constrained by traits/interfaces so you get a concise error at t…

This isn't about Zig, but I found that I prefer something similar to concepts over traits/interfaces, as the former are somewhat limited as to what they express.

    /**
     * @checked x & 1 "The input parameter must allow bit operations"
     */
    macro bool is_power_of_2(x)
    {
      return x != 0 && (x & (x - 1)) == 0;
    }

In the example above (disregard the fact that it's placed in the doc comments) we'd get an error if `x & 1` is invalid (doesn't pass semantic checking). This is the simplest possible example. Basically if you pass in a float or a struct you would then get "The input parameter must allow bit operations" rather than a dump of errors from the macro body.

We can imagine other constraints, such as checking the value (if constant) to conform with valid ranges and so on.

This is more of a "contract" style constraint that can be placed directly at the call location, rather than pushing down the check further down into macro body, for example something like this:

    macro bool is_power_of_2(x)
    {
      $assert($checks(x & 1), "The input parameter must allow bit operations");
      return x != 0 && (x & (x - 1)) == 0;
    }

In this example the error would be localized to the macro, which perhaps isn't what we want, even if the compiler is kind enough to tell us where the macro was included.

Re: Problems of C, and how Zig addresses them

#290

Post by lerno » Sun, Jul 09, 2023, 6:51 PM UTC

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…

What do you think about C3 then? https://c3-lang.org