Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig: The Modern Alternative to C

infoworld.com

Post reply on HN
Print view View original

151–160 of 181 posts

Re: Zig: The Modern Alternative to C

#151

Post by pron »

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.

I can't say that I feel naturally attracted to Zig's position on information hiding (although I do find the whole package a good fit for most of my personal preferences), but it's hard for me to predict how the gestalt of its features will perform in the market, not to mention that the market success of any product is affected by many factors that aren't intrinsic to the product.

BTW, how did you reach the conclusion there isn't "all that much new C being written"?

Re: Zig: The Modern Alternative to C

#152

Post by kps »

Animats wrote: post #148
kps wrote: post #146

Earlier quoted context omitted.

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.

I certainly understand the Zig core's arguments, but I don't think they'll matter in the places where these C coding standards are used. I'm sure an external linter could solve the problem using some naming convention or magic comments, but I'm not sure it'll get far enough for that to be written. [Edit: there does seem to be community interest in metadata annotations for external static analysis https://github.com/ziglang/zig/issues/14656 ]

Although I only have a beginner knowledge of the language, it seems to me that Zig is just on the edge of being able to provide a nice unification of the C opaque-pointer idiom with other opaque handles (e.g. POSIX file descriptors, GL handles).

Re: Zig: The Modern Alternative to C

#153

Post by messe »

humanrebar wrote: post #105
flohofwoe wrote: post #101

Earlier quoted context omitted.

In practice it works very well though, I experimented a bit with replacing cmake with build.zig for a 'not-quite-trivial' C++ project, and tbh for cross-platform code that's a lot nicer than wrestling with the arcane cmake syntax and all the C/C++ compiler toolchain differences: https://github.com/floooh/sokol-tools/blob/master/build.zig The basic idea is the same as in all other build systems: you describe your buil…

Right. But switching build systems is a big ask for a lot of situations. The build workflow is part of the API for a lot users of that project.

Just because it’s the default doesn’t mean it’s the only option.

Another approach would be to integrate your zig code as a static library, and have your existing build system call out to zig’s build system just for that part of the build. Linking it to the rest of your code could then be performed by your existing build system, just as it would link any other library.

In practice, Zig is quite flexible.

Re: Zig: The Modern Alternative to C

#154

Post by properparity »

eska wrote: post #81
banyaaa wrote: post #77

Earlier quoted context omitted.

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

Store an error code forget to check it, store a future but fail to poll it, etc.

That is something a decent type system should solve - make it impossible to pass 'incomplete values' on, so any state further on which depends on the error handled/not handled will expect the appropriate type and compiler will error at that call site.

An unused variable means you weren't passing it on anywhere so there is no code which depends on its value, so how can it be a bug?

future = x.do_async(); return;

should not error out because of 'unused variable', it should give a error message concerning the lifetime of the future object.

Re: Zig: The Modern Alternative to C

#155

Post by kps »

pron wrote: post #151
kps wrote: post #146

Earlier quoted context omitted.

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.

I can't say that I feel naturally attracted to Zig's position on information hiding (although I do find the whole package a good fit for most of my personal preferences), but it's hard for me to predict how the gestalt of its features will perform in the market, not to mention that the market success of any product is affected by many factors that aren't intrinsic to the product. BTW, how did you reach the conclusion…

‘Much’ is a relative term; there may be more absolute lines being written today than at its relative peak. But I see the spaces where a green-field project would choose C shrinking; even lightbulbs run C++ now that economies of scale have made 32-bit controllers so cheap. (I've written a lot of C, including parts of a C compiler, so I know it well, and I'm just not seeing it get much attention now. But if I could write Zig in a job I do think that would be more fun than writing C in a job again.)

Re: Zig: The Modern Alternative to C

#156

Post by tialaramex »

jstimpfle wrote: post #131
tialaramex wrote: post #121

Earlier quoted context omitted.

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…

Maybe the problem you've got is that you actually haven't understood what the alternative you don't like even is in practice ?

  // Assuming buffer is a mut [u8] and text is the text value we'd like to write into it
  // if we've got some string, just let text = string.as_bytes();

  if text.len() > buffer.len() {
    // As with snprintf we need to decide what to do if it won't all fit
    // ... for example let's just truncate it
    let truncated = &text[..buffer.len()];
    buffer.copy_from_slice(truncated);
  } else {
    let (left, _) = buffer.split_at_mut(text.len());
    left.copy_from_slice(&text);
  }
As I thought I'd explained, the yak shaving problems for your C-style strings are on the other side, reading this structure. With pointer + length strings this is no trouble but with a 0-terminated string you have to conjure that sentinel from somewhere, maybe allocating in the process. Slower and uglier.

Re: Zig: The Modern Alternative to C

#157

Post by tialaramex »

tcmart14 wrote: post #137
banyaaa wrote: post #77

Earlier quoted context omitted.

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

The good news is that although intuitively that feels horrible, mechanically those are string literals, so, that doesn't actually do very much, just re-assigning a pointer. Moreover, there's no way an optimising compiler can't see those assignments are futile and elide them, whereupon in release builds it might as well be a comment.

And yes, lots of people who don't like Zig's choice agree unused variables are bad and shouldn't survive into your release code. They just don't agree with Andrew that it's a fatal error and the program shouldn't build.

Re: Zig: The Modern Alternative to C

#158

Post by humanrebar »

messe wrote: post #153
humanrebar wrote: post #105

Earlier quoted context omitted.

Right. But switching build systems is a big ask for a lot of situations. The build workflow is part of the API for a lot users of that project.

Just because it’s the default doesn’t mean it’s the only option. Another approach would be to integrate your zig code as a static library, and have your existing build system call out to zig’s build system just for that part of the build. Linking it to the rest of your code could then be performed by your existing build system, just as it would link any other library. In practice, Zig is quite flexible.

I'd like that plan a lot more if there were any normal way for build systems to communicate about build requirements and outcomes and the zig toolchain implemented it.

Re: Zig: The Modern Alternative to C

#159

Post by KRAKRISMOTT »

Koshkin wrote: post #143
flohofwoe wrote: post #130

Earlier quoted context omitted.

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

And the Big Bad Go will come and blow down their houses.

Re: Zig: The Modern Alternative to C

#160

Post by piperswe »

Gigachad wrote: post #57
kissgyorgy wrote: post #49

"that could one day replace C" I don't understand why would anybody say that, it's seems such a simple concept to me that nothing ever will replace C. Think about just the Linux kernel, nothing else. Nobody will and can rewrite every part of it that a C compiler will not be needed.

I doubt every single line of C will be removed considering a lot of it is drivers for hardware no one has anymore, but I’d say in 10 years the majority of actually used code in the Linux kernel will be Rust. The Asahi project has shown that Rust is the better choice for kernel code right now.

I'd say in 10 years the majority of new kernel modules will be written in Rust, but old code won't be rewritten just for the sake of rewriting in Rust (except maybe a select few where such a rewrite is identified as beneficial)
Post reply on HN