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

241–250 of 250 posts

Re: Zig 0.9.0

#241

Post by SuchAnonMuchWow »

jstimpfle wrote: post #210
SuchAnonMuchWow wrote: post #185

Earlier quoted context omitted.

I assume you never had to deal with unicode normalization ? When you send your unicode string to an external system (for example a storage server with a database) and latter retrieve the string, only to find out that it has been normalized differently so it no longer match byte-for-byte what is stored in your program, and all of a sudden strcmp no longer works. Or all kind of weirdness like that because every system…

> I assume you never had to deal with unicode normalization ? I hadn't, and as long as I control the data I'm displaying, I won't have to. > Or all kind of weirdness like that because every system outside of your program will handle unicode differently Blame those systems, not me. What you suggest is surrendering to the state of affairs, which we collectively self-inflicted. When I have to deal with normalization iss…

> Blame those systems, not me.

Yes I completely agree with you, and if you don't need it, any unicode handling library is overkill and add more headaches than simply handling utf-8 string as byte arrays.

I just wanted to insist on the fact that some people will have to deals with theses kind of issues. And these issues are self inflicted, but it gets worse every time someone try to reinvent the wheel or rely on byte array when they shouldn't.

Having a standard library in the language make the issue less worse: the core of the language still handle only byte arrays, and for the cases where it's not enough you still have only one library so you don't add your own subtly different mishandling of the standard by implementing your own.

So memcpy is fine, but that's about it: for example, please don't use strcmp when you need to sort data alphabetically and please don't try to reimplement the standard algorithms designed for that, otherwise you will be part of the problem.

Re: Zig 0.9.0

#242

Post by anonymoushn »

svnpenn wrote: post #240
anonymoushn wrote: post #234

Earlier quoted context omitted.

Please let me know the ways this does not do the right thing. Thanks. https://www.godbolt.org/z/Y3z8rhzrq

Im not sure how a 50 line program is better than a 5 line program, but OK. Also it seems you had to write functions to get the same result. My original comment, was that Andrew has a habit of shitting on other languages without proper references or examples. Nothing you can really say is going to change Andrews behavior, so maybe you should stop, unless you can justify Andrews comments.

Your original program which is claimed not-possible-to-port is 14 LOC. This comparable program is 18 LOC: https://www.godbolt.org/z/xf4Tdr1Ps

Most of the difference comes from the demand that we represent unicode codepoints as integers at some point in the program, which is a nonsensical thing to do, because unicode codepoints don't correspond to anything useful in the actual text being represented.

You seem to have a habit of making false claims about the standard libraries of languages you dislike, and when pressed on the matter ask other people to do your homework. I certainly should stop doing other people's homework.

Re: Zig 0.9.0

#243

Post by ShrigmaMale »

chaz6 wrote: post #208
coldtea wrote: post #167

Earlier quoted context omitted.

