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

51–60 of 181 posts

Re: Zig: The Modern Alternative to C

#51

Post by flohofwoe »

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.

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 the TS compiler and linters are usually configured to also catch any unused variables as "errors" I no longer see Zig's stance on the same thing as critical as before, it's more or less "just" a tooling issue.

Re: Zig: The Modern Alternative to C

#52

Post by tialaramex »

gpderetta wrote: post #37
oriolid wrote: post #34

Earlier quoted context omitted.

C++ has syntax for adding functions to objects and type system support for deriving object types from other object types and overriding those member functions. There are some who consider these a rather important thing.

I'm just saying that, pedantically, "object" is a term of art in C and C++ which has little to do with the typical OOP definition of object.

Indeed. For example the language needs a notion of these objects having some particular type, and they need to be able to have lifetimes, so that we can talk about ideas like type punning (legal in C in some ways, not legal in C++), about aliasing rules, and about provenance.

If you don't want to do any of this, you can't achieve the performance from high level software (where "high level" here means C rather than machine code) that people have come to expect and demand.

Re: Zig: The Modern Alternative to C

#53

Post by zozbot234 »

gpderetta wrote: post #37
oriolid wrote: post #34

Earlier quoted context omitted.

C++ has syntax for adding functions to objects and type system support for deriving object types from other object types and overriding those member functions. There are some who consider these a rather important thing.

I'm just saying that, pedantically, "object" is a term of art in C and C++ which has little to do with the typical OOP definition of object.

These are pretty much the same thing, though. The C-specific definition of "object" was devised to make C usable with hardware architectures like segmented memory, which was being marketed as "OOP down to the hardware" back in the 1980s. The fact that the term "object" is used here is not a coincidence.

Re: Zig: The Modern Alternative to C

#54

Post by hawski »

rahen wrote: post #39
hawski wrote: post #13

Earlier quoted context omitted.

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 would be interested in hearing more about your point. TCL is an elegant scripting language, very LISP-y, where most data structures are lists of strings. Go on the other hand is more like a modern mix of C and Pascal with GC and lots of convenient libraries, and which builds statically. The performance of TCL and Go are also a world apart.

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.

Re: Zig: The Modern Alternative to C

#55

Post by Gigachad »

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.

Really seems like something that should be a lint rule..

Re: Zig: The Modern Alternative to C

#56

Post by cassepipe »

kissgyorgy wrote: post #49

"that could one day replace C" I don't understand why would anybody say that, it's seems such a simple concept to me that nothing ever will replace C. Think about just the Linux kernel, nothing else. Nobody will and can rewrite every part of it that a C compiler will not be needed.

The meaning is obviously to replace C in situations where C shines when writing new code. No one is talking about rewriting the Linux Kernel. Even the Zig project's explicit goal is to be seamlessly interoperable with C in order to build upon already written C code.

Re: Zig: The Modern Alternative to C

#57

Post by Gigachad »

kissgyorgy wrote: post #49

"that could one day replace C" I don't understand why would anybody say that, it's seems such a simple concept to me that nothing ever will replace C. Think about just the Linux kernel, nothing else. Nobody will and can rewrite every part of it that a C compiler will not be needed.

I doubt every single line of C will be removed considering a lot of it is drivers for hardware no one has anymore, but I’d say in 10 years the majority of actually used code in the Linux kernel will be Rust. The Asahi project has shown that Rust is the better choice for kernel code right now.

Re: Zig: The Modern Alternative to C

#58

Post by kaba0 »

flohofwoe wrote: post #51
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.

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 is an error for all I care, and a “debug” one where it really shouldn’t be linting my code unnecessarily.

Re: Zig: The Modern Alternative to C

#59

Post by flohofwoe »

tialaramex wrote: post #50
flohofwoe wrote: post #23

Earlier quoted context omitted.

> No objects, just structs C doesn't have 'objects' either, just structs. In Zig you can add functions to structs though, and you have UFCS syntax sugar, both together is pretty close to class methods ;) Those sentinel terminated arrays are a killer feature for C API interop, since you don't need to allocate separate C strings on the stack or heap just for passing string literals into the C API (Zig string literals a…

> 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-terminated arrays are a pretty clever solution to the problem (even though they still need a temporary allocation to convert a regular slice to a zero-terminated slice for "dynamically built strings", but one can get surprisingly far with just string literals).

Post reply on HN