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

191–200 of 250 posts

Re: Zig 0.9.0

#191

Post by kaba0 »

xedrac wrote: post #101
jhgb wrote: post #96

Earlier quoted context omitted.

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.

I really like Zig, but the lack of RAII means we're back to malloc/free style programming, and I would never opt into that unless Rust could not be used (e.g. binary size too large). Having said that, it's way better than C and I hope it does well.

Not really back to that. Zig just chooses a different way to deal with memory, namely different compilation modes and faster write-compile-test cycles.

It’s a different tradeoff which may be worth it for some use-cases. But it’s definitely not obvious whether it is worse, as the alternative comes with a huge complexity on the language side.

Re: Zig 0.9.0

#192

Post by Firadeoclus »

lmm wrote: post #102
von_lohengramm wrote: post #92

Earlier quoted context omitted.

> 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. T…

Doing find substring by find byte subsequence won't behave correctly in many cases, where semantically equivalent strings have multiple different bytesequence representation. Treating strings as byte slices exposes a lot of footguns; it shouldn't be easy just as e.g. treating floating-point numbers as byte sequences shouldn't be easy.

I'm curious, what would be a good reason why treating floating point numbers as byte sequences should be any harder than what is required to make it obvious (provided their binary format is well defined)?

Re: Zig 0.9.0

#193

Post by jhgb »

ncmncm wrote: post #132
jhgb wrote: post #115

Earlier quoted context omitted.

I imagine that Zig has a lot more focus on "I can't use X in my environment" types of situation. It seems that for many such situations it might be a better fit than Rust.

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.

Re: Zig 0.9.0

#194

Post by kzemek »

bvrmn wrote: post #171
coldtea wrote: post #158

Earlier quoted context omitted.

It seems like every language must have some dumb decisions made because the authors don't care/think they know better/are stubborn/etc or because it painted itself into a hole from the start, without which it would be close to perfect for its use cases. Python has the GIL. Go itself has a few such cases (usually revolving around "NIH" and misguided simplicity). Zig has the prejudice about proper string handling.

> Python has the GIL. You are welcome to show fast single-core python interpreter without GIL. Coreteam will gladly accept your patches.

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.

Re: Zig 0.9.0

#195

Post by motiejus »

_vvhw wrote: post #170
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...

Zig's C interop is pretty good though, and there must be some decent native Unicode library out there somewhere right? ;) I've worked on a full-duplex file synchronization system that had to support cross-platform operating systems and file systems, across a variety of Unicode normalization schemes (and versions [1], which is why I introduced the question), and I'm personally satisfied that baking this into the langu…

Would Bellard's libunicode[1] work?

[1]: https://github.com/bellard/quickjs/blob/master/libunicode.h

Re: Zig 0.9.0

#196

Post by anonymoushn »

svnpenn wrote: post #135
AndyKelley wrote: post #34

Earlier quoted context omitted.

A lot of people reach for string handling when the actual correct thing to do is intentionally avoid string handling, and only handle strings as opaque encoded UTF-8 bytes, that cannot be reasoned about in terms of human language. I would even argue that having string handling in a standard library (or language) has the potential to cause a net increase in bugs, because of people thinking they are handling strings wh…

> 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.

Re: Zig 0.9.0

#197

Post by feffe »

svnpenn wrote: post #135
AndyKelley wrote: post #34

Earlier quoted context omitted.

A lot of people reach for string handling when the actual correct thing to do is intentionally avoid string handling, and only handle strings as opaque encoded UTF-8 bytes, that cannot be reasoned about in terms of human language. I would even argue that having string handling in a standard library (or language) has the potential to cause a net increase in bugs, because of people thinking they are handling strings wh…

> 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.

Maybe Andrew is referring to this? I'm just guessing but that is the only thing I can think of which could be considered broken. Go mostly just treat strings as bag of bytes and you have to use one of the unicode packages to actually do any significant work with them.

https://play.golang.com/p/Dla3sXciYXC

I also think string handling in Go is pretty sane. But range vs indexing on strings is something you need to be aware of.

Re: Zig 0.9.0

#198

Post by bvrmn »

kzemek wrote: post #194
bvrmn wrote: post #171

Earlier quoted context omitted.

> Python has the GIL. You are welcome to show fast single-core python interpreter without GIL. Coreteam will gladly accept your patches.

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 example numpy.

What else?

Re: Zig 0.9.0

#200

Post by kaba0 »

nicoburns wrote: post #38
AndyKelley wrote: post #26

Earlier quoted context omitted.

Please note there is an accepted proposal[1] to add an unused keyword, making it possible to detect conflicts between things being marked unused and actually being used, and improving tooling integration. [1]: https://github.com/ziglang/zig/issues/10245

I think there should definitely be a global option to disable this during development. This makes temporarily trying something out (e.g commenting out some code to run only part of it) a massive pain, as you have to go up and edit the variable definition as well as the code using it).

Fully agree. I meet with it mostly in typescript’s linter, but recursively having to comment out things is just simply terrible. Of course it is great for prod, but for debug it is very questionable.
Post reply on HN