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

171–180 of 181 posts

Re: Zig: The Modern Alternative to C

#171

Post by Tozen »

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…

Vlang, is a newer programming language (with various modern features, including package manager) that also has the classic C style for loops.

https://github.com/vlang/v/blob/master/doc/docs.md#c-for

Re: Zig: The Modern Alternative to C

#172

Post by Tozen »

anecdotal1 wrote: post #94
guntherhermann wrote: post #27

Earlier quoted context omitted.

> C-style for loops can almost always be replaced with iterators in a more concise manner. Not if you want to optimise for performance. A simple example: I search through a list of n items to find item m, iterators typically don't let you break out of the iteration. Zig is the only contender I've seen where the for loop looks iterator-like, but also supports break/continue.

Dlang isn't a contender here? It can do most everything Zig can do, speaks C natively, and it supports break/continue? edit: plus has a GC if you don't want to do manual memory management, already has a package manager, good at producing native/static binaries, can do automatic type inference, user defined types, cross compiling is super easy...

You made a good point, that is often overlooked about memory management, as if all users will always want to do it manually. The reality is, many don't want to deal with it at all or only for specific projects and reasons. For new and various users, not having to worry about manual memory management until they are ready or want to, can be a huge relief or increase productivity.

Re: Zig: The Modern Alternative to C

#173

Post by oriolid »

gpderetta wrote: post #168
oriolid wrote: post #167

Earlier quoted context omitted.

The original claim was that C++ "objects" and C PODs and primitives are the same. It's a rather odd claim, and the questions whether C++ "objects" are true objects, there is even a definition of true object, or was object oriented programming a good idea to begin with, don't seem to be closely related.

The standard definition definition of Object in C++ is the same as the definition of Object in C because the standard says so: https://en.cppreference.com/w/cpp/language/object . Is not a problem of interpretation. It is just that the C standard uses the term object for just a bunch of memory (with a type) and the C++ standard does so too. Nothing to do with objects in the OOP sense.

This is interesting. The page you linked mentions that objects can be created using operator new, but I was not aware that C has such thing. Further down polymorphic objects are introduced, and I am fairly sure C does not have those. My favorite detail is mention of "implicitly defined copy/move special member functions", but it is never explained what member functions are. Almost as if you were using a definition that is missing something to prove some kind of point.

By the way, the document you linked to is not the standard. The published standards are not freely available, but here is the relevant part of current draft: https://eel.is/c++draft/intro.object

Re: Zig: The Modern Alternative to C

#174

Post by throwawaymaths »

kaba0 wrote: post #125
throwawaymaths wrote: post #113

Earlier quoted context omitted.

Longer answer: I think it's inevitable that someone will write a static checker for lifetime analysis.

That’s pretty much impossible in the general case, thanks to Rice’s theorem. Rust can only do so because it limits the possible lifetime “shapes”. Otherwise why don’t build it for C instead?

Rust doesn't do it either. It has 'unsafe'. So just as with rust, you would annonate certain things in zig as 'trusted', and anything else will be checked.

For example, for pointers, assume allocator interface create, alloc, destroy, and free functions work as advertised, and trust them. Anything that uses the pointers is checked. For file descriptors, assume open and close are trusted, everything in between is checked.

You can't really build it so easily for c because c language is not generally compiled to an IR, and the syntax is rather ill-defined. It's not context-free and it has lexical macros.

Anyways statically checked annotated c exists, SEL4 is a good example, but iirc it actually checks arm machine code, and yes it is memory safe C.

Re: Zig: The Modern Alternative to C

#175

Post by kaba0 »

throwawaymaths wrote: post #174
kaba0 wrote: post #125

Earlier quoted context omitted.

That’s pretty much impossible in the general case, thanks to Rice’s theorem. Rust can only do so because it limits the possible lifetime “shapes”. Otherwise why don’t build it for C instead?

Rust doesn't do it either. It has 'unsafe'. So just as with rust, you would annonate certain things in zig as 'trusted', and anything else will be checked. For example, for pointers, assume allocator interface create, alloc, destroy, and free functions work as advertised, and trust them. Anything that uses the pointers is checked. For file descriptors, assume open and close are trusted, everything in between is check…

What do you think C compilers work on if not IR? Also, it not being context-free is not a problem after parsing, that’s a different part of the process.

This is about what we can claim about runtime properties. What exactly do you mean by a checked pointer? A pointer has temporal and spatial boundaries — will you add a huge amount of metadata to each pointer to runtime validate whether it’s correctly used? That’s pretty much what valgrind and sanitizers do, but that has quite an overhead. In general you can’t check it for any kind of pointer usage. Rust as I mentioned can get away with it by heavily restricting how pointers can be used. Unchecked is an escape hatch, you can’t just put the “checked” boundary at any place you wish, it has to be placed in a way that makes analysis of its assumed properties sound. In case of Rust this is true, but you would have to restrict Zig’s semantics to something like Rust’s to make your idea workable.

