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

181–190 of 250 posts

Re: Zig 0.9.0

#181

Post by AndyKelley »

yellowapple wrote: post #175
AndyKelley wrote: post #43

Earlier quoted context omitted.

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…

> Does this mean that y'all are open to the self-hosted compiler supporting CPU architectures unlikely to ever have LLVM support?

Yes! We won't block 1.0 on the quality of the less mainstream targets, but that's what the tier system is for - to ship a compiler that has varying levels of quality for various targets, while communicating clearly to users what kind of experience they can expect for each one.

SuperH patches are absolutely welcome.

> how is zig cc anticipated to work with a self-hosted Zig? Will there be a dependency on clang [...]?

The main distribution of Zig will be LLVM/Clang-enabled. However it is already possible to build a version of Zig that does not have these features enabled. In such case, compiling C, C++, and Objective-C code will result in an error.

However, the arocc project[1] is emerging, which, depending on a combination of how much funding ZSF gets and how much enthusiasm the unpaid contributors working in their spare time have, is looking like a promising C frontend that would be available even without LLVM/Clang. It is C only, however, with no intention of compiling C++ or Objective-C.

> would zig cc support the planned C backend?

As it is currently implemented: no. Zig invokes clang to turn C source code into object files.

However, with the arocc frontend mentioned above, this would be converting the C source code into ZIR (or perhaps AIR), which could then be lowered with any of the backends, including the (partially complete) C backend. In such case, the C output would look drastically different than the input. It would look more like a machine-generated IR than natural C code that a human would write.

[1]: https://github.com/Vexu/arocc

Re: Zig 0.9.0

#182

Post by jstimpfle »

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 don't get what's so hard about it. Most of my programs deal with UTF-8 simply by doing memcpy(). Parsing code just loops over the bytes and compares to ASCII characters (0-9, A-Z, a-z, \n, \r, \t ...). That's how UTF-8 was designed to be used.

Re: Zig 0.9.0

#183

Post by jstimpfle »

wyldfire wrote: post #80
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…

> 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 have lost count of how many times I have wanted to find substrings, transform cases, catenate strings, find patterns, substitute patterns. I'd be happy to do that in a language that did…

Maybe Java or Python are better choices for your problems. The point of a systems programming language is to allow implementation of specific solutions to specific problems. There are many, many ways to do the things you mention here (and that starts with the strings' storage format and allocation strategy) , so it's the right choice to not include _anything_ like that in the core language.

Re: Zig 0.9.0

#184

Post by fiedzia »

fastball wrote: post #147
bvrmn wrote: post #137

Earlier quoted context omitted.

>>> "ñ"[0] 'n' >>> "ñ"[1] '̃'

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.

this is normalization issue, not version issue

import unicodedata list(unicodedata.normalize('NFD', "ñ")) >> ['n', '̃']

list(unicodedata.normalize('NFC', "ñ")) >> ['ñ']

both are correct, the issue is that unicode allows accented letters to be written as _accented_letter_ or _letter_, _accent_. The idea of "character" in uncicode is not very useful, most of the time you will want graphemes, not codepoints. User-friendliness wise, this is what Python should use (another rant - strings should not have length method, they should have byte_length, codepoint_length and grapheme_length).

Re: Zig 0.9.0

#185

Post by SuchAnonMuchWow »

jstimpfle wrote: post #182
coldtea wrote: post #165

Earlier quoted context omitted.

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 don't get what's so hard about it. Most of my programs deal with UTF-8 simply by doing memcpy(). Parsing code just loops over the bytes and compares to ASCII characters (0-9, A-Z, a-z, \n, \r, \t ...). That's how UTF-8 was designed to be used.

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 outside of your program will handle unicode differently, and you will need to adapt to them, and having a string library to do most of the heavy-lifting will avoid the need for every user to rewrite a library from scratch.

Not to mention that for every developer which rewrite unicode handling functions, you will probably end up with a function with subtly different behaviors from others, which aggravate the problem for others when they will try to communicate with your system.

Re: Zig 0.9.0

#186

Post by logicchains »

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…

To clarify, is there any plan to develop a pure-Zig backend, so people who want to escape from LLVM can use that backend for compiling Zig code instead?

Re: Zig 0.9.0

#187

Post by rini17 »

Akira1364 wrote: post #161
chrismorgan wrote: post #114

Earlier quoted context omitted.

> * CSV: wrong. the spec does not tell you to decode any strings, nor is it necessary to have any unicode awareness in order to properly read and parse the data or deal with the delimiters. CSV is defined in terms of characters, not bytes, so CSV parsing does require you to be encoding-aware: if your CSV file is encoded as UTF-16, bytewise parsing will destroy the data.

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.

Re: Zig 0.9.0

#188

Post by rightbyte »

jstimpfle wrote: post #177
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...

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.

Re: Zig 0.9.0

#189

Post by AndyKelley »

logicchains wrote: post #186
AndyKelley wrote: post #43

Earlier quoted context omitted.

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…

To clarify, is there any plan to develop a pure-Zig backend, so people who want to escape from LLVM can use that backend for compiling Zig code instead?

Yes. If you look at the infographic here:

https://ziglang.org/download/0.9.0/release-notes.html#Self-H...

Notice the bubble that says "LLVM Codegen" (44% done). This is the LLVM backend. All the other bubbles do not depend on LLVM at all.

I suggest to check back in with the next release of Zig and see where we are at. I suspect we will have at least the x86 backend fully operational by then.

Re: Zig 0.9.0

#190

Post by kaba0 »

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.

Well, Zig’s compile time metaprogramming capabilities do rival that of C++’s in a much more simple way, imo.
Post reply on HN