Zig: The Modern Alternative to C • Hacker News Board

Re: Zig: The Modern Alternative to C

#141

Post by Animats » Fri, Mar 10, 2023, 5:51 PM UTC

anonymoushn wrote: post #103

pron wrote: post #84

Earlier quoted context omitted.

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…

I don't think that unsafe constructs are clearly delineated in Zig. @intToPtr and @ptrToInt are in the same namespace as @max. The raw pointer of a slice is a member you can access with mySlice.ptr. A user came into the discord a month or so ago and asked a question about a program they had written where they compared a value to undefined. This is obviously never correct and they meant to make the variable nullable a…

> I don't think that unsafe constructs are clearly delineated in Zig.

That's the real problem. It's a mixture of safe and unsafe features, with no clear boundary. C++ is like that. The trouble is, people keep using raw pointers and mess up. Read CERT advisories. Most of them come from that class of error.

This is the same problem all the attempts to fix up C have hit.

Just say no to unsafe code.

Re: Zig: The Modern Alternative to C

#142

Post by naasking » Fri, Mar 10, 2023, 5:53 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.

I have no dog in this race as I don't use Zig at the moment, but I'm not sure speculative is that unfair. Zig can literally be a drop-in replacement for GCC/clang [1], meaning you don't even have to fully adopt Zig as the build tool, so your initial comment about a lack of separation of concerns doesn't seem correct: just use "zig cc" for the C/C++ source if that's all you want.

That said, using Zig as the build tool seems to bring trivial cross-compilation support and portability, without having to deal with linkers [2]. Cross-compilation has always been and remains a PITA, so that's pretty compelling.

[1] https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

[2] https://zig.news/kristoff/compile-a-c-c-project-with-zig-368...

Re: Zig: The Modern Alternative to C

#143

Post by Koshkin » Fri, Mar 10, 2023, 5:55 PM UTC

flohofwoe wrote: post #130

Koshkin wrote: post #128

const std = @import("std"); pub fn main() !void { const stdout = std.io.getStdOut().writer(); try stdout.print("Hello, {s}!\n", .{"world"}); } To me, this looks worse than anything I have seen before.

Alternatively: const print = @import("std").debug.print; pub fn main() void { print("Hello {s}!", .{"World"}); } Or using the logging API: const info = @import("std").log.info; pub fn main() void { info("Hello {s}!", .{"World"}); } (I'm actually not sure why Zig doesn't have a simple way to print to stdout, but I guess there are 'reasons')

Zig is the ugliest of the Three Piglets (the other two being Rust and Swift).

Re: Zig: The Modern Alternative to C

#144

Post by pron » Fri, Mar 10, 2023, 6:10 PM UTC

Animats wrote: post #141

anonymoushn wrote: post #103

Earlier quoted context omitted.

I don't think that unsafe constructs are clearly delineated in Zig. @intToPtr and @ptrToInt are in the same namespace as @max. The raw pointer of a slice is a member you can access with mySlice.ptr. A user came into the discord a month or so ago and asked a question about a program they had written where they compared a value to undefined. This is obviously never correct and they meant to make the variable nullable a…

> I don't think that unsafe constructs are clearly delineated in Zig. That's the real problem. It's a mixture of safe and unsafe features, with no clear boundary. C++ is like that. The trouble is, people keep using raw pointers and mess up. Read CERT advisories. Most of them come from that class of error. This is the same problem all the attempts to fix up C have hit. Just say no to unsafe code.

The boundary in Zig is clear, certainly clearer than in C or C++. Unsafe pointers that allow pointer arithmetic have a special type and are far less common than in C++ (and obviously C). Other unsafe operations are clearly grepped, which is not at all the case in C and C++. It is also a much simpler language than C++, which may offers easier understanding and review.

The problem with eliminating unsafe code altogether is that doing so has a cost that, in some situations, is not worth it. Sometimes it's a runtime code in memory footprint or CPU resources; sometimes it's a cost in code complexity or development speed, which may have an adverse impact on correctness, which is the real thing we're interested in.

