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

221–230 of 286 posts

Re: Maintain It with Zig

#221

Post by optymizer »

AndyKelley wrote: post #120
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…

Hi Andy, I'm really intrigued by Zig's features - you're definitely solving the right and hard problems for C developers like myself.

If I may, my only piece of feedback (as someone who looked at Zig with fresh eyes) is that the syntax has lots of special chars (@, !void, .{}, &, etc). Is there a rationale published for these and other design choices (even if it's "I like it that way"). I would have expected a language with ambitious goals like Zig to take a stab at coming up with a grammar that's even simpler and cleaner than C.

Regardless, getting a new programming language working, noticed and used is monumental effort, so I wish you best of luck with Zig!

Re: Maintain It with Zig

#222

Post by dnautics »

optymizer wrote: post #221
AndyKelley wrote: post #120

Earlier quoted context omitted.

> 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…

Hi Andy, I'm really intrigued by Zig's features - you're definitely solving the right and hard problems for C developers like myself. If I may, my only piece of feedback (as someone who looked at Zig with fresh eyes) is that the syntax has lots of special chars (@, !void, .{}, &, etc). Is there a rationale published for these and other design choices (even if it's "I like it that way"). I would have expected a langua…

One of the things after working with zig for a bit, is that the dangerous stuff is cumbersome to write (not hard to read, though), and has lots of fiddly bits like @ signs... So your eye is drawn to it as if to say "here are the parts of the code that need careful review".

Relative to c, though there are imo fewer special chars:. Zig adds ! and ?, Which are there for really good reason, but subtracts for example and #.

The hardest thing is the . syntax for anonymous structs and tuples, but to be fair it is very consistent, and so many times I'd think,"hey I wonder if..." And then try it with the syntax and of course it works.

Re: Maintain It with Zig

#223

Post by travisgriggs »

rattray wrote: post #16
_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 they solve some similar and some different problems, with some similarities and differences! The biggest difference in the problems they solve, in my view, is that Zig does not aim for safety. It'll be easier to write safe programs yourself with Zig than it might be with C, but it doesn't give you any guarantees. Zig also seems like it may be a better fit for embedded programming; there's a big community arou…

I write/maintain multiple code bases for XMega, SAMD, and STM chips. The kind where 32K ram is cool and 256K flash is lots. I'm curious if either of these is ready for normal humans to cross compile for these kinds of targets (M0 and the ilk). Zig looks very interesting to me.

Re: Maintain It with Zig

#224

Post by coldtea »

losvedir wrote: post #95
moogly wrote: post #64

Earlier quoted context omitted.

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…

Note that while strings are generally opaque bytes in Zig, there are standard library functions[0] to work with them as Unicode codepoints and such. But Unicode is quite large and complicated, and things like grapheme clusters aren't in the standard library (yet?). I also believe that that module is planned to be rewritten. So it's more the case that Zig plans to someday support Unicode at the standard library level,…

>*It's nice to let the type system help you enforce your application boundaries, but I think you could wrap it pretty easily in a struct of your own if you needed that.

Well, as you said "Unicode is quite large and complicated".

And in 2021 it's not just anglosaxon software users anymore (if they ever were), good unicode lib if not type is a must.

Re: Maintain It with Zig

#225

Post by coldtea »

tialaramex wrote: post #161
losvedir wrote: post #95

Earlier quoted context omitted.

Note that while strings are generally opaque bytes in Zig, there are standard library functions[0] to work with them as Unicode codepoints and such. But Unicode is quite large and complicated, and things like grapheme clusters aren't in the standard library (yet?). I also believe that that module is planned to be rewritten. So it's more the case that Zig plans to someday support Unicode at the standard library level,…

> Basically just a flag that the array of bytes has been checked and is valid? In something like Zig I think it's OK that it's merely a stated assumption that these bytes are UTF-8, not actually checked - so long as people take that seriously. It's nice in code that maybe isn't very concerned with such things to be able to know that any "string" is actually text we can display, output to a console, something like tha…

>In something like Zig I think it's OK that it's merely a stated assumption that these bytes are UTF-8, not actually checked - so long as people take that seriously.

And also as long as all supported operations on those bytes still result in utf-8 strings (there could be unsafe operations too, like splitting at a random byte offset, but there should be a clearly marked safe set that wont corrupt a valid utf-8 byte sequence).

Re: Maintain It with Zig

#226

Post by coldtea »

kristoff_it wrote: post #93
10000truths wrote: post #80

Earlier quoted context omitted.

> 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…

Agreed, and Zig also has a lib for that as well: https://github.com/jecolon/ziglyph/

If it's not a single official library, then this will just end up in a future mess...

Like in any language with any lib that is not self-contained (cuts across all aspects of a program and can be used anywhere) and has many different implementations and no sanctioned one.

Re: Maintain It with Zig

#227

Post by kobebrookskC3 »

azakai wrote: post #202
pjmlp wrote: post #33

Until Zig fixes the issues with use after free, it is hardly an improvement.

I'm not close to Zig development, but in addition to the GeneralPurposeAllocator work that a comment already links to, there is other ongoing stuff in that space, like an allocator in 64-bit that does not reuse pages (and instead keeps using new addresses in the "infinite" 64-bit space). There are also known techniques like Type-After-Type that can avoid use-after free in C and C++ [0]. And also advances in hardware…

what does zig offer over c/c++ with sanitizers?

Re: Maintain It with Zig

#228

Post by pphysch »

shp0ngle wrote: post #210

You replace the pipeline from GCC/LLVM to Zig. But the codebase is still in C and therefore has all the negative properties (memory unsafety, undefined behaviour), so what did you gain?

You can write new code in Zig and gradually refactor the problematic bits of C

Re: Maintain It with Zig

#229

Post by dnautics »

AndyKelley wrote: post #114
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…

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.

I believe the creator is on record on some youtube video or something stating that the intent is to replace C.

Re: Maintain It with Zig

#230

Post by travisgriggs »

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'd say both. C++ is so insanely complicated at times with the various things you mention. And every release it just seems to get worse, because while "nice to have features" are added, the old stuff doesn't go away, and the syntactic gymnastics they have to go through to get it all to coexist are the programming language to who's on first.

But the stack of stuff it takes you supposedly need to get stuff to compile is often insane. On one project I demonstrated that just find . | grep ".c$" | xargs gcc ... and a final link ran significantly faster than the mass of recursive nested/fake/etc makefiles that were supposed to speed up the compiles by doing dependency computations. I remember showing someone the basic "we turn the .c files into .o files, and then we make a second pass to link 'em" and they were like "really? that's all there is to compiling a C program?"

The real straw for me when I was contributing to the Cairo project was recognizing I was going to have understand this stuff more, and so I sat down and read the Make manual: 16 chapters. Now I need to understand Automake, read the manual: 26 chapters. And then Autoconf: 21 chapters. It was like it was just spinning bigger and bigger.

Post reply on HN