When adopting a new niche language, with hardly any following, and frequent changes, and not even an 1.0, like Zig, "which version of UTF8" (as if that's an issue) is the least of your worries... "Which third-party strings lib of several half-complete incompatible libs" will be a much realer concern...

How feasible would it be to defer string processing to the operating system so that the behavior of all software running on it is the same? Perhaps a new OS interface could be defined for this purpose using syscalls on Linux. At the very least, there should be one canonical set of algorithms per operating system, rather than everyone downstream reinventing the wheel. Please forgive me if this sounds absurd, I am not…

Because string processing is not slow enough? Making string operations eat the performance impact of that context switch in and out of kernel is not a good idea. Library is better. This is not string but I'm thinking to some language like Rust where the "time" crate is not language feature but just about standard and all the other library use it. This is possible if a library like it is good quality and exist early in the language.

Re: Zig 0.9.0

#244

Post by svnpenn »

anonymoushn wrote: post #242
svnpenn wrote: post #240

Earlier quoted context omitted.

Im not sure how a 50 line program is better than a 5 line program, but OK. Also it seems you had to write functions to get the same result. My original comment, was that Andrew has a habit of shitting on other languages without proper references or examples. Nothing you can really say is going to change Andrews behavior, so maybe you should stop, unless you can justify Andrews comments.

Your original program which is claimed not-possible-to-port is 14 LOC. This comparable program is 18 LOC: https://www.godbolt.org/z/xf4Tdr1Ps Most of the difference comes from the demand that we represent unicode codepoints as integers at some point in the program, which is a nonsensical thing to do, because unicode codepoints don't correspond to anything useful in the actual text being represented. You seem to have…

You seem to have a habit of getting off topic. This thread was never about Zig, it was about Andrew shitting on other languages without justification. I think you can agree that for the basic example I gave, the Go language is easier, more streamline, more comfortable to work with. It allows to get the task done quickly.

So for Andrew to shit on Go string handling with not a single example is rude, and frankly just wrong as I have demonstrated.

Re: Zig 0.9.0

#245

Post by anonymoushn »

SuchAnonMuchWow wrote: post #241
jstimpfle wrote: post #210

Earlier quoted context omitted.

> I assume you never had to deal with unicode normalization ? I hadn't, and as long as I control the data I'm displaying, I won't have to. > Or all kind of weirdness like that because every system outside of your program will handle unicode differently Blame those systems, not me. What you suggest is surrendering to the state of affairs, which we collectively self-inflicted. When I have to deal with normalization iss…

> Blame those systems, not me. Yes I completely agree with you, and if you don't need it, any unicode handling library is overkill and add more headaches than simply handling utf-8 string as byte arrays. I just wanted to insist on the fact that some people will have to deals with theses kind of issues. And these issues are self inflicted, but it gets worse every time someone try to reinvent the wheel or rely on byte…

Can you really fix anything by changing the native string type? You'll inevitably need to exchange bytes with different systems that demand different encodings and different normalization forms.

Re: Zig 0.9.0

#246

Post by ruined »

dnautics wrote: post #87
ruined wrote: post #40

Earlier quoted context omitted.

thread tl;dr: it doesn't look like there will be language support for things like codepoints or grapheme indexing or treatment of strings as anything but byte arrays, so ddevault is sad. there is intention from andrewrk and jecolon to provide such features in the standard library before 1.0 release. downside to library vs lang support that is you can expect a good chunk of programmers to ignore the less-ergonomic lib…

Does this boil to the semantic question of if the stdlib is part of the language?

i don't think so. the answer is presumed no, because everyone in the relevant thread including language authors and stdlib authors (with plenty of overlap) agree that it is not, and agree there are functional distinctions about what is possible on either side of that dividing line (mostly due to zig not supporting custom operators).

Re: Zig 0.9.0

#247

Post by tdeck »

rep_lodsb wrote: post #124
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…

"Stringly typed" programming gave us SQL injections, shellshock, and the log4j debacle. Not to mention probably 99% of processor cycles being wasted on parsing and re-encoding again and again from/to text-based formats that are in no way actually human-readable without the use of specialized tools. When have you last browsed the web using telnet? It's all plain text, so you should be able to, right? Press Ctrl-U righ…

That's right, my suggestion was clearly that we should replace all datatyoes with strings. This comment brought to you by TCL/Tk.

Re: Zig 0.9.0

#248

Post by _vvhw »

roca wrote: post #225
_vvhw wrote: post #156

Earlier quoted context omitted.

Which version of UTF8?

Regular UTF8, not WTF-8 or any of those other variants (which are for encoding data that is not necessarily Unicode).

Also excluding Unicode normalization? Or should that also be baked in?

Re: Zig 0.9.0

#249

Post by roca »

_vvhw wrote: post #248
roca wrote: post #225

Earlier quoted context omitted.

Regular UTF8, not WTF-8 or any of those other variants (which are for encoding data that is not necessarily Unicode).

Also excluding Unicode normalization? Or should that also be baked in?

No need to drag Unicode normalization into it; don't require strings to be normalized. Normalization is only relevant in very specific contexts and you don't want to pay for it elsewhere.

Re: Zig 0.9.0

#250

Post by _vvhw »

roca wrote: post #249
_vvhw wrote: post #248

Earlier quoted context omitted.

Also excluding Unicode normalization? Or should that also be baked in?

No need to drag Unicode normalization into it; don't require strings to be normalized. Normalization is only relevant in very specific contexts and you don't want to pay for it elsewhere.

Agreed, but I think that many people would consider Unicode normalization to be part of what they want from the std lib when they mean that UTF8 should be baked in... so that they can manipulate UTF8 as they want, including in various normal forms according to platform. It's hard to imagine people being satisfied without having access to Unicode normalization.

For example, consider JS' introduction of String.normalize(). This is a slippery slope. It had a huge impact on Node's build process and binary sizes because now all the tables had to be shipped. But it's still broken in JS, because no matter the Unicode normalization support provided, it will never match the exact tables used e.g. in Apple's HFS.

I feel that by the time it gets to String.normalize(), it's too far gone.

Post reply on HN