Finding the sweet spots among the various options can only be done empirically, and because Zig is so different (it's as different from C as it is from C++ and as different from either as it is from Rust) there's nothing we can extrapolate from. Because it is its very particular combination of features (and lack thereof) that is its message, those who look at a particular aspect and say, oh, this feature is like language X, therefore Zig will have the characteristics of X, completely miss what Zig does. It tries to strike a particular balance between the compiler, the human reader, and the tooling and development experience that can only be considered as a whole.

I have no idea if Zig is "good" or if it will be successful -- only time will tell -- but I find the language so refreshing and fascinating because it is a radical departure from everything we've seen in that space in quite a long time. There is no language with a similar mix of features (and lack of features).

Re: Zig: The Modern Alternative to C

#145

Post by firstlink » Fri, Mar 10, 2023, 6:57 PM UTC

nsajko wrote: post #76

proto_lambda wrote: post #25

Earlier quoted context omitted.

C-style for loops can almost always be replaced with iterators in a more concise manner. No need for the explicit termination check or the explicit advancement expression, that's already handled by the iterator.

Iterators are often nice, but are no replacement for loops. Try processing multidimensional arrays without loops.

> iterators

> without loops

This is a false dichotomy. You can use iterators to replace three-clause loops without changing the body:

    for row in 0..rows {
      for col in 0..cols {
        arr[row][col]
      }
    }

This is far easier to read than three-clause loops which repeat redundant information repeatedly and redundantly.

Re: Zig: The Modern Alternative to C

#146

Post by kps » Fri, Mar 10, 2023, 6:58 PM UTC

pron wrote: post #144

Animats wrote: post #141

Earlier quoted context omitted.

> I don't think that unsafe constructs are clearly delineated in Zig. That's the real problem. It's a mixture of safe and unsafe features, with no clear boundary. C++ is like that. The trouble is, people keep using raw pointers and mess up. Read CERT advisories. Most of them come from that class of error. This is the same problem all the attempts to fix up C have hit. Just say no to unsafe code.

The boundary in Zig is clear, certainly clearer than in C or C++. Unsafe pointers that allow pointer arithmetic have a special type and are far less common than in C++ (and obviously C). Other unsafe operations are clearly grepped, which is not at all the case in C and C++. It is also a much simpler language than C++, which may offers easier understanding and review. The problem with eliminating unsafe code altogethe…

I fear that it will fail because it rejects information hiding. There isn't all that much new C being written, so it seems counterproductive to renounce the users that (have to) follow coding standards like MISRA C and CERT C.

Re: Zig: The Modern Alternative to C

#147

Post by oriolid » Fri, Mar 10, 2023, 7:17 PM UTC

gpderetta wrote: post #139

oriolid wrote: post #138

Earlier quoted context omitted.

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.

Well, you brought up the subject :) I think it's a bit intellectually dishonest to appeal to typical OOP definition when there isn't one (except that your language isn't true OOP but my language, I won't tell which one, is). And there are quite a few different definitions of late binding too.

Re: Zig: The Modern Alternative to C

#148

Post by Animats » Fri, Mar 10, 2023, 7:19 PM UTC

kps wrote: post #146

pron wrote: post #144

Earlier quoted context omitted.

The boundary in Zig is clear, certainly clearer than in C or C++. Unsafe pointers that allow pointer arithmetic have a special type and are far less common than in C++ (and obviously C). Other unsafe operations are clearly grepped, which is not at all the case in C and C++. It is also a much simpler language than C++, which may offers easier understanding and review. The problem with eliminating unsafe code altogethe…

I fear that it will fail because it rejects information hiding. There isn't all that much new C being written, so it seems counterproductive to renounce the users that (have to) follow coding standards like MISRA C and CERT C.

> information hiding

An interesting point, especially at API boundaries.

C and Zig not having information hiding is to some extent a feature. C++ is notorious for having information hiding without safety. Almost no other language has that combination.

Re: Zig: The Modern Alternative to C

#149

Post by [deleted] » Fri, Mar 10, 2023, 7:55 PM UTC

oriolid wrote: post #147

gpderetta wrote: post #139

Earlier quoted context omitted.

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.

Well, you brought up the subject :) I think it's a bit intellectually dishonest to appeal to typical OOP definition when there isn't one (except that your language isn't true OOP but my language, I won't tell which one, is). And there are quite a few different definitions of late binding too.

[deleted]

Re: Zig: The Modern Alternative to C

#150

Post by TUSF » Fri, Mar 10, 2023, 7:57 PM UTC

flohofwoe wrote: post #11

sgt wrote: post #5

Is it a good alternative to Go? How is interoperability?

The Zig compiler is also a (clang compatible) C/C++/ObjC compiler, the Zig toolchain comes with C and C++ runtime headers and libraries, C headers (but not C++ or ObjC headers) can be directly imported into Zig code. Don't know how many of those checkboxes Go ticks (I think it can at least import C headers?). Whether it's going to become a good alternative for Go will depend mainly on the stdlib I think. What's clear…

> Don't know how many of those checkboxes Go ticks (I think it can at least import C headers?).

Go lets you write C in your Go files, and reference it with a psuedo-package, "C". So you can import C headers, but Go itself doesn't come with a C compiler toolchain, and ends up relying on your system's C compiler, and thus you lose Go's cross-compilation, unless you have the headers for your target platform. I've seen some have been using "zig cc" as their C compiler with Go, given it makes cross-compilation easy.