Zig 0.9.0 • Hacker News Board

Re: Zig 0.9.0

#171

Post by bvrmn » Tue, Dec 21, 2021, 8:54 AM UTC

coldtea wrote: post #158

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.

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.

Re: Zig 0.9.0

#172

Post by fastball » Tue, Dec 21, 2021, 8:55 AM UTC

bvrmn wrote: post #168

fastball wrote: post #147

Earlier quoted context omitted.

Huh, which version is that? Python 3.9 on my system: >>> "ñ"[0] 'ñ' >>> "ñ"[1] IndexError: string index out of range Which is what I would expect.

Python 3.9.9 (main, Nov 20 2021, 21:30:06) [GCC 11.1.0] on linux

EDIT: I can't seem to replicate this on my Ubuntu system. Strange.

Ah, interesting, I suppose then there is a difference in the way Linux handles strings? Didn't realize that, very unfortunate if true. I am running MacOS.

Re: Zig 0.9.0

#173

Post by anonymoushn » Tue, Dec 21, 2021, 8:59 AM UTC

coldtea wrote: post #165

anonymoushn wrote: post #151

Earlier quoted context omitted.

It seems way nicer to have a language that treats strings as byte arrays and use libraries to handle encodings than to have a language that treats strings as UCS-2 and use libraries to handle UTF-8 strings that live inside of UCS-2 strings.

I don't know, it has been a pain to work with strings in any language that does the above, and has seldom (if ever) been a problem with Java, Go, Swift, or even modern Python 3, and so on...

I'm not sure how to explain the difference in experience here. Python 3's built-in string encoding support has been a source of endless pain to me, and Lua's belief that strings are byte arrays has been much easier to deal with.

Re: Zig 0.9.0

#174

Post by _vvhw » Tue, Dec 21, 2021, 9:09 AM UTC

coldtea wrote: post #162

dnautics wrote: post #130

Earlier quoted context omitted.

I believe there is someone using it in production for a field deployed embedded system that is tied to revenue. IIRC Forwards compatibility is not an issue because those deployments are one-and-done.

> I believe there is someone using it in production for a field deployed embedded system that is tied to revenue. Sure. But people do all kinds of not advisable things, even if revenue is at risk. In fact, it might even be fine, for their use cases. The build it once, it has the libs they want covered, it works like the want, that's it. That can work with any early release language/lib. The problem is with someone ca…

Zig's a little different here.

Zig's C interop means it can leverage some of the most battle-tested libraries out there, with no shortage of libraries given C's massive ecosystem. And with Zig, it's not like you have to rewrite your whole system in a new language, you can incrementally rewrite the parts that make sense, test, and repeat.

Zig's tooling around compilation is also arguably ahead of most languages, and Zig's progress here is flowing back and adding value to many communities. For example, this 0.9.0 release can now build native Node addons without requiring node-gyp.

Re: Zig 0.9.0

#175

Post by yellowapple » Tue, Dec 21, 2021, 9:14 AM UTC

AndyKelley wrote: post #43

lhorie wrote: post #31

Would be nice to get more clarity on what exactly is the scope of the self hosted compiler. From previous discussions, I was under the impression that people would use the self hosted compiler for development, but still be expected to use the bootstrap compiler for production (because LLVM optimizations are in the latter but not the former). This page makes it sound like the self-hosted compiler will be the compiler,…

The self-hosted compiler is the compiler. It has an LLVM backend. The bootstrap compiler will be used only to bootstrap the self-hosted compiler. The self-hosted LLVM backend is not done. Zig 0.9.0 is the self-hosted compiler, you are using the self-hosted compiler when you use Zig today. But it relies on the bootstrap compiler for the LLVM backend. I know it is weird to say "self-hosted LLVM backend" but I don't kno…

Does this mean that y'all are open to the self-hosted compiler supporting CPU architectures unlikely to ever have LLVM support? I know that's one of the blockers for the oft-asked "Will OpenBSD consider adopting Rust/Zig/Go/whatever?", as one example of a project that targets platforms which LLVM does not.

