Live data from Hacker News

Maintain It with Zig

kristoff.it

71–80 of 286 posts

Re: Maintain It with Zig

#71
post #63

Earlier quoted context omitted.

There is also the notion of languages you love writing code in vs languages you like reading code in. Languages with more powerful abstraction abilities bring joy to the writer but make things tedious for the reader.

Totally. I personally would not agree with > Languages with more powerful abstraction abilities bring joy to the writer but make things tedious for the reader. I find map/filter to be easier to read than a C-style for loop. Things that are conceptually denser make discussion between experts easier, even if it makes things harder for non-experts. This is why jargon exists, for example.

Ah yes - that makes sense. I should have been more precise - I meant abstractions that allow you to add opaqueness (like macros and operator overloading). Again culture plays a role here too - some communities normalize such abstractions more than others.

In short I believe languages that one can pick up in a couple of days and then read code where reasoning of the code is highly local would stand a higher chance of being perceived as simple.

Re: Maintain It with Zig

#72
post #5
post #4

Interesting; this piece advocates for porting only (or at least initially) the build system of C/C++ projects to use the Zig compiler and the build.zig build system for cross-compiling dependencies. A package manager in the works could be interesting too. I don't do C/C++ development. How many headaches would using Zigs compiler & build system solve?

Zig has painless cross compilation, with gcc or clang it's a nightmare

o.O

Zig uses LLVM for cross compilation, and so does clang. It's really not any better.

https://clang.llvm.org/docs/CrossCompilation.html

Re: Maintain It with Zig

#73
post #69

Earlier quoted context omitted.

As a counterpoint, I remember when someone satirized RIIR on HN and the post was flagged into oblivion even though the comments section was mostly approving. https://news.ycombinator.com/item?id=25198571 Someone reposted the same document with Rust replaced with "$hotlang" which, for a reason you can guess, wasn't flagged at all: https://news.ycombinator.com/item?id=25208313 My impression is that there are more than…

Agree with what you said. Another data point I noted how often popular Rust associated people hit Twitter whining about a disagreement they had on hacker news. I have almost never seen with other popular/mainstream programing languages. But for Rust it is regular thing.

Oh I’ve been doing that since before Rust existed. And I assure you, complaining about Hacker News goes beyond Rust folks. Heck, even pg has complained about Hacker News on Twitter.

Re: Maintain It with Zig

#74
post #70

The author seems to be under the impression that Rust cannot live harmoniously within the C ABI ecosystem, which is false. To some extent. Rust, due to relying on LLVM, is limited by its available targets; and so cannot enjoy the full access that C/C++ can. The same is true for Zig, however, since it does not compile to C.

yet.

Re: Maintain It with Zig

#75

> added a Rust dependency which in turn changed the list of supported platforms My understanding is that `zig cc`/`zig c++` are thin wrappers around LLVM, so doesn't that just reintroduce the same problem?

‘zig cc’ is more than that. You get a very powerful caching system, and built in support for cross compilation to a huge range of targets (via zig shipping with libc sources). Zig is extremely impressive.

The built in cross compilation is just LLVM; it's a narrower set of targets than GCC, and a _far_ narrower set of targets than where you'll find a C compiler.

clang cross compilation is not really any harder, you just supply the -target flag.

Re: Maintain It with Zig

#76

> added a Rust dependency which in turn changed the list of supported platforms My understanding is that `zig cc`/`zig c++` are thin wrappers around LLVM, so doesn't that just reintroduce the same problem?

llvm’s platform support or the lack thereof was not the issue, it was assuming you had a compiler other than a C compiler installed at all on certain platforms. This would have affected zig in the same way, or any non-C language.

Re: Maintain It with Zig

#78
post #48

Earlier quoted context omitted.

Probably related to the following: https://github.com/ziglang/zig/issues/3180

Gee, IIUC it looks like it's been addressed by offering a new allocator that's able to detect use-after-free.

To be fair this alone is nowhere near what Rust can do for you in terms of safety.

Re: Maintain It with Zig

#79
post #15

Earlier quoted context omitted.

I think that's correct with some overlap, yes. Zig's explicit goal - as stated by the creator - is to replace C. Nothing more, nothing less. I feel like Rust wants to replace C but it also wants to replace C++. And given the complexity difference between the two languages, that means that Rust will end up closer to C++ than to C. So there's some overlap based on how Rust positions itself, but not based on how Zig pos…

> Zig's explicit goal - as stated by the creator - is to replace C. Nothing more, nothing less. The ZIG compiler requires a C compiler to compile to a native executable though.

> The ZIG compiler requires a C compiler to compile to a native executable though.

No it doesn't? Not unless you want to also compile C, which the Zig compiler is capable of doing because it bundles clang.

Re: Maintain It with Zig

#80
post #64
post #6

Zig is a very interesting language. You are able to do thing that would require wizard level skills in C with simple plain language construct. Like serializing/deserializing an enum variants over the wire for example in the most efficient way (look at std.json.{parser, stringify} [0]). > soon we’ll also have a package manager This. If they succeed to do this (and I have my doubts) it will be a paradigm shift for low-…

I've been toying with Zig over the summer, and I'm really impressed by the build system, general ergonomics and the explicitness of the language. The only thing I've found being a pain point is C's biggest pain point: the lack of a proper string type. Even though I've worked for years in the past with C and C++, I still get tripped up, and in Zig I keep on being confused whether I should use raw byte arrays, or senti…

> I've always tried as much as possible to treat strings as just opaque data and never look into them, which tends to work well, but in some domains you really need to look at and massage the characters/codepoints/grapheme clusters, and the lack of a first-citizen UTF-8-aware string type is, I think, a bit unfortunate in this day and age.

You don't need a string type for that, you just need routines that handle UTF-8 strings, like utfcpp (https://github.com/nemtrif/utfcpp).

Post reply on HN