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

161–170 of 286 posts

Re: Maintain It with Zig

#161

Post by tialaramex »

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

> 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 that. Not for example a TCP/IP packet we haven't decoded yet, or the first 32 bytes of a JPEG image.

Programmers who aren't writing firmware for a vacuum cleaner or washing machine, probably want string literals like "this" in their code, and you'd naturally want those to have a type, for which a string type is the obvious fit. I believe in 2021 this type should obviously be UTF-8. "It's just some bytes" is far from useless, but it isn't much of a string type.

I was sceptical at first about Rust's choice to build in str (immutable UTF-8 string slices), because that seems like a relatively high level concept. But unlike std::string::String, str isn't that tricky after all. See, the only place such things would come from (not having std::string::String to make new ones) is the program source, and our compiler is necessarily already reading the program source, so it follows that the compiler must know how the source is encoded etc and thus it does actually know exactly what those literal strings are. If your literal wasn't Unicode, that wasn't a Rust program and it won't compile.

Re: Maintain It with Zig

#162

Post by maleldil »

woodrowbarlow wrote: post #86
oconnor663 wrote: post #13

Earlier quoted context omitted.

> Would it be fair to say that Zig is to C, what Rust is to C++? There's definitely something to that analogy, but I think it also misses a lot of really important details. For example, Zig has generics, which right off the bat makes it hard to say that it's "like C". Also Rust enforces memory safety, which isn't like C or C++.

i love that zig doesn't have a special syntax for generics, it just allows anything to be resolved at compile-time -- including types. which gives you generics 'for free'.

I've only cursory of Zig, so bear with me. Does this mean that Zig templates are like C++, that is, duck typing? Or is there a notion of constraining the type arguments?

Re: Maintain It with Zig

#163

Post by robinei »

maleldil wrote: post #162
woodrowbarlow wrote: post #86

Earlier quoted context omitted.

i love that zig doesn't have a special syntax for generics, it just allows anything to be resolved at compile-time -- including types. which gives you generics 'for free'.

I've only cursory of Zig, so bear with me. Does this mean that Zig templates are like C++, that is, duck typing? Or is there a notion of constraining the type arguments?

You can constrain type arguments with a compile-time `if` check, and generate a compile error on violation.

Re: Maintain It with Zig

#164

Post by kristoff_it »

maleldil wrote: post #162
woodrowbarlow wrote: post #86

Earlier quoted context omitted.

i love that zig doesn't have a special syntax for generics, it just allows anything to be resolved at compile-time -- including types. which gives you generics 'for free'.

I've only cursory of Zig, so bear with me. Does this mean that Zig templates are like C++, that is, duck typing? Or is there a notion of constraining the type arguments?

It's duck typed but it's not based on a funky and limited syntax, but rather types at comptime become normal arguments to functions that you can then inspect using normal Zig code.

I wrote a blog post about comptime if you want to learn more: https://kristoff.it/blog/what-is-zig-comptime/

Re: Maintain It with Zig

#165

Post by pjmlp »

jhgb wrote: post #160
pjmlp wrote: post #121

Earlier quoted context omitted.

All systems programming languages need the ability to do unsafe stuff, the big difference between C , C++, Objective-C and all the remaining system programming languages since JOVIAL and NEWP, is the explicit unsafe code blocks that make that visible. It is a big difference to have it on your face that something might need to be properly double checked and having each line of code as possible security exploit.

> the big difference between C , C++, Objective-C and all the remaining system programming languages since JOVIAL and NEWP, is the explicit unsafe code blocks that make that visible. Would you consider Oberon to belong in the former or latter category? On one hand, there's no explicit code blocks as such (syntactically). On the other hand, unsafe primitive operations are limited to the SYSTEM module, so functions cal…

If you read Oberon documentation, modules importing SYSTEM are tainted and considered unsafe.

Just like Modula-2 already does it.

Re: Maintain It with Zig

#166

Post by zamadatix »

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…

After self hosted compiler and package manager what are the big ticket items blocking 1.0 (other than fixes for a lot of the stuff that is broken)?

Re: Maintain It with Zig

#167

Post by ngrilly »

kristoff_it wrote: post #78
wyldfire wrote: post #56

Earlier quoted context omitted.

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.

Any plans to go one step further towards memory safety (and even better data race freedom)? Maybe using ARC when the overhead is acceptable (like Swift), it static analysis is not possible due to the type system not supporting the concepts of ownership, borrowing, lifetimes and so on?

Zig is super exciting, but without a GC or Rust type system, I’m worried about going “back” to a language where I have to think about memory leaks, use after free and so on.

Re: Maintain It with Zig

#168

Post by zamadatix »

matu3ba wrote: post #74
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.

yet.

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

Re: Maintain It with Zig

#169

Post by jhgb »

pjmlp wrote: post #165
jhgb wrote: post #160

Earlier quoted context omitted.

> the big difference between C , C++, Objective-C and all the remaining system programming languages since JOVIAL and NEWP, is the explicit unsafe code blocks that make that visible. Would you consider Oberon to belong in the former or latter category? On one hand, there's no explicit code blocks as such (syntactically). On the other hand, unsafe primitive operations are limited to the SYSTEM module, so functions cal…

If you read Oberon documentation, modules importing SYSTEM are tainted and considered unsafe. Just like Modula-2 already does it.

Well...that's what I meant. But which one is it, then?

Re: Maintain It with Zig

#170

Post by kllrnohj »

steveklabnik wrote: post #149
kllrnohj wrote: post #145

Earlier quoted context omitted.

> You're splitting hairs in a weird way. rustc cannot compile C code. zig can. But why do I care? I don't use rustc directly, the build system of choice does. And very few of the major build systems have an issue handling multiple languages. Cargo (rust's build system) supports build scripts and the community has already created C/C++ compiler hooks such as https://github.com/alexcrichton/cc-rs rustup and cargo also…

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, though, then I already obviously have a working C compiler & build toolchain in place since that's my start point.
Post reply on HN