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

Zig 0.9.0

ziglang.org

Post reply on HN
Print view View original

91–100 of 250 posts

Re: Zig 0.9.0

#91

Post by jeremyjh »

Spex_guy wrote: post #72
refulgentis wrote: post #60

Earlier quoted context omitted.

I had no idea it wasn't in production yet: is there a story for why it consumes so much space on HN? Is the story strong enough already that is a clear alternative to Rust for post-C++ projects?

I can't comment for all the other people who are posting and voting for those posts, but at least for me Zig has quickly become my language of choice for side projects. Its cross compilation features alone are enough for it to replace the system C/C++ compiler toolchains I used to use, and the language itself is everything I'm looking for. Readable (IMO) syntax, proper namespaces, order independent declarations, powe…

It seems strange to compare to C++ when it has none of the features that most define C++ like RAII, OOP & templates. Its not really "simplified" - its something totally different.

Re: Zig 0.9.0

#92

Post by von_lohengramm »

turminal wrote: post #84
von_lohengramm wrote: post #78

Earlier quoted context omitted.

> representing strings as character slices Zig does not do this. It represents strings as byte slices. A UTF-8 character could be multiple codepoints with each codepoint being multiple bytes. A big thing about Zig is not hiding complexity. If UTF-8 were implemented at a language level (whatever that means), then "language level" string operations would be non-linear, which would be very non-Ziggy. I could see value i…

> character slices Sorry, byte slices is what I had in mind. I'm not talking about language level string operations as in concatenation with + or something like that at all, because that certainly wouldn't make sense in language like Zig. I'm not advocating for string functionality in the language, I'm advocating for a way to not allow byte slice functionality on a thing that is clearly not a byte slice.

> a way to not allow byte slice functionality on a thing that is clearly not a byte slice

This already exists in the form of structs or opaque types. Both of these approaches would end up being implemented in "userspace" anyways, whether that's standard library or third-party.

However, (UTF-8) strings are byte slices. You can do simple manipulation with them as byte slices safely and validly. Split on spaces? Sure. Tokenize? Sure. Find substring? Sure. You can't do things that depend on say UTF-8 graphemes, but you can safely do most things that depend on bytes. For most purposes, treating strings as byte slices is the safest and correct approach.

Re: Zig 0.9.0

#94

Post by _rend »

Spex_guy wrote: post #90
_rend wrote: post #65

Earlier quoted context omitted.

JSON[1], for instance, specifies: 1. "JSON syntax describes a sequence of Unicode code points. JSON also depends on Unicode in the hex numbers used in the \u escapement notation." 2. "A JSON text is a sequence of tokens formed from Unicode code points that conforms to the JSON value grammar." 3. "A string is a sequence of Unicode code points wrapped with quotation marks (U+0022). All code points may be placed within…

Parsing this out of utf-8 encoding requires no knowledge of unicode or even utf-8. All of the relevant characters (reverse solidus, quotation mark, and control characters) are single byte characters in the ascii subset. These characters cannot be found inside multi-byte characters in utf-8 due to the design of the encoding. Converting the unicode character escape codes to utf-8 would require knowledge of utf-8 encodi…

> Parsing this out of utf-8 encoding requires no knowledge of unicode or even utf-8.

If you have valid UTF-8 already, then yes, the task is a lot easier. But depending on the level at which you're parsing, this might not be the case — i.e., if you're writing a JSON parser from the ground up, you do need to know what UTF-8 and Unicode are, and will need to validate the input data.

> Converting the unicode character escape codes to utf-8 would require knowledge of utf-8 encoding

Agreed. Even if you're not working at the "array-of-bytes" level, you will need to be able to parse and translate "\u..."-style strings into the appropriate output character encoding.

> but this unescaping is not a feature that would be provided by the language regardless.

I'm not sure we're talking about this being handled at the language level. This translation is something that would likely be offered at the parser level (working with the features offered by the standard library), but the parser does need to know about it — and does need to be able to work with strings at a granular level to be able to parse it out. By definition, it cannot leave the input data as an undecoded bag of bytes.

Note, too, that the JSON spec does not specifically require UTF-8. UTF-16 is a completely valid encoding for JSON (though much less common than UTF-8), in which case none of these characters are an ASCII subset, and greater awareness is needed to be able to handle this.

Re: Zig 0.9.0

#95

Post by jhgb »

Heh. And just yesterday, I checked if there wasn't a new release to check out! Now there is, I guess.

Re: Zig 0.9.0

#96

Post by jhgb »

