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

61–70 of 181 posts

Re: Zig: The Modern Alternative to C

#61

Post by tialaramex »

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.

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 can produce languages which don't do anything well by compromising everywhere - but one of the negatives of visionaries is that they can stubbornly stick to their preferences overriding any other consideration. Andrew is quite sure he's right, nothing will overcome that.

It's OK, C++ manages to suffer from afflictions of a single coherent vision (Bjarne Stroustrup's) and having an unwieldy committee structure (WG21 the "C++ Standards Committee") and despite the resulting flaws it was enormously successful.

Re: Zig: The Modern Alternative to C

#62

Post by flohofwoe »

kaba0 wrote: post #58
flohofwoe wrote: post #51

Earlier quoted context omitted.

The feature is really quite ok when working in an IDE where those errors are displayed immediately as error squiggles, and there's now also an error for any 'left-over' _ = unused_variable; ...statements (although I'm starting to prefer Typescript's convention to mark unused variables and function parameters with a leading underscore to suppress unused errors). In any case, once I started to write more TS code where…

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

Re: Zig: The Modern Alternative to C

#63

Post by tmtvl »

flohofwoe wrote: post #17
wheelerof4te wrote: post #14

Too many dots. It feels like programming in a OOP language, which C isn't.

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

Re: Zig: The Modern Alternative to C

#64

Post by wheelerof4te »

flohofwoe wrote: post #17
wheelerof4te wrote: post #14

Too many dots. It feels like programming in a OOP language, which C isn't.

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

So, instead of doing functions like every other modern language in history, you intentonally introduce foreign syntax?

And still compare it to C?

Re: Zig: The Modern Alternative to C

#65

Post by wheelerof4te »

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

That makes it seem like every function call returns an object, that calls it's own method.

Weird.

Re: Zig: The Modern Alternative to C

#66

Post by flohofwoe »

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

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

Re: Zig: The Modern Alternative to C

#67

Post by tmtvl »

wheelerof4te wrote: post #65
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();

That makes it seem like every function call returns an object, that calls it's own method. Weird.

That is Uniform Function Call Syntax, cfr. Wikipedia: https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax

Re: Zig: The Modern Alternative to C

#68

Post by carlmr »

laserbeam wrote: post #41
carlmr wrote: post #36

Earlier quoted context omitted.

That's really cool. I'm wondering though how Zig handles massive concurrency? Is there some possibility to have greenthreading?

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 just wondering because the article mentioned Zig having a lot of the benefits of Rust and Go, and this is one thing where Rust doesn't shine, so I was wondering if they had an answer for this.

Re: Zig: The Modern Alternative to C

#69

Post by coldtea »

DixieDev wrote: post #42

I think the official Zig website already does a good enough job at expressing what the the language has to offer, to the extent C devs can read a couple of pages and know whether or not they vibe with the language. The only thing it's missing is quoted praise from its users. https://ziglang.org/learn/overview/ https://ziglang.org/learn/why_zig_rust_d_cpp/

>The only thing it's missing is quoted praise from its users.

"I can't believe it's not C!"

Re: Zig: The Modern Alternative to C

#70

Post by coldtea »

hawski wrote: post #10
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.

Yes, but it still is a part of the standard library and how the standard library does things - a convention. Same as in C, as malloc is just a function. You could create a replacement library for C stdlib and it could also expect an allocator in the parameters if a given function could allocate.

>Yes, but it still is a part of the standard library and how the standard library does things - a convention. Same as in C, as malloc is just a function.

Yes, but it doesn't argue that it's not the same in C. Just that it's not the same as languages who do the memory allocation themselves.

>You could create a replacement library for C stdlib and it could also expect an allocator in the parameters if a given function could allocate.

You could do anyting in C, even write Zig in it. And vice versa, you co do malloc in Zig. But allocators are how Zig is designed/used, whereas C opts for malloc.

Post reply on HN