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

211–220 of 250 posts

Re: Zig 0.9.0

#211

Post by duped »

bvrmn wrote: post #198
kzemek wrote: post #194

Earlier quoted context omitted.

That's how I understand "painted itself into a hole from the start" from the GP - removing GIL at this point is very hard because virtually all of Python language and code has been created in a world with the GIL.

It's nice to have atomic guarantees of GILed implementation. For me current CPython semantic is a golden middle: you have pretty fast interpreter without race conditions (for huge part of user code). Due to GIL. I always like to ask for what kind of task one needs GILless python? CPU bound? If you are using native python code for CPU bound tasks you are already in a bad place. C extensions can release GIL. For exampl…

Anything with a hard or soft real-time constraint (audio, video, industrial automation, etc). You'd be shocked how many algorithmic prototypes are written in numpy then hand converted to C++ for realization.

Re: Zig 0.9.0

#212

Post by jstimpfle »

rightbyte wrote: post #188
jstimpfle wrote: post #177

Earlier quoted context omitted.

For systems programmers the answer to "which third-party strings lib" is probably "None, write your own that fits with the rest of the system". A ready-made lib will be a lot of work to fit in - consider choice of internal encoding, allocation, hashing, buffering, mutable operations, etc.... Assuming that you really want to use UTF-8 internally, which is probably a sensible choice, the reusable part of a string libra…

> Many programs, in particular non-graphical programs don't need any UTF-8 code at all - UTF-8 handling is basically memcpy(). argv to main is utf8 on my system.

On Unix/Linux, it is binary data without any restrictions except that each argument is zero-terminated (the typical argument is probably UTF-8 if you have set a UTF-8 locale). You'll see exactly the bytes that were put in as arguments to execlp() et. al. by the parent process.

On Windows, I believe it is Unicode converted to current codepage.

In any case I don't need to care about it since I can simply treat arguments as ASCII-extended opaque strings as described.

Re: Zig 0.9.0

#213

Post by svnpenn »

anonymoushn wrote: post #196
svnpenn wrote: post #135

Earlier quoted context omitted.

> Go's string handling is completely broken, for example. Classic Andy, shitting on other language with no references or examples. Go has some of the best string handling I've used. Seamless byte, rune, string conversion. Simple iterating and slicing. Plus helpful tools like strings.Builder and strconv.AppendInt. while Zig has nothing.

Zig certainly has things like strings.Builder and strconv.AppendInt, which aren't really related to language-level encoding-aware string support.

No it doesnt

Re: Zig 0.9.0

#214

Post by anonymoushn »

svnpenn wrote: post #213
anonymoushn wrote: post #196

Earlier quoted context omitted.

Zig certainly has things like strings.Builder and strconv.AppendInt, which aren't really related to language-level encoding-aware string support.

No it doesnt

strings are called []u8, strings.Builder is called std.ArrayList(u8), strconv.AppendInt is called std.fmt.formatInt. Are you trolling?

Re: Zig 0.9.0

#215

Post by svnpenn »

anonymoushn wrote: post #214
svnpenn wrote: post #213

Earlier quoted context omitted.

No it doesnt

strings are called []u8, strings.Builder is called std.ArrayList(u8), strconv.AppendInt is called std.fmt.formatInt. Are you trolling?

those dont do the same thing at all. strings.Builder can append a byte, rune, string, or byte slice:

https://godocs.io/strings#Builder

ArrayList cant do that. And strconv.AppendInt can convert a number to byte slice, then it appends to an existing byte slice. formatInt cant do that.

Re: Zig 0.9.0

#216

Post by Akira1364 »

rini17 wrote: post #187
Akira1364 wrote: post #161

Earlier quoted context omitted.

That's not really true at all. The single byte / single character comma separators are all that matters there. As long as you directly acknowledge / exactly replicate whatever blob of data happens to be in between each set of commas (even if it is nonsense garbage text) then you're correctly parsing the CSV.

Well let's try :grinningface:,:grinningface: which is d83d de00 002c d83d de00 in UTF16BE. If you extract first column by naively cutting the blob bytewise before the comma you end up with d83d de00 00 with extra NUL byte, which is a problem. With UTF16LE you'd prepend NUL which is even worse.

