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

51–60 of 250 posts

Re: Zig 0.9.0

#51

Post by AndyKelley »

tdeck wrote: post #41
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…

> 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 awareness in order to properly read and parse the data or deal with the delimiters.

Additional request: if you attempt to provide a counter-example, please also point to the place in the spec where it tells you to decode a string.

Re: Zig 0.9.0

#52

Post by adgjlsfhk1 »

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…

CSV?

Re: Zig 0.9.0

#53

Post by zamadatix »

Vendan wrote: post #37
lhorie wrote: post #33

Earlier quoted context omitted.

IIRC the self hosting compiler will allow both spaces and tabs, but they didn't feel it was worthwhile to backport this to the bootstrap compiler.

That's... slightly better, but afaict, "allows both spaces and tabs" seems to be "convert tabs to spaces" zig fmt accepts and converts tabs to spaces, \r\n to \n, as well as many other transformations of non-canonical to canonical style. Which is... still saying "spaces instead of tabs"

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

Re: Zig 0.9.0

#54

Post by ironmagma »

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…

HTTP for one. It does something like assume ASCII-like until it encounters odd looking bytes and/or a meta encoding tag.

Re: Zig 0.9.0

#55

Post by Spex_guy »

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?

We currently don't advise using the Zig language in production. The compiler has known bugs and even some miscompilations, and we sometimes make breaking changes to the std lib and even the language. However, `zig cc` and `zig c++` are currently considered stable enough for production use.

Re: Zig 0.9.0

#56

Post by ben0x539 »

nauticacom wrote: post #23
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'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?

    foo := someDefaultValue
    if someCondition {
        foo := someMoreSpecificValue
    }
Whoops, accidentally created a fresh, unused variable in the nested scope instead of changing the value of the original variable.

I do that frighteningly often.

Re: Zig 0.9.0

#57

Post by Spex_guy »

spekcular wrote: post #2

Exciting stuff. How far away is Zig 1.0, roughly?

Hard to say, 1.0 for us comes when everything is fully stable in both the language and standard library, and we believe that it can last at least 20 years without modification. My estimate is at least 5 years from now, possibly more.

Re: Zig 0.9.0

#58

Post by Vendan »

zamadatix wrote: post #53
Vendan wrote: post #37

Earlier quoted context omitted.

That's... slightly better, but afaict, "allows both spaces and tabs" seems to be "convert tabs to spaces" zig fmt accepts and converts tabs to spaces, \r\n to \n, as well as many other transformations of non-canonical to canonical style. Which is... still saying "spaces instead of tabs"

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

Re: Zig 0.9.0

#59

Post by [deleted] »

rmanolis wrote: post #50

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.

[deleted]

Re: Zig 0.9.0

#60

Post by refulgentis »

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?
Post reply on HN