Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maintain It with Zig

kristoff.it

Post reply on HN
Print view View original

111–120 of 286 posts

Re: Maintain It with Zig

#111

Post by AndyKelley »

moogly wrote: post #64
skywal_l wrote: 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…

Out of curiosity, what are you working on that requires a proper string type (rather than encoded UTF-8 bytes)?

Re: Maintain It with Zig

#112

Post by kristoff_it »

kllrnohj wrote: post #98
dleslie wrote: 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.

Yeah it was a really odd choice of a "why not Rust" bug since the problem with Rust in that bug applies entirely to Zig as well. So if you can't use Rust because it doesn't have the broad compiler support that C does, you almost certainly can't use Zig either for the exact same reason. And then the article touts Zig using their own in-house linker, which seems inevitable to have less platform support than LLVM will?…

> which seems inevitable to have less platform support than LLVM will?

ZLD can link for M1 while LLVM can't yet. And Zig can also use lld alongside it to increase the platform coverage.

> but you can't claim that's a benefit at the same time the problem with Rust is it's lack of fringe system support... :/

I find it hard to believe that a dispassionate reader could misinterpret to this degree the goal of a sentence written in a chapter dedicated entirely to showcase the limits of rewriting code in another language, be it RIIR or RIIZ.

See my reply to the parent comment for the intended meaning of that example.

Re: Maintain It with Zig

#113

Post by kaibee »

abledon wrote: post #96
nrclark wrote: 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…

We already have c/c++ as low level bases, now zig/rust are coming for the throne, I really hope contenders dont keep spawning like rabbits. If everyone got behind a smaller # of initiatives the worlds codebase would be simpler going forward? I'm imaging some poor software engineer in 2065, having to maintain an enterprise legacy stack... levels of FORTRAN/COBOL->C->C++->ZIG->RUST->PERL->PYTHON.... all the way up....J…

> I'm imaging some poor software engineer in 2065, having to maintain an enterprise legacy stack... levels of FORTRAN/COBOL->C->C++->ZIG->RUST->PERL->PYTHON.... all the way up....JS..etc..

I have good news and bad news: That programmer will not know any of those languages, as they will just program in English and GPT-3000 will convert it into code.

Re: Maintain It with Zig

#114

Post by AndyKelley »

nrclark wrote: post #15
_6pvr wrote: post #8

Earlier quoted context omitted.

I've been paying attention to Zig posts on HN, mostly just because it seems well-liked and I think Andrew Kelley is interesting/smart. Would it be fair to say that Zig is to C, what Rust is to C++? Or are they both just kind of...low-ish-level systems languages solving similar problems, differently?

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…

You can find Zig's explicit goal as stated by the creator on the homepage:

> Zig is a general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.

Re: Maintain It with Zig

#115

Post by adamdusty »

torginus wrote: post #109

Generally speaking, what killed C++/C for me is the absolute insanity that comes with it's build systems/third party dependency management. I feel like the notoriety that C++ gets for it's absurd complexity comes not from variadic template metaprogramming/rvalue references/unique_ptr or whatever, but the absolutely humongous effort needed to understand automake/CMake/autotools just to build other people's code (god f…

The build system for zig is essentially the same as CMAKE just in Zig and entirely undocumented.

Re: Maintain It with Zig

#116

Post by dleslie »

kristoff_it wrote: post #110
dleslie wrote: 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.

> The author seems to be under the impression that Rust cannot live harmoniously within the C ABI ecosystem, which is false. The author is not under any such impression. The key point is that Zig can cross-compile C/C++ code, while Rust can't. If you have a Rust project that depends on C code, you will have to put in some work if you want to compile it for a different target. That's a pretty big difference in practic…

Zig itself doesn't cross compile C/C++ code, LLVM does the work for Zig.

> If you have a Rust project that depends on C code, you will have to put in some work if you want to compile it for a different target.

Rust is built on LLVM, and so its toolchain can also cross-compile C/C++ code. There are crates for that[0], and projects inspired by that idea[1].

> Give it some time, it will.

Given enough time mountains become valleys. Zig doesn't compile to C now; and won't be mature and field-tested for a decade or more.

0: https://crates.io/crates/cc

1: https://www.build2.org/

Re: Maintain It with Zig

#117

Post by pjmlp »

torginus wrote: post #109

Generally speaking, what killed C++/C for me is the absolute insanity that comes with it's build systems/third party dependency management. I feel like the notoriety that C++ gets for it's absurd complexity comes not from variadic template metaprogramming/rvalue references/unique_ptr or whatever, but the absolutely humongous effort needed to understand automake/CMake/autotools just to build other people's code (god f…

I just build a VS solution, call MSBuild, install dependencies via NuGET/vcpkg and be done with it.

And even better since they support binary libraries, I can focus on my own code instead of building the foundations first.

Re: Maintain It with Zig

#118

Post by kristoff_it »

dleslie wrote: post #103
messe wrote: post #97

Earlier quoted context omitted.

> If someone wanted to package clang to do that, they could. They do, in fact, that's how clang cross compilation packages work. Clang doesn't bundle a C standard library implementation. > But sure, to Zig's credit, they ship all the supported toolchains and so don't have many different cross compilation variants in the OS's package manager. But that's a bit like buying one of everything, even though you'll only use…

> Clang doesn't bundle a C standard library implementation. ... So? It can use most any you wish. > Zig only bundles the sources, so it builds the C library on-demand. Which it then caches, post-compilation, taking up binary space on disk comparable to if you just downloaded the pre-compiled target binaries.

> Which it then caches, post-compilation, taking up binary space on disk comparable to if you just downloaded the pre-compiled target binaries.

I don't understand the point of this comeback. If you have the artifact cached it means that you compiled for that target, while the rest of the stdlibs remain in source form (also Zig deduplicates header files which is why everything fits in a 40mb tarball), and you didn't have to download anything manually. What else would you want exactly?

Re: Maintain It with Zig

#119

Post by [deleted] »

torginus wrote: post #109

Generally speaking, what killed C++/C for me is the absolute insanity that comes with it's build systems/third party dependency management. I feel like the notoriety that C++ gets for it's absurd complexity comes not from variadic template metaprogramming/rvalue references/unique_ptr or whatever, but the absolutely humongous effort needed to understand automake/CMake/autotools just to build other people's code (god f…

[deleted]

Re: Maintain It with Zig

#120

Post by AndyKelley »

skywal_l wrote: 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-…

> Let's hope this is not vaporware.

I sincerely approve of the skepticism. I can assure you there is already a very large fire under my ass to get this shipped.

To provide some more context, here is a snippet from the latest release notes[0]:

> Having a package manager built into the Zig compiler is a long-anticipated feature. Zig 0.8.0 does not have this feature.

> If the package manager works well, people will use it, which means building Zig projects will involve compiling more lines of Zig code, which means the Zig compiler must get faster, better at incremental compilation, and better at resource management.

> Therefore, the package manager depends on finishing the Self-Hosted Compiler, since it is planned to have these improved performance characteristics, while the Bootstrap Compiler is not planned to have them.

I can't help but mention, I am incredibly excited about how well the self-hosted compiler is coming along. Progress is swift, and all the ambitious design decisions (fully incremental compilation[1], extremely fast debug builds[2], low memory usage, multi-threaded) are intact. I anticipate it to make quite a splash once it becomes generally usable.

I don't expect the package manager to take nearly as long to develop.

[0]: https://ziglang.org/download/0.8.0/release-notes.html#Packag...

[1]: https://vimeo.com/491488902

[2]: https://twitter.com/andy_kelley/status/1416485475125141504

Post reply on HN