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

101–110 of 181 posts

Re: Zig: The Modern Alternative to C

#101

Post by flohofwoe »

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.

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 build as number of build steps and their dependencies. There's really no reason why this build description should happen in a separate build tool and language.

Re: Zig: The Modern Alternative to C

#102

Post by naasking »

flohofwoe wrote: post #66
tmtvl wrote: post #63

Earlier quoted context omitted.

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();

Personally I find the chaining a lot more readable, but maybe that's just me :)

It's not just you. Long function chains/nested function calls are discouraged in most languages for readability reasons, but chaining is 100% more readable to everyone who has tried both for any appreciable length of time.

Re: Zig: The Modern Alternative to C

#103

Post by anonymoushn »

pron wrote: post #84
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…

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 and compare it to null.

Re: Zig: The Modern Alternative to C

#104

Post by giancarlostoro »

pornel wrote: post #92
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.

You can still have it but add more modern syntax for looping. Hell Java has "goto" reserved if I remember correctly.

Re: Zig: The Modern Alternative to C

#105

Post by humanrebar »

flohofwoe wrote: post #101
humanrebar wrote: post #91

Earlier quoted context omitted.

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.

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.

Re: Zig: The Modern Alternative to C

#106

Post by HeavyFeather »

kaba0 wrote: post #46

Does Zig still have that insane compiler enforced no unused variables policy? Honestly, that is such a stupid thing that it literally kept me away from the language, which I otherwise find interesting for its niche.

“Insane” really? How so? In what world do unused variables make sense?

Re: Zig: The Modern Alternative to C

#107

Post by Decabytes »

I tried using Zig for a little bit, and it just doesn't feel ergonomic to use _for me_. It's not 1.0 so I'm hoping that a lot of that will be ironed out, but some of it is baked into the language. Being forced to assign variables to _ if you aren't using them somewhere else in the program annoyed me a lot more than I expected. Especially in the learning phase when you are asking a lot of questions and have to write up toy examples of what you are trying to do when asking people for help.

I also ran into an issue where I wanted to initialize an array with 30k 0 values and I ended up having to write a loop to do it, and ran into issues with the loop and assigning values. It felt like if the language was going to be militant about certain things to prevent you from making mistakes, that it should just go the whole way. At least with Rust after fighting with the borrow checker I would know I had a safe program. With Zig I have to fight with the langauge, but then it's not even memory safe once I get everything working

Re: Zig: The Modern Alternative to C

#108

Post by humanrebar »

naasking wrote: post #99
humanrebar wrote: post #91

Earlier quoted context omitted.

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?

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.

Re: Zig: The Modern Alternative to C

#109

Post by AnIdiotOnTheNet »

mcdonje wrote: post #95

It looks like Zig doesn't have a GC. Does it have any improvements over C in that area? Like Rust's lifetimes?

Short answer: not exactly, no.

Long answer: Zig does a lot of stuff to make the easy way of dealing with memory the correct way. The typical pattern is to use defer/errdefer statements to clean up on end of scope or in case of error. One of the included allocators checks for leaks and use after free, and it is trivial to change which allocator is used based on build mode. It is also very strict about pointers and has a whole lot of different kinds to represent different use cases and include appropriate safety checks (in safe and debug modes) when dealing with them.

Re: Zig: The Modern Alternative to C

#110

Post by kps »

jenadine wrote: post #18
loeg wrote: post #8

Earlier quoted context omitted.

The point that paragraph is trying to make but articulates imperfectly is that you explicitly pass an Allocator to the stdlib routines that allocate -- rather than having them allocate on the heap implicitly.

So you have coloured functions? The red that can allocate, and the blue that cannot?

Well, you have expicit allocators. A popular branch of the field calls this ‘dependency injection’. It's true that the current standard library never allocates implicitly, because that would be bad on constrained projects, but there's nothing stopping you from writing code that does so, or presumably even using libc.
Post reply on HN