jeremyjh wrote: post #91
Spex_guy wrote: post #72

Earlier quoted context omitted.

I can't comment for all the other people who are posting and voting for those posts, but at least for me Zig has quickly become my language of choice for side projects. Its cross compilation features alone are enough for it to replace the system C/C++ compiler toolchains I used to use, and the language itself is everything I'm looking for. Readable (IMO) syntax, proper namespaces, order independent declarations, powe…

It seems strange to compare to C++ when it has none of the features that most define C++ like RAII, OOP & templates. Its not really "simplified" - its something totally different.

Presumably the idea is that lots of things that you basically have to use C++ for today because C alone is weak could be served by Zig instead, not that Zig and C++ are comparable languages.

Re: Zig 0.9.0

#97

Post by joe_guy »

AndyKelley wrote: post #51
tdeck wrote: post #41

Earlier quoted context omitted.

> the actual correct thing to do is intentionally avoid string handling, That sounds nice and all, but wr have 50+ years of protocols and formats and APIs built up around strings. Unless you're just writing code to run on a small microcontroller, you need to be able to parse and generate strings. So its going to be pretty frustrating not to have good support for them, or to have every codebase use its own libraries a…

Protocols and formats absolutely should not require decoding strings. I think you are mistaken. Can you name any well-established protocol or format that does not treat strings as opaque encoded bytes? Edit: so far these examples have been given: * HTTP: wrong. the spec does not tell you to decode any strings * CSV: wrong. the spec does not tell you to decode any strings, nor is it necessary to have any unicode aware…

Anything with case insensitivity, like domain names and email addresses, require knowledge of strings as strings.

Case sensitivity, ordering, and case changing rules, are reasons not only to have strings, but extensive culture support built into them. String types also let you compare utf16 bytes to utf8 bytes, for example.

To think that strings are opaque bytes is massively naive. It presumes one encoding exists, the input is always valid, in addition to what is said above.

An example of what you're setting yourself up for, is an exploit based around differences in handling invalid utf8.

Re: Zig 0.9.0

#98

Post by mamcx »

AndyKelley wrote: post #51
tdeck wrote: post #41

Earlier quoted context omitted.

> the actual correct thing to do is intentionally avoid string handling, That sounds nice and all, but wr have 50+ years of protocols and formats and APIs built up around strings. Unless you're just writing code to run on a small microcontroller, you need to be able to parse and generate strings. So its going to be pretty frustrating not to have good support for them, or to have every codebase use its own libraries a…

Protocols and formats absolutely should not require decoding strings. I think you are mistaken. Can you name any well-established protocol or format that does not treat strings as opaque encoded bytes? Edit: so far these examples have been given: * HTTP: wrong. the spec does not tell you to decode any strings * CSV: wrong. the spec does not tell you to decode any strings, nor is it necessary to have any unicode aware…

What???

> the spec does not tell you to decode any strings

Which "spec" is that? My user ask for csv, see csv, upload csv, do SEARCH on CSV, transform them, etc. Even do some scripting on them.

Nowhere, EVER "opaque encoded bytes" is on the spec of the users!

Re: Zig 0.9.0

#99

Post by skybrian »

db65edfc7996 wrote: post #14

Compiler error for unused variables :( [0]. Possibly my most hated feature of Go. [0] https://ziglang.org/download/0.9.0/release-notes.html#Compil... Edit: To be clear, love enforcing the idea for production code, but wish they had embraced a '-dev' mode or equivalent flag that made it easier to experiment.

It might be nicer if the formatter automatically commented out unused stuff, instead of removing it. (As long as it isn’t checked in.)

Re: Zig 0.9.0

#100

Post by lmm »

AndyKelley wrote: post #51
tdeck wrote: post #41

Earlier quoted context omitted.

> the actual correct thing to do is intentionally avoid string handling, That sounds nice and all, but wr have 50+ years of protocols and formats and APIs built up around strings. Unless you're just writing code to run on a small microcontroller, you need to be able to parse and generate strings. So its going to be pretty frustrating not to have good support for them, or to have every codebase use its own libraries a…

Protocols and formats absolutely should not require decoding strings. I think you are mistaken. Can you name any well-established protocol or format that does not treat strings as opaque encoded bytes? Edit: so far these examples have been given: * HTTP: wrong. the spec does not tell you to decode any strings * CSV: wrong. the spec does not tell you to decode any strings, nor is it necessary to have any unicode aware…

The HTTP specification does tell you to behave differently depending on the presence or absence of specific values for case-insensitive headers. That requires decoding the header name strings.
Post reply on HN