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

91–100 of 181 posts

Re: Zig: The Modern Alternative to C

#91

Post by humanrebar »

flohofwoe wrote: post #30
andrewstuart wrote: post #26

Of all the new languages I find zig most interesting because it claims to not need build systems (not sure if I have that right?), it focuses on c library compatibility, and most importantly it aims to be a small language. I’d like to love rust but it’s so big I just don’t have time to learn it all. It’s a pity rust is so damn big. Anyhow zig looks like a great alternative even if it lacks the safety of rust.

> because it claims to not need build systems Zig has a build system, but it's integrated into the compiler and stdlib (e.g. there's usually a 'build.zig' file in the project root which is regular Zig code using 'build system' modules from stdlib, this build.zig is then transparently compiled and run to 'perform the build'). (it's interesting that nothing of this is so special to Zig that other compilers - even C com…

Honestly, the lack of separation of concerns between compiling, linking, building, and packaging is what gives me pause about zig. I don't see it having a nice onramp for my existing C and C++ codebases.

It's trying to make a new systems programming ecosystem, sort of, but also trying to interop well with C source code but not at the tooling level... not exactly a coherent adoption curve.

Re: Zig: The Modern Alternative to C

#92

Post by pornel »

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.

Re: Zig: The Modern Alternative to C

#93

Post by rom-antics »

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 agree. I gave Zig a fair shake, even went so far as to find the compiler PR that automatically adds `_ = foo` to your source code while compiling[1] and set up the VSCode extension with autofix. I couldn't get used to seeing the lines with `_ =` appear and disappear all over my code while I was typing.

With the usual warnings approach, you can rely on compiler/IDE/pre-commit tooling to find unused variables - they'll all nag you until it's fixed. With Zig's autofix approach, those problems are immediately silenced and you don't have any help from the compiler or tooling to find unused variables. It's quite an ironic outcome if you think about it.

[1]: https://github.com/ziglang/zig/pull/12803

Re: Zig: The Modern Alternative to C

#94

Post by anecdotal1 »

guntherhermann wrote: post #27
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.

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

Re: Zig: The Modern Alternative to C

#96

Post by jstimpfle »

tialaramex wrote: post #83
flohofwoe wrote: post #59

Earlier quoted context omitted.

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

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. They offer an in-band signal that is sometimes very practical. Slices are more generally flexible, especially w.r.t substrings, but when you look at a memory dump for example it's great to have those terminators.

> once you're not talking directly to the kernel ABI you're free to choose abstractions which better suit both sides.

Requiring string copies just to reshape arguments according to idealistic beliefs is a huge yak shave. It means creating all those wrappers, handling all those extra failure modes, and coming up with extra versions of records (often on-disk structures) that have fixed size zero-terminated string buffers embedded.

Re: Zig: The Modern Alternative to C

#97

Post by drogus »

hawski wrote: post #13
sgt wrote: post #5

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

It is not an alternative to Go same as C++ or Rust is not really an alternative to Go. They are on a different level, but can do the same job. Though I could argue that Tcl could be an alternative to Go, I think many would not agree. Zig has manual memory management, doesn't have much of a runtime (no CSP out of the box) and above all is not mature yet (breaking changes do happen). As of now it has one of the best st…

I'm hearing this so often that I think I have to write a blog post some day. I think both Zig and Rust can be an alternative to Go. Zig is still young, so it probably lacks tools for many domains, but if it grows I expect it to get more tooling similarly to what's happening for Rust. So just talking for Rust today, it's used in:

- gaming

- web apps

- networking

- CLIs

- distributed systems

- crypto

- systems programming (like for example databases)

- language tooling (for example JS ecosystem has a lot of Rust based tools being developed right now)

and probably much more.

Go is used for every single of these categories too. Databases? Check. Networking? Check. CLIs? Check. And so on, and so on. The truth is that it's often a matter of taste, timing and various constraints that are often non technical at all.

Taste is the most subjective reason, nevertheless it's often a driving choice. If I start a new personal project I usually default to Rust these days, unless it's a bad fit, but I've successfully used Rust in many different domains, so it's safe to say Rust covers most of my programming needs (other than maybe a quick throwaway script). Even if Go was a sligtly better fit, I would choose Rust anyway, cause I just enjoy it more.

When it comes to constraints, I think that is most often relevant in a professional setting. I've worked in many different companies and very rarely, especially when a company is on the bigger side, you can just choose whatever tools you want just based on technical requirements. If a company is a Ruby shop, they will have to have a very strong reason to start a new project in a different language, even if it is clearly a better choice. But then a good question is: what makes a tool a better choice? It will very often be really hard to tell until you actually do the project. Have you ever been in a discussion about choosing a new language for a project? I have been, lots of times. One time was especially interesting, cause we were discussing what to use for a real time application keeping a long running websocket connections. We were considering Ruby (it was a Ruby shop), Go, Elixir and Rust. We chose Rust in the end, but I'm sure that we could have been successful with Elixir or Go too. The most interesting part? There was an experienced developer that was pushing for Ruby hard. He was working as a "Principal Engineer" and if it was up to him I'm sure he would have chosen Ruby, which for me was the least feasible choice. Would it be a good choice? I don't think so, but I can't say for certain and we will probably never know. So as you can see, even with very clear requirements people will disagree on "the best tool for the job" (which is also why I hate this term). But even if everyone agrees on a technical aspect, there might be also other constraints. If a company is growing very fast they might be worried about hiring for example. And they may choose a language that is technically a bit worse than some alternatives, but has a bigger talent pool.

Timing is a tricky one, cause at the moment both languages are quite mature, but if you think about it, a lot of well known big projects in Go (k8s, docker, terraform etc) were started when Rust was honestly quite rough. So while I'm not saying if k8s was started today, it would be definitely started in Rust, I think that at least some of those projects might consider Rust. The same goes for companies that are invested in Go already. Even if Rust made sense for some of the new projects they would probably lean heavily towards Go, cause of a collective company experience.

So, yes, Rust is an alternative to Go in many (most?) domains. In the same way Zig can be in this place too when it gets more tooling and maturity.

Re: Zig: The Modern Alternative to C

#98

Post by tialaramex »

flohofwoe wrote: post #62
kaba0 wrote: post #58

Earlier quoted context omitted.

But why should I have to recursively modify my code when I am experimenting with shit? Like, am I the one that does something wrong, because commenting/uncommenting a single line to check the outcome of a program is extremely common in my workflow, and that fkin compile error can absolutely throw me out of the loop of what I was trying to do. And it is not even hard to solve, just add a “production” profile where it…

To be clear, I would also actually prefer if those were warnings in development mode, but so far at least Zig has no warnings, only errors. But I'm open to the idea that the Zig team knows what they are doing ;)

AIUI Zig has embraced the view that either something is bad, and so it's an error and we shouldn't compile, or it's fine so no need for a warning. I don't think this actually is a reasonable stance although I can see why C might make you think so.

Rust's linter, clippy, provides a rich seam of stuff that definitely shouldn't be fatal but some / many people would value knowing about. For example yesterday I built a Range which intentionally is the wrong way up, isize::MAX..isize::MIN - and so clippy says well, that's probably not what you wanted. This is a good lint. If I ever do the same thing by mistake I definitely want to know about it, but this time was not a mistake, so I wrote an allow attribute on that Range to silence the linter and also flag to readers, "No, this is on purpose".

Re: Zig: The Modern Alternative to C

#99

Post by naasking »

humanrebar wrote: post #91
flohofwoe wrote: post #30

Earlier quoted context omitted.

> because it claims to not need build systems Zig has a build system, but it's integrated into the compiler and stdlib (e.g. there's usually a 'build.zig' file in the project root which is regular Zig code using 'build system' modules from stdlib, this build.zig is then transparently compiled and run to 'perform the build'). (it's interesting that nothing of this is so special to Zig that other compilers - even C com…

Honestly, the lack of separation of concerns between compiling, linking, building, and packaging is what gives me pause about zig. I don't see it having a nice onramp for my existing C and C++ codebases. It's trying to make a new systems programming ecosystem, sort of, but also trying to interop well with C source code but not at the tooling level... not exactly a coherent adoption curve.

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

Re: Zig: The Modern Alternative to C

#100

Post by nemoniac »

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…

> That article is about control flow and syntax, which isn't a big problem. What matters is data.

I fully agree that what matters is data but I stumbled over your remark that control flow and syntax mightn't be an issue. In fact I'd go so far as to say that above a certain level of abstraction it's all about control flow and syntax. But then Zig doesn't seem to be addressing such levels so perhaps you're right.

Post reply on HN