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

71–80 of 250 posts

Re: Zig 0.9.0

#71

Post by turminal »

AndyKelley wrote: post #34
diegocg wrote: post #25

Earlier quoted context omitted.

They can put it on the standard library or the core language or wherever they want, but they absolutely need to provide good string handling. And regardless of where they put the code, this is something that needs to be done by the core team. Otherwise you will end with too many string libraries, all of them trying to solve a particular problem and doing bad at everything else, with bad documentation and different AP…

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…

By not treating strings specially, you get people screwing around with individual bytes inside codepoints which leads to at least as many bugs.

Re: Zig 0.9.0

#72

Post by Spex_guy »

refulgentis wrote: post #60
zenlot wrote: post #46

Is Zig going strong in community, or it's likely to remain as a niche / fans language? I like the idea, but anybody knows how community / companies react to it in a more wider "looking to use in production" environment?

I had no idea it wasn't in production yet: is there a story for why it consumes so much space on HN? Is the story strong enough already that is a clear alternative to Rust for post-C++ projects?

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, powerful metaprogramming, and an unmatched level of internal consistency all make it stand out to me. It feels like a massively simplified C++, a native language that improves significantly on C without introducing a massive set of unrelated features.

Re: Zig 0.9.0

#73

Post by lhorie »

Vendan wrote: post #58
zamadatix wrote: post #53

Earlier quoted context omitted.

"zig fmt" is the formatter not the aforementioned self hosted compiler.

It's a part of the ecosystem, and is, AFAICT, saying "tabs are not welcome here". Happy to be proven wrong.

See https://github.com/ziglang/zig/wiki/FAQ#why-does-zig-force-m...

In a nutshell, what you're currently using is the stage 1 compiler, aka the bootstrapping compiler to compile the official zig compiler going forward. zig fmt is opinionated because it was only meant to enforce formatting for the zig project. At that stage of the project's life, they felt it was more important to get shit done in a consistent manner w/ the people that are actually contributing than to cater to a hypothetical accessibility-impaired developer that isn't.

Zig is a very ambitious project. Prioritizing pragmatism over ideology is a fairly common theme with it currently. Another example: they repeatedly break stdlib APIs because catering to a larger audience is currently less important than getting other things nailed down first.

Re: Zig 0.9.0

#74

Post by kbd »

refulgentis wrote: post #60
zenlot wrote: post #46

Is Zig going strong in community, or it's likely to remain as a niche / fans language? I like the idea, but anybody knows how community / companies react to it in a more wider "looking to use in production" environment?

I had no idea it wasn't in production yet: is there a story for why it consumes so much space on HN? Is the story strong enough already that is a clear alternative to Rust for post-C++ projects?

Zig is full of good ideas and seems to be a truly serious attempt, by very talented developers, at improving the “C level” of the stack. I put my money where my mouth is and have a recurring donation to the Zig Software Foundation every month. Lots of people are excited about it. Dunno why you thought it was “ready for production” at a 0.x version though. They’re actively working on the self-hosted compiler and there are breaking changes every release still fyi.

Re: Zig 0.9.0

#75

Post by somethingor »

tdeck wrote: post #67
AndyKelley wrote: post #51

Earlier quoted context omitted.

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 problem is you've invented your own definition of the terms "string" and "string handling" which doesn't seem to agree with the generally accepted usage of these words. You're fixated on the word "decode" despite that not being the original focus of the discussion, not being present in my comment or the original comment you're replying to. I could create a standard library called "arrayofbytes" that lets you, for…

In Zig, those functions are in std.mem (distinct from std.ascii and std.unicode)

Re: Zig 0.9.0

#76

Post by 1_player »

macintux wrote: post #24
nauticacom wrote: post #23

Earlier quoted context omitted.

I've genuinely never understood this one, especially as a flat-out error instead of a warning. When could not using a variable ever be a bug?

When you mistakenly used the wrong variable name instead, I suppose.

It is only useful in the very niche case that the incorrect variable name you're using is defined (otherwise you'd get an unknown identifier error) and the correct name you should have been using isn't used anywhere.

Would catch this:

  var a, b
  c = a + a // whoops, should have been a + b, compiler complains about unused b
Doesn't catch this:

  var a, b
  foo(a, b)
  c = a + a // whoops, should have been a + b, but still compiles
All in all, unused variables being errors is an awful feature that isn't very helpful in practice, at the cost of making experimentation a pain in the arse.

There is nothing that kills my state of flow more than having to comment a piece of code that is unreferenced, because the compiler complains, while I'm trying to hack and explore some idea.

Re: Zig 0.9.0

#77

Post by Vendan »

lhorie wrote: post #73
Vendan wrote: post #58