Re: Zig: The Modern Alternative to C

#176

Post by throwawaymaths »

kaba0 wrote: post #175
throwawaymaths wrote: post #174

Earlier quoted context omitted.

Rust doesn't do it either. It has 'unsafe'. So just as with rust, you would annonate certain things in zig as 'trusted', and anything else will be checked. For example, for pointers, assume allocator interface create, alloc, destroy, and free functions work as advertised, and trust them. Anything that uses the pointers is checked. For file descriptors, assume open and close are trusted, everything in between is check…

What do you think C compilers work on if not IR? Also, it not being context-free is not a problem after parsing, that’s a different part of the process. This is about what we can claim about runtime properties. What exactly do you mean by a checked pointer? A pointer has temporal and spatial boundaries — will you add a huge amount of metadata to each pointer to runtime validate whether it’s correctly used? That’s pre…

> In case of Rust this is true, but you would have to restrict Zig’s semantics to something like Rust’s to make your idea workable.

That's exactly the point. You would be restricting zig's semantics within code that you've fenced. You claim it's not possible. Trivially it should be possible, because this is simply the equivalent of abstracting rusts compiler logic (and in the worst case scenario even it's type system, via annotations) to a sidecar step that is run at a different phase of building your code. Or, more generically, formalizing logic that a code reviewer is doing in their head to understand data lifecycles. Really, to support your impossibility claim: It's on you to give an example of zig code that wouldn't be analyzable.

Re: Zig: The Modern Alternative to C

#177

Post by kaba0 »

throwawaymaths wrote: post #176
kaba0 wrote: post #175

Earlier quoted context omitted.

What do you think C compilers work on if not IR? Also, it not being context-free is not a problem after parsing, that’s a different part of the process. This is about what we can claim about runtime properties. What exactly do you mean by a checked pointer? A pointer has temporal and spatial boundaries — will you add a huge amount of metadata to each pointer to runtime validate whether it’s correctly used? That’s pre…

> In case of Rust this is true, but you would have to restrict Zig’s semantics to something like Rust’s to make your idea workable. That's exactly the point. You would be restricting zig's semantics within code that you've fenced. You claim it's not possible. Trivially it should be possible, because this is simply the equivalent of abstracting rusts compiler logic (and in the worst case scenario even it's type system…

I think we misunderstand each other on what is “inside-outside”. Sure, you can have a tiny “safe” block in zig, but that won’t be able to use any outside pointer safely, and I don’t see much point in that — is that what you mean? Because unless you say that, then no.

Also surely you can write some zig to rust compiler (which mind you, will not compile most of your programs as the equivalent rust is not semantically correct), but there is not much point.

Re code:

    let ptr = allocate();
    if (undecideableProperty()) {
      destroy ptr;
    }
    print(*ptr);
Insert any number of undecidable property there, one elegant example would be the Goldbach conjecture.

Re: Zig: The Modern Alternative to C

#178

Post by dmux »

blacksqr wrote: post #170
hawski wrote: post #54

Earlier quoted context omitted.

I am pulling a leg here a bit. I could risk a statement that Tcl could be an alternative when all you want is a simple CRUD backend. Now performance considerations are valid, but in some applications Tcl could be fast enough. Both languages, or maybe we could say platforms, have manged runtimes and maybe that's were similarities end.

Tcl is good for both CRUD and REST; for example, the sqlite.org web site uses a pure Tcl web server, through which you can access sqlite's SCM app which is backed by a SQLite database.

I was under the impression that the sqlite.org website used Dr. Richard Hipp's "althttpd" (written in C): https://sqlite.org/althttpd/doc/trunk/althttpd.md

Re: Zig: The Modern Alternative to C

#179

Post by throwawaymaths »

kaba0 wrote: post #177
throwawaymaths wrote: post #176

Earlier quoted context omitted.

> In case of Rust this is true, but you would have to restrict Zig’s semantics to something like Rust’s to make your idea workable. That's exactly the point. You would be restricting zig's semantics within code that you've fenced. You claim it's not possible. Trivially it should be possible, because this is simply the equivalent of abstracting rusts compiler logic (and in the worst case scenario even it's type system…

I think we misunderstand each other on what is “inside-outside”. Sure, you can have a tiny “safe” block in zig, but that won’t be able to use any outside pointer safely, and I don’t see much point in that — is that what you mean? Because unless you say that, then no. Also surely you can write some zig to rust compiler (which mind you, will not compile most of your programs as the equivalent rust is not semantically c…

If any branch could destroy the pointer, you wouldn't be able to use it later, the static analysis would stop the build. No need to evaulate the undecidable.

Re: Zig: The Modern Alternative to C

#180

Post by throwawaymaths »

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

you might not have a stdout, for example very low to the metal.
Post reply on HN