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

41–50 of 250 posts

Re: Zig 0.9.0

#41

Post by tdeck »

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…

> 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 and idioms for working with strings.

Re: Zig 0.9.0

#42

Post by nicoburns »

dilap wrote: post #28
db65edfc7996 wrote: post #21

Earlier quoted context omitted.

That is still more movement for when I am hacking out a feature. When I am trying to figure out an idea, I am liberally creating new variables and adding imports without care. In other languages, I can freely comment in/out large swaths of code as I understand the problem. Not a deal-breaker (honestly, I write Python most days), but a huge annoyance.

Yeah, it's a fair point. Per the zig writeup, the plan / hope for this use case is an editor command that will quickly add in all the "_ = unused" statements, which should take it down to very-small annoyance. (From my use in Go, I'm definitely overall a fan of the feature. Tho of course how much personal value vs annoyance you get out of it is going to depend on your own code style and behaviors.)

In JavaScript we have a lint for this, so I can run code with unused variables, but I can’t commit code with unused variables (and CI will enforce that for everyone on the team if they bypass the precommit hook). That seems best of both worlds to me.

Re: Zig 0.9.0

#43

Post by AndyKelley »

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 know what else to call it. It's the .zig code that lowers Zig IR to LLVM IR.

It's possible to build Zig without an LLVM dependency by not passing `-Denable-llvm` to `zig build`. In this case the LLVM backend is not available (neither the self-hosted one or the bootstrap one).

Re: Zig 0.9.0

#44

Post by [deleted] »

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,…

[deleted]

Re: Zig 0.9.0

#45

Post by [deleted] »

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.

[deleted]

Re: Zig 0.9.0

#46

Post by zenlot »

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?

Re: Zig 0.9.0

#47

Post by dnautics »

AndyKelley wrote: post #26
flohofwoe wrote: post #16

Earlier quoted context omitted.

One problem I see with this decision is that code will now be littered with: _ = bla; _ = blub; ...which have been forgotten during development. So the next thing that's needed is an error if 'bla' or 'blub' are actually used elsewhere ;)

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 like this a lot. Though, many pls offer making the identifier start with _ to make it unused well.

Re: Zig 0.9.0

#48

Post by _rend »

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…

IMO, Swift is a language that gets it right, by exposing an interface which feels to very closely match how "humans" understand text — the default String interface is a collection of grapheme clusters, while `.utf8View`, `.utf16View`, and `.unicodeScalarView` are optional views which expose data explicitly encoded as needed.

Swift is pretty pedantically strict about Unicode correctness, and avoids some pitfalls which lead to incorrect handling (e.g., integer-based indexing). This means that the traditional way many developers might be used to interacting with strings is cumbersome and annoying — but once you get past the initial hurdle*, most operations are actually (1) really easy, especially when expressed in terms of generic Sequence/Collection operations, and (2) much more difficult to get wrong.

*I think the largest part of that hurdle is overcoming what you may have gotten used to from other languages, i.e., treating strings as an array of "characters", for some language/library definition of "character" (whether bytes, code points, etc.). It's relatively rare that you actually care about indexing into an arbitrary spot in a string: instead, combinations of slicing operations (including `prefix(_:)`, `dropFirst(_:)`, `take(while:)`, etc.) and generic Collection operations will get you what you want. Things like `.reversed()`, `.sorted(), and `.shuffled()` all work trivially correctly too (since you're not operating on a bag of bytes), and it's exceedingly rare that user input will confound the operations you might need to perform. (Exception: operations like case folding and collection, which are locale-specific, need special handling through a framework like Foundation.)

To be clear: not everything is sunshine and roses, but an amazing amount of functionality "falls out" of basic protocol conformances on String, and its exposure as a Collection of grapheme clusters.

Given a specific string manipulation task, I'd be happy to provide an example of what it might look like in Swift!

Re: Zig 0.9.0

#50

Post by rmanolis »

I love Zig. But unfortunately there are no use cases for web developers yet that Go and JavaScript does not do already … unless the webassembly replace JS for more cool and futuristic UI.
Post reply on HN