My guess from the preliminary Plan 9 target work mentioned in the release notes is that something like a SuperH backend (for example) would indeed be in scope (provided someone's willing to contribute one, of course), but a confirmation would be neat. I suppose the C backend would do the job in these cases, too, but I'm sure it'd be nice to not have to include GCC (or some other C compiler besides zig cc) in the mix (especially for projects like OpenBSD that try to minimize copyleft code).

Speaking of: how is zig cc anticipated to work with a self-hosted Zig? Will there be a dependency on clang (as suggested by the punt_to_clang(...) call in the current main.zig)? Will it be possible to swap that out with something else that could turn C into ZIR (or something else the self-hosted compiler could then punt to whatever backend)?

Relatedly, would zig cc support the planned C backend? If so, would the resulting C output be equivalent to the input (notwithstanding the current limitations re: macros, struct bitfields, etc.)?

Re: Zig 0.9.0

#176

Post by _vvhw » Tue, Dec 21, 2021, 9:25 AM UTC

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.

I love the idea about compiler checking for unused variables in production, and that it's strict and not a warning that can be ignored merrily merrily, gently down the stream! :)

We found a few cases in TigerBeetle where some nasty bugs would have been detected and prevented by this. Some of these were at the entry point to a function, where the function failed to check all the pre-conditions and was ignoring some of the API interface, and others were where we were calculating some of the derived buffers we would need, but then never use them, using the original buffer incorrectly instead.

Re: Zig 0.9.0

#177

Post by jstimpfle » Tue, Dec 21, 2021, 9:30 AM UTC

coldtea wrote: post #167

_vvhw wrote: post #156

Earlier quoted context omitted.

Which version of UTF8?

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

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 library is basically the UTF-8 encoded/decoder. A useful implementation of UTF-8 is about 100-200 lines, I could probably rewrite what I use in an hour or two without an internet connection. The rest of the work is integration stuff that doesn't make sense to put in a library IMO. The idea of a string library fits much better with garbage collected and scripting languages (which includes C++ with RAII mechanism, but consider that std::string and similar often cause bad performance).

Many programs, in particular non-graphical programs don't need any UTF-8 code at all - UTF-8 handling is basically memcpy().

Re: Zig 0.9.0

#178

Post by animesh » Tue, Dec 21, 2021, 9:31 AM UTC

von_lohengramm wrote: post #11

aix1 wrote: post #7

Is there a good "Why Zig" writeup motivating the language? I've been looking around their web site and the only thing I could find was pretty generic: Zig is a general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.

In addition to the other recommendations, the Zig Zen[0] and The Road to Zig 1.0[1] are pretty convincing. [0] https://ziglang.org/documentation/master/#Zen [1] https://www.youtube.com/watch?v=Gv2I7qTux7g

That Road to Zig talk is a must watch. I keep coming back to it. More than the language, I love how much conviction Andrew has in his vision for Zig.

Re: Zig 0.9.0

#179

Post by bvrmn » Tue, Dec 21, 2021, 9:32 AM UTC

fastball wrote: post #172

bvrmn wrote: post #168

Earlier quoted context omitted.

Python 3.9.9 (main, Nov 20 2021, 21:30:06) [GCC 11.1.0] on linux

EDIT: I can't seem to replicate this on my Ubuntu system. Strange. Ah, interesting, I suppose then there is a difference in the way Linux handles strings? Didn't realize that, very unfortunate if true. I am running MacOS.

Actually browser normalized string and it works for me also. Here is original byte sequence:

    >>> b'n\xcc\x83'.decode()
    'ñ'
    >>> b'n\xcc\x83'.decode()[0]
    'n'
    >>> b'n\xcc\x83'.decode()[1]
    '̃'

But I agree, it's rare case when you need to deal with non-normalized data.

Re: Zig 0.9.0

#180

Post by alophawen » Tue, Dec 21, 2021, 9:35 AM UTC

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 tar / star format requires decoding strings of octal numbers.

https://en.wikipedia.org/wiki/Tar_(computing)#Header