Zig: The Modern Alternative to C • Hacker News Board

Re: Zig: The Modern Alternative to C

#131

Post by jstimpfle » Fri, Mar 10, 2023, 4:26 PM UTC

tialaramex wrote: post #121

jstimpfle wrote: post #96

Earlier quoted context omitted.

GP made a great point and I get the impression you're fighting really hard to ignore reality. Idealistic thinking doesn't win the practical exams. Zero-terminated strings are a fact of life and essential to using many useful APIs. Like it or not, if a new ecosystem wants adoption it had better interoperate with the established ones without much friction. Apart from that, zero-terminated strings aren't strictly bad. T…

I've been on both sides of this fence, decades writing C before I wrote any Rust - and no, IMNSHO the Yak barbering necessary is much more extensive and annoying with zero terminated strings. The on-disk fixed size structure stuff is actually nicer in a language that favours slices, because with C-strings we're incurring a special case, what happens when the sub-structure is full? With slices that's just fine, but wi…

> so you have to decide what to do about that

No, you need to do what needs to be done according to the on-disk format. The disk doesn't care what you think is the ideal string representation. If the available space is used up, it is used up. That's just the semantics that come with the physical reality of existing systems where you can't just malloc an extra space on the heap. Having an internal representation that matches what's on the disk is the right call, everything else is only layering complexity.

Also, you're making it look like it was hard to use, but those semantics are very easy to program against, using something like snprintf(buffer, sizeof buffer, "%s", ...), or just do it manually.

Re: Zig: The Modern Alternative to C

#132

Post by ngrilly » Fri, Mar 10, 2023, 4:31 PM UTC

pron wrote: post #84

Animats wrote: post #19

That article is about control flow and syntax, which isn't a big problem. What matters is data. So what does Zig have that C doesn't? - Arrays and slices. A slice is a pointer and a length. There's subscript checking on slices. You'd expect that the preferred operation would be to take a slice from a slice, but the documentation does not mention that option. This may be a documentation error. There is a ".." operator…

Sometimes what's most important is not what you have but what you don't have. Zig doesn't have preprocessor macros; it doesn't have dangerous C-like unions (unless explicitly requested via "unsafe" constructs). Pointer arithmetic and casts are explicitly delineated as unsafe constructs, and are more easily avoided. What this means is that (unless the clearly demarcated "unsafe" constructs are used) all pointers in a…

This is exactly why I'm excited about Zig. It offers everything that was powerful and fun about C, and much more (comptime, error handling, better types, etc.), but without the warts that made me avoid C during the last 20 years.

Re: Zig: The Modern Alternative to C

#133

Post by loeg » Fri, Mar 10, 2023, 4:41 PM UTC

jenadine wrote: post #18

loeg wrote: post #8

Earlier quoted context omitted.

The point that paragraph is trying to make but articulates imperfectly is that you explicitly pass an Allocator to the stdlib routines that allocate -- rather than having them allocate on the heap implicitly.

So you have coloured functions? The red that can allocate, and the blue that cannot?

No, I wouldn't describe it like that. It's more that there isn't an ambient, implicit Allocator lying around for stdlib to use. It is explicitly provided by callers.

Re: Zig: The Modern Alternative to C

#134

Post by pornel » Fri, Mar 10, 2023, 4:45 PM UTC

giancarlostoro wrote: post #104

pornel wrote: post #92

Earlier quoted context omitted.

Because the classic for loop is prone to off-by-one errors, and it's unnecessarily boilerplatey for simple cases. OTOH complex cases that take advantage of customizing the three clauses or independently modify iteration variable(s) are usually "clever", not in a good way.

You can still have it but add more modern syntax for looping. Hell Java has "goto" reserved if I remember correctly.

All languages with a simplified `for` loop have kept `while` for the other cases. That makes the old `for` just a redundant syntax.

Re: Zig: The Modern Alternative to C

#135

Post by thomascgalvin » Fri, Mar 10, 2023, 4:45 PM UTC

simg wrote: post #117

genuine question: why might you pick Zig over Rust?

The borrow checker is a hard hill to climb for a lot of people, to the point where many devs get to that part of the tutorial and decide to go do something else with their lives.

Re: Zig: The Modern Alternative to C

#136

Post by david2ndaccount » Fri, Mar 10, 2023, 5:02 PM UTC

pornel wrote: post #92

david2ndaccount wrote: post #12