Earlier quoted context omitted.

It's a part of the ecosystem, and is, AFAICT, saying "tabs are not welcome here". Happy to be proven wrong.

See https://github.com/ziglang/zig/wiki/FAQ#why-does-zig-force-m... In a nutshell, what you're currently using is the stage 1 compiler, aka the bootstrapping compiler to compile the official zig compiler going forward. zig fmt is opinionated because it was only meant to enforce formatting for the zig project. At that stage of the project's life, they felt it was more important to get shit done in a consistent manner…

I stand (partially) corrected, though everything there does still seem to point towards "tabs tolerated, but the formatter will convert to spaces". I also find it highly amusing that `zig fmt` converts tabs to spaces, and yet they point at gofmt, which, as far as I'm concerned, is the gold standard of "tabs for indentation, spaces for alignment." It could be that that is where zig wants to land eventually, and if so, I'm going to be quite happy and excited.

Re: Zig 0.9.0

#78

Post by von_lohengramm »

turminal wrote: post #70
von_lohengramm wrote: post #61

Earlier quoted context omitted.

It's not that simple. Obviously, you'd choose UTF-8, but that exposes another issue: a codepoint is not a character. There's no simple & elegant solution to this at the language level.

> a codepoint is not a character Precisely. That's why I think representing strings as character slices and letting third party libraries handle them is not a good solution. Deciding what features to put in the language vs. the stdlib vs. third party libraries is one of the hardest parts of language design. Personally I believe strings are important and frequent enough they deserve special treatment at the language l…

> representing strings as character slices

Zig does not do this. It represents strings as byte slices. A UTF-8 character could be multiple codepoints with each codepoint being multiple bytes.

A big thing about Zig is not hiding complexity. If UTF-8 were implemented at a language level (whatever that means), then "language level" string operations would be non-linear, which would be very non-Ziggy. I could see value in a standard library UTF-8 implementation, but a LOT of forethought would need to be put into it. I think keeping UTF-8 string manipulation at the third-party library level is a good choice for now. Maybe once the language is finalized, the ecosystem is more developed, and lessons have been learned from the third-party libraries, then the standard library can implement this.

Re: Zig 0.9.0

#79

Post by formerly_proven »

flohofwoe wrote: post #12
vladharbuz wrote: post #3

I don't know if string handling has been improved, but it's one of the few things stopping me from using Zig. I look forward to 1.0, which will hopefully have proper strings. [0] [0]: https://github.com/ziglang/zig/issues/234

IMHO Zig's builtin string handling (or rather, lack of) is exactly right for a systems programming language. Zig avoids the biggest problem of C strings and treats strings as ptr/length slices, not as zero-terminated. UTF-8 for string literals is also fine. That's all that's needed (and should be implemented) on the language level, everything else should go into the standard library, and additional specialized string…

u8 slices strike me as exactly the correct thing on the language level as well. In particular, it allows very straightforward zero-copy parsing/tokenization of strings. Most parsing of strings doesn't really need to know about UTF-8 and works correctly in the presence of non-ASCII codepoints.

String literally are not really UTF-8. Rather, zig source files are UTF-8 (by definition), and string literals are u8 literals; putting some UTF-8 between quotes just puts the literal UTF-8 encoded text into the literal because those are the bytes that are in the source file. In particular, string literals can contain arbitrary binary data and null bytes by way of \x00 escapes.

For Unicode handling there's some basic stuff in std.unicode (conversion between different UTF encodings, checking validity, decoding to codepoints etc.). This is used e.g. on Windows for checking filesystem paths. I don't general libraries of encodings is really that important today, iso-8859 and shift JIS might be useful sometimes, but everything else probably doesn't need to bloat up a standard library (iirc Python's codecs package, which contains dozens upon dozens of encodings, is like a third of the standard library by size).

Re: Zig 0.9.0

#80

Post by wyldfire »

AndyKelley wrote: post #34
diegocg wrote: post #25

Earlier quoted context omitted.

They can put it on the standard library or the core language or wherever they want, but they absolutely need to provide good string handling. And regardless of where they put the code, this is something that needs to be done by the core team. Otherwise you will end with too many string libraries, all of them trying to solve a particular problem and doing bad at everything else, with bad documentation and different AP…

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 didn't permit me to index the underlyinc characters or the bytes. Keep 'em opaque, sure. But I think it would be a mistake for a language not to have an idiom with a favorite library to perform these operations on encoded text. If resolving library dependencies is easy enough, then it doesn't need to be "standard" but it should be "the defacto standard." And if it turns out the defacto standard stagnates and doesn't keep up with the needs of developers, a new one can come take its place.

Post reply on HN