Live data from Hacker News

Maintain It with Zig

kristoff.it

171–180 of 286 posts

Re: Maintain It with Zig

#171
post #74

Earlier quoted context omitted.

yet.

One could say the same thing about Rust, and at least that language has hit 1.0.

It's not just a random remark, the self-hosted implementation of the compiler which is being worked on as we speak (type?) has multiple backends, one being the C backend which will be used to simplify the bootstrap process of Zig.

Re: Maintain It with Zig

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

Will the compiler have something like go's ability to vendor code locally? I've worked on some science projects and this has been a hard requirement on some systems for tape archive storage.

Re: Maintain It with Zig

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

How can I help?

Re: Maintain It with Zig

#174

Earlier quoted context omitted.

You are talking about the simplicity of a line of code. The topic being discussed, though, was the simplicity of the language itself .

The simplicity of the language is directly correlated to the simplicity of that line. The fact that the language makes relationships between inputs and outputs explicit is a feature of the language, because of its borrow checker, at the expense of being syntactically verbose compared to C.

Not at all. A single line will use a tiny subset of language features. It will show you nothing about the overall complexity of the language, just about those things it happens to use.

Re: Maintain It with Zig

#175

Earlier quoted context omitted.

You care because you need to have a c compiler installed, as well as the libc stuff… It is a giant pain to do so in some circumstances. One less dependency is a good thing. I quoted from cc’s readme above.

100% of platforms that Zig & Rust run on already have a C compiler installed, though. A c compiler being present is the baseline assumption. If Zig existed in places C doesn't and I wanted to write C for that platform then having Zig CC would be an advantage. But such a situation doesn't currently exist and seems unlikely to ever exist? Especially in the context of a library/module porting to Zig or Rust piecemeal, t…

you may have one. Not everyone does, or should. It is a massive pain. See how many folks complain about various native wrapper packages in Python and Ruby for example. Someone even made a Python wheel wrapper for zig to make it easier to compile C extensions.

Re: Maintain It with Zig

#176
post #99

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…

Sure, you're not wrong. For my purposes that'd work, but I'm of the opinion that delegating that to an optional library will make a lot of developers lazy and not even bother thinking about Unicode/i18n/l10n issues at all. I've seen so much code, in a multitude of languages that is oblivious to it, but even if it's reified in a type or even having some form of language support, I guess you can argue that people can s…

That was basically the state of affairs with strings in Python 2, and although the transition was awful, I'm really, really appreciative of Python 3 now having clearly-separated str and bytes types.

Re: Maintain It with Zig

#177

Earlier quoted context omitted.

Not sure if this transpired in the writing, but my interpretation of RIIR, partially informed by the chat with JT [0], is that this is a sentiment that I guess is there in some people, but that it was never something officially sanctioned. [0] https://www.youtube.com/watch?v=X7ny7Qrsbd8&t=5391s

It is a weird self-fulfilling thing. People talk about it like it's a thing, so it's a thing, even if there's very little actual evidence of anyone sincerely holding this belief. People repeat that there's this plague of folks requesting that projects be re-written, and while it is literally true that I have seen two or three instances of this (you link to one of them, and notably it is not anyone harassing maintaine…

As a programmer I think it's notable that when I learned Rust I wanted to rewrite stuff in Rust.

I rewrote 'leakdice' as part of learning Rust, so arguably that doesn't count (though I had never rewritten a program to learn a previous language), and 'misfortunate' wouldn't make sense in unsafe languages so that doesn't count either, but I then also immediately began rewriting 4store in Rust.

I had never been compelled to rewrite stuff in other languages I learned. I am a compulsive programmer, so I did write stuff in languages I learned, (the other day I re-discovered, via an enquiry to a very old email address, that I used to know Scheme, as evidenced by the fact I wrote some Scheme that they were asking about from last century) but I didn't rewrite anything until I learned Rust.

C. Go. Python. Java. PHP. Bash. Perl. C#. Early C++. I'm sure there are many more. But always new things, either because the language afforded something I hadn't considered before or more often I wanted something and I chose a languages I knew would be able to achieve it. That's why I wrote some PHP less than a year ago, I'm not proud of that, but PHP got the job done so that's what I did. I can report that modern PHP is merely a bad idea, like Javascript, which I probably forgot to list above.

Anyway with Rust I not only wanted to write new low-level code in Rust, I looked again at C programs I use and thought, "I should rewrite that in Rust". It felt like a good idea, and I expect to follow through on it at least somewhat, let's see how long 4store takes.

Re: Maintain It with Zig

#178
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,…

> Then again, I'm not sure exactly what a type would be for Unicode.

I have this internally in my lang AST Rust

    Utf8
I think that is the type:

    struct City {
        name:Utf8
    }
For a scripting lang like mine I surface it as `Str` but in a system language I think is better to say `Utf8`

Re: Maintain It with Zig

#179

Agreed for sure that working with C and C++ is the only way forward for systems languages. Rust's expression of this is the zero-cost C FFI, using native platform tooling, and stuff like that. Rust was never about re-writing the world, after all, its reason for existing was to eventually improve Firefox. The very first presentation about Rust ( http://venge.net/graydon/talks/intro-talk-2.pdf ) says "We are not “rewri…

Not sure if this transpired in the writing, but my interpretation of RIIR, partially informed by the chat with JT [0], is that this is a sentiment that I guess is there in some people, but that it was never something officially sanctioned. [0] https://www.youtube.com/watch?v=X7ny7Qrsbd8&t=5391s

I see it more like an aspirational goal. But one where everyone understand that is at most about start new projects that wholesome replace them (or "replace" is for create alternatives, not for truly rewrite the old ones).

And I'm one that will be super-happy if all C/C++ code in the world dissapear now and be replace by Pascal/Rust/Zig/D/anything else that is better.

MOST of my troubles are because C/C++. And the worst ones. Even if I 'm in a environment (business apps, ERps) where in theory system lang concerns are a distant worry.

Re: Maintain It with Zig

#180
post #140

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…

> ...I can assure you there is already a very large fire under my ass to get this shipped ... [followed by a short, easy-to-follow explanation as to why it's taking so long] I'm going to check out Zig because of your response. I love coming across comments like this one on HN.

Zig has been on my radar precisely because of Andrew Kelley's vision.

I wrote about cross-compiling to a raspberry-pi and writing a barebones driver for an OLED display[^1]

That was a lot of fun despite the fact the code was incredibly basic. The interop with C was effortless.

[^1] https://www.kamelasa.dev/posts/gettin-ziggy-with-it-pi-zero....

Post reply on HN