I don’t know why these new languages have to have their own special takes on loops without giving us the classic C99 version of the three-clause-for-loop. Even JavaScript has it. If they want to improve on it, then allow us to declare variables of different types in the first clause. Yes, using the C-style loop to iterate over a container sucks, but that is an argument for also having a for-each loop. There are lots…

Because the classic for loop is prone to off-by-one errors, and it's unnecessarily boilerplatey for simple cases. OTOH complex cases that take advantage of customizing the three clauses or independently modify iteration variable(s) are usually "clever", not in a good way.

Zig supports the 2nd and 3rd clause already in its while loop. Would it kill it to accept an initializer and look more like other languages instead of having a special snowflake syntax.

Is this (note the enclosing braces)

  {
    var thing = thinger();
    while(cond(thing)) : (mutate(thing)){
      // do whatever
    }
  }

really better than this?

  for(var thing = thinger(); cond(thing); mutate(thing)){
    // do whatever
  }

Re: Zig: The Modern Alternative to C

#137

Post by tcmart14 » Fri, Mar 10, 2023, 5:05 PM UTC

banyaaa wrote: post #77

tialaramex wrote: post #61

Earlier quoted context omitted.

Product of the creator's will. Andrew is confident that always rejecting programs with unused variables catches bugs, and he believes that if you don't like this you should have software to adapt the Zig you write so that it compiles, by adding or removing _ = unused_variable; style statements to consume the otherwise unused variables. There can be a benefit to a singular coherent vision behind something - committees…

What's an example of a bug that would be caused by having an unused variable? I honestly can't think of one.

As someone who works at a company with an old horrible code base, for me its not so much of it can cause bugs, but it presents people from doing stupid things. In parts of a codebase we have a long legacy function that contains a string that tries to show what "state" a process is in, but the string is only ever used for that. Never is it actually used by the system. So we have code that looks like this

  public void processTransaction() {
    string state = "start";
    getCardDetails();
    state = "serialize";
    serializeCardData();
    state = "send data";
    sendData();
    state = "check return code";
    bool success = checkReturnCode();
    if (!success) {
      state = "failed";
      doFailThing();
      return;
    }
    state = "store transaction record";
    storeTheThing();
    state = "complete";
  }

First, this code is a simple example, in reality, the code has bunch of branching and doesn't actually call out to functions to do things like "getCardDetails," so just replace that function in the example above with some parsing logic of a string to parse Track1 and Track2 data. The equivalent method we actually have in our code base to do that is ~1500 lines of code. But that string is doing nothing that a comment couldn't accomplish. Or more importantly, what the code could describe itself if it actually adhered to good design principles. Ideally, I would refactor this, but the owner of the company is adament on keeping this 1500 line abomination untouched.

For me, I often unused variables in production code are usually filling the void a comment or good design would have filled.

Re: Zig: The Modern Alternative to C

#138

Post by oriolid » Fri, Mar 10, 2023, 5:23 PM UTC

gpderetta wrote: post #37

oriolid wrote: post #34

Earlier quoted context omitted.

C++ has syntax for adding functions to objects and type system support for deriving object types from other object types and overriding those member functions. There are some who consider these a rather important thing.

I'm just saying that, pedantically, "object" is a term of art in C and C++ which has little to do with the typical OOP definition of object.

Just out of curiosity, what is the typical OOP definition of object?

Re: Zig: The Modern Alternative to C

#139

Post by gpderetta » Fri, Mar 10, 2023, 5:31 PM UTC

oriolid wrote: post #138

gpderetta wrote: post #37

Earlier quoted context omitted.

I'm just saying that, pedantically, "object" is a term of art in C and C++ which has little to do with the typical OOP definition of object.

Just out of curiosity, what is the typical OOP definition of object?

Ah, that's a trick question. There is no typical OOP definition of object. I used to think that only aspect everybody agrees on is late binding, but some people consider traits-like static binding a form of OOP.

Re: Zig: The Modern Alternative to C

#140

Post by [deleted] » Fri, Mar 10, 2023, 5:51 PM UTC

humanrebar wrote: post #108

naasking wrote: post #99

Earlier quoted context omitted.

Is this onramp problem an actual issue you've run into or a speculative issue that you anticipate but haven't actually tried?

I don't have a repo that demonstrates now, no. But it's dismissive to call it speculative. I've seen this sort of problem in smaller situations in the past, like projects whose build systems assume toolchains that aren't what are used in my packaging ecosystem. Replacing all my compilers and linkers and build systems is at least an order of magnitude more disruptive than that.

[deleted]