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

81–90 of 181 posts

Re: Zig: The Modern Alternative to C

#81

Post by eska »

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.

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

Re: Zig: The Modern Alternative to C

#82

Post by hawski »

T-A wrote: post #75
hawski wrote: post #24

Earlier quoted context omitted.

I think one of the author's problems is that he conflates C and C++ and it seems they do not have a knowledge around either. This quote also supports this: > There is no malloc keyword like in C/C++.

Are you nitpicking about it being a keyword in C, https://en.cppreference.com/w/c/memory/malloc and a standard library function in C++ https://en.cppreference.com/w/cpp/memory/c/malloc ?

It is not a keyword in C, so it is not a nit. For all the language is concerned it is just a function that takes a number and returns a pointer. If a compiler treats it any different it is only a question of optimizations or to generate helpful warning/error messages.

You can point linker to a different implementation for all it cares.

Re: Zig: The Modern Alternative to C

#83

Post by tialaramex »

flohofwoe wrote: post #59
tialaramex wrote: post #50

Earlier quoted context omitted.

> I really wish Rust would use the same idea, it would simplify creating C API wrappers a lot. Zero terminated strings suck , you need to do allocation everywhere to work with them, or else you must in-place mutate the strings in hard to reason about ways and they can't fully represent arbitrary text. So I definitely wouldn't want Rust's &str string references to have either behaviour. If what you do is interact clos…

Well yeah, zero terminated strings suck, but that doesn't change the fact that pretty much all operating systems and fundamental C libraries expect strings to be zero terminated, it's not just a C quirk anymore, but burned forever into operating system ABIs too. A programming language which is supposed to interact with those APIs directly really shouldn't make this harder than it needs to be, and Zig's sentinel-termi…

> pretty much all operating systems and fundamental C libraries expect strings to be zero terminated

C libraries are going to mostly be like that because it's how C works. If that's our high bar we're never getting anywhere.

Operating systems don't use many strings -- strings are awful because they're variable size and need parsing. Filenames are the most obvious place the kernel needs strings, and here the 0 terminating string is pretty horrible actually, the kernel can't assume the sentinel is present as that's obviously a massive security hole, so we end up not benefiting from the use of the sentinel, it's there because of C compatibility, as that wanes in significance there's no reason it needs to remain.

On most operating systems the kernel system call ABI is not stable, which means you aren't supposed to rely on this stuff anyway, and once you're not talking directly to the kernel ABI you're free to choose abstractions which better suit both sides.

Re: Zig: The Modern Alternative to C

#84

Post by pron »

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 Zig program are known, and cannot be created "from nothingness" (as in C).

In addition, Zig, while about as simple as C, has the same expressiveness as C++, not to mention its exceptional build capabilities.

I don't know if all that would prove sufficient to one day replace C and/or C++ -- replacing incumbents is always an uphill battle -- but Zig is the most revolutionary (rather than evolutionary) low-level language we've seen in a very, very long time. It offers a completely different approach to how low-level programs are to be written and built.

Because Zig is so simple, how revolutionary it is can be missed when you look at one feature at a time, and can only be appreciated once you consider the whole: The mix of simplicity and power, and the eye toward tooling.

Re: Zig: The Modern Alternative to C

#85

Post by kaba0 »

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.

Which is absolutely not solved by assigning it to _ neither, if anything it will just make the variable appear used in syntax highlighting and that will make me forget to properly use it!

IDEs just gray out the unused variables and that is an 1000x better way of handling this issue.

Re: Zig: The Modern Alternative to C

#86

Post by kristoff_it »

carlmr wrote: post #68
laserbeam wrote: post #41

Earlier quoted context omitted.

Unsure what "massive concurrency means". As far as I'm aware zig offers no special primitives for threading (other than tools in a standard library to start/stop threads and such). Async/await/suspend/resume are features used for concurrency (yielding on a single thread). You then use those primitives to implement parallelism however you want. Just like you'd do in C. Or, ykno, someone makes a library that does green…

So Go has a two things that enable massive concurrency. 1. Coroutines have dynamic stacks, meaning that you can start a lot of threads without exhausting your memory: https://medium.com/a-journey-with-go/go-how-does-the-gorouti... 2. Go has a lightweight threading model that doesn't map one thread to one OS/kernel level thread. Enabling you to have thousands of threads operating at once. limited by GOMAXPROCS. I was…

Go style concurrency can be also implemented in Zig, with the caveat that since Zig doesn't have a runtime / gc, you can't expect full 1:1 mapping with what Go provides.

IMO the key point of Go's concurrency are channels, and those have already been implemented in Zig, with comparable semantics (eg blocking when the channel is full).

Here is how I use a channel (defined a few lines above) to implement the main loop of an interactive program I wrote:

https://github.com/kristoff-it/bork/blob/master/src/main.zig...

Re: Zig: The Modern Alternative to C

#88

Post by kristoff_it »

tmtvl wrote: post #63
flohofwoe wrote: post #17

Earlier quoted context omitted.

UFCS is hardly "OOP", it's just a bit of syntax sugar to allow function call chaining instead of nesting.

But isn't function call chaining generally an antipattern? And you can do it without Universal Function Call Syntax anyway, and besides... it's ugly as hell. # Writing it like this is bad: print (length (drop_failed (get_students (school_system)))); # But like this is okay? school_system.get_students().drop_failed().length().print();

Chaining this much is not really recommended in Zig. An idiomatic implementation of that stuff would not allow you to chain this much.

Additionally, in Zig temporaries (which you would be implicitly constructing by chaining) are immutable, meaning that a chain of calls would only compile as long as it doesn't try to mutate any intermediate value (which is a nice protection against footguns).

But really, this is a coding style that's considered fine in Rust, not in Zig.

Re: Zig: The Modern Alternative to C

#89

Post by afiori »

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.

using the wrong variable in repeated code:

value1 value2 g(value1)

g(value1)

or other similar cases

Re: Zig: The Modern Alternative to C

#90

Post by eska »

kaba0 wrote: post #85
eska wrote: post #81

Earlier quoted context omitted.

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

Which is absolutely not solved by assigning it to _ neither, if anything it will just make the variable appear used in syntax highlighting and that will make me forget to properly use it! IDEs just gray out the unused variables and that is an 1000x better way of handling this issue.

I think you misunderstand the purpose of assigning to _.

Extremely common bug 1: a function returns an error/future, but you don’t check/poll it “foo();”. May happen because you copy some tutorial code that’s not rigid about error checking, or you don’t realize that this language doesn’t have futures that run without being polled.

Quite common bug 2: you store the error/future, but don’t check/poll it “let a = foo();”. May happen when moving code, certain branches, copy paste error, not enough coffee.

Opt-in: it doesn’t matter if the call succeeded or the future is polled, leave me alone “let _ = foo()”. May happen in test code for example. This is not the common case, so the opt-in annoyance is justified to improve the common case.

Post reply on HN