Live data from Hacker News

Zig 0.9.0

ziglang.org

31–40 of 250 posts

Re: Zig 0.9.0

#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, but various parts of the compiler infrastructure will be either interchangeable with not-quite-self-hosted modules via flags, or these LLVM-leveraging modules (e.g. for C/C++ compilation) will always be hard dependencies even in the self-hosted compiler.

Re: Zig 0.9.0

#32

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.

In which case a warning would also do the trick, unless the compiler produces so many warnings that people stop caring.

Re: Zig 0.9.0

#33
post #30

Zig is such a cool looking language, really just love the idea of comptime, but every time it comes up, all I can think about is how it's mandating spaces for indentations. I know it seems pedantic, but a programming language just saying "I don't care about accessibility by the visually impaired" when it is just text comes across as overbearing and insensitive. https://www.reddit.com/r/javascript/comments/c8drjo/nobo…

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.

Re: Zig 0.9.0

#34
post #25

Earlier quoted context omitted.

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…

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 when actually they are just screwing around with codepoints. Go's string handling is completely broken, for example. As a result of strings in the language, Go programs tend to be more broken than C programs in terms of string handling.

Re: Zig 0.9.0

#35

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 like this feature. It has saved me from annoying bugs multiple times in Go during refactoring.

[deleted]

Re: Zig 0.9.0

#36

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…

No post body was provided.

Re: Zig 0.9.0

#37
post #33
post #30

Zig is such a cool looking language, really just love the idea of comptime, but every time it comes up, all I can think about is how it's mandating spaces for indentations. I know it seems pedantic, but a programming language just saying "I don't care about accessibility by the visually impaired" when it is just text comes across as overbearing and insensitive. https://www.reddit.com/r/javascript/comments/c8drjo/nobo…

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"

Re: Zig 0.9.0

#38

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 think there should definitely be a global option to disable this during development. This makes temporarily trying something out (e.g commenting out some code to run only part of it) a massive pain, as you have to go up and edit the variable definition as well as the code using it).

Re: Zig 0.9.0

#39

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 tend to prefer a warning rather than a hard error. In CI or a production build, you can make warnings hard errors, but when trying to debug something, you can make temporaries or comment things out as needed

Re: Zig 0.9.0

#40

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

thread tl;dr:

it doesn't look like there will be language support for things like codepoints or grapheme indexing or treatment of strings as anything but byte arrays, so ddevault is sad.

there is intention from andrewrk and jecolon to provide such features in the standard library before 1.0 release.

downside to library vs lang support that is you can expect a good chunk of programmers to ignore the less-ergonomic library features, use the language features at hand, and handle strings incorrectly as byte arrays.

Post reply on HN