I think you somewhat misunderstood the manner I was suggesting you'd be approaching things there, though nothing you've said is incorrect.

Re: Zig 0.9.0

#217

Post by ncmncm »

jhgb wrote: post #193
ncmncm wrote: post #132

Earlier quoted context omitted.

There is, for practical purposes, noplace where one can't use C++, except where gatekeepers exercise power keep it out. Typically it would be only a day's work to get those building with a C++ compiler, whence they could begin modernizing. There are plenty of loadable modules in C++ for Linux and BSDs, and plugins for Postgres, in places where there is no expectation of upstreaming them. Zig is in a similar boat.

Perhaps you're correct about C++, but I was more referring to the Zig vs. Rust situation.

Since the Zig tool chain can also compile C, and Zig can use C headers without translation, the cases are more similar than one might otherwise suspect.

But of course it would be less of an upgrade, and the Zig parts would have to stay clearly segregated.

Re: Zig 0.9.0

#218

Post by lhorie »

rini17 wrote: post #187
Akira1364 wrote: post #161

Earlier quoted context omitted.

That's not really true at all. The single byte / single character comma separators are all that matters there. As long as you directly acknowledge / exactly replicate whatever blob of data happens to be in between each set of commas (even if it is nonsense garbage text) then you're correctly parsing the CSV.

Well let's try :grinningface:,:grinningface: which is d83d de00 002c d83d de00 in UTF16BE. If you extract first column by naively cutting the blob bytewise before the comma you end up with d83d de00 00 with extra NUL byte, which is a problem. With UTF16LE you'd prepend NUL which is even worse.

> cutting the blob bytewise

That doesn't make sense. If you're working with utf16, why would you slice bytewise? That's like slicing a zip file bytewise and wondering why it got corrupted.

The whole point of the argument for string support at a library level (rather than assuming some sort of equivalence between stringness and its underlying byte buffer at the language level) is that fixed width bytes fundamentally cannot model human language characters unambiguously because what a "character" is depends on the encoding/decoding contract of the program manipulating the byte buffer.

Assuming equivalence between 0x2C and `,` stems from the ancient history of ASCII, english and usage of C `char` as a mechanism to squeeze performance out of string operations by not properly supporting the full gamut of valid human language characters.

For a low level language that might be used to implement protocols, it totally makes sense that foo.len is length in bytes, because you're pretty much never going to want to know number of grapheme clusters at a protocol level. It doesn't make sense for a language level .len to be length in terms of codepoint count because that assumes encoding, which is fundamentally a business logic level concern.

Re: Zig 0.9.0

#219

Post by bvrmn »

duped wrote: post #211
bvrmn wrote: post #198

Earlier quoted context omitted.

It's nice to have atomic guarantees of GILed implementation. For me current CPython semantic is a golden middle: you have pretty fast interpreter without race conditions (for huge part of user code). Due to GIL. I always like to ask for what kind of task one needs GILless python? CPU bound? If you are using native python code for CPU bound tasks you are already in a bad place. C extensions can release GIL. For exampl…

Anything with a hard or soft real-time constraint (audio, video, industrial automation, etc). You'd be shocked how many algorithmic prototypes are written in numpy then hand converted to C++ for realization.

NumPy releases GIL. I love NumPy myself and created complex interactive realtime synths. It always was more convenient to slap Cython or C code to achieve desired 100x performance instead of getting potentially 10x (4x on my laptop) with multithreading.

Re: Zig 0.9.0

#220

Post by lhorie »

lmm wrote: post #157
coldtea wrote: post #153

Earlier quoted context omitted.

> That requires decoding the header name strings. Which should be ascii though no?

Maybe, but it's not "treating strings as opaque encoded bytes" which is what was asked.

ASCII is kinda special in that it's both a way of encoding strings and it has character-to-byte equivalence. You can specify an HTTP header as being any number of characters between `\n\r` characters or any number of bytes between `0x0A 0x0D`, and the parsing code is going to compile to pretty much the same thing regardless of whether you know what `0x0A` means or not.
Post reply on HN