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

131–140 of 250 posts

Re: Zig 0.9.0

#131

Post by Vendan »

zamadatix wrote: post #81
Vendan wrote: post #77

Earlier quoted context omitted.

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

Using the built in formatter is optional, you'll be free to run your own formatter. Right now you might be more worried about how the current compiler can't even compile Zig correctly before worrying about what stylistic choices it can handle. I'm a tabs guy myself but it's really quite irrelevant at the moment - the focus is still on figuring out how Zig should work and making that happen not day to day usability of…

Please see https://github.com/ziglang/zig/issues/544#issuecomment-36396... and https://github.com/ziglang/zig/issues/663. In particular, `For every codepoint of zig source code, it is an error for the codepoint to be one of U+0000-U+0009, U+000b-U+001f, U+007f, U+0085, U+2028, U+2029`. Hard tab is U+0009, which is called out as specifically an error. This could just be stale docs, but it's linked to from the wiki as well: https://github.com/ziglang/zig/wiki/FAQ#why-does-zig-fmt-hav.... Again, if this is all old, please ignore (and maybe make it a priority to update?). But the general tone is: "No tabs, only spaces"

Re: Zig 0.9.0

#132

Post by ncmncm »

jhgb wrote: post #115
tw102 wrote: post #111

Earlier quoted context omitted.

Unfortunately malloc-free is unavoidable if you're writing code that needs to allocate memory rather carefully (e.g. guaranteeing no OOMs—Rust has many situations where it'll silently heap alloc and then panic on OOM). Looks like Zig has accepted that it'll be used for those situations and decided to make that experience really good, instead of deciding to be a rustalike or insist on RAII. I think that's an appropria…

I imagine that Zig has a lot more focus on "I can't use X in my environment" types of situation. It seems that for many such situations it might be a better fit than Rust.

There is, for practical purposes, noplace where one can't use C++, except where gatekeepers exercise power keep it out. Typically it would be only a day's work to get those building with a C++ compiler, whence they could begin modernizing.

There are plenty of loadable modules in C++ for Linux and BSDs, and plugins for Postgres, in places where there is no expectation of upstreaming them.

Zig is in a similar boat.

Re: Zig 0.9.0

#133

Post by Shadonototra »

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.

No post body was provided.

Re: Zig 0.9.0

#134

Post by lhorie »

Vendan wrote: post #77
lhorie wrote: post #73

Earlier quoted context omitted.

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 wouldn't read too much into what `zig fmt` means in terms of what is supposed to be idiomatic. Like many things in zig land, `zig fmt` isn't really mature yet - e.g. it still mis-formats things like long expression chains among other things. They are still planning to do a polish pass over all of these DX-related aspects of the project (fmt, stdlib). I'd expect this bikeshed to resurrect in full force once they start looking into zig fmt more seriously.

Re: Zig 0.9.0

#135

Post by svnpenn »

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…

> Go's string handling is completely broken, for example.

Classic Andy, shitting on other language with no references or examples. Go has some of the best string handling I've used. Seamless byte, rune, string conversion. Simple iterating and slicing. Plus helpful tools like strings.Builder and strconv.AppendInt. while Zig has nothing.

Re: Zig 0.9.0

#136

Post by errantmind »

Congrats.

Here's to hoping Zig gets explicit SIMD intrinsics in 1.0. It is one of the few things holding me back. That and the pedantic compiler errors around unused variables.

Re: Zig 0.9.0

#137

Post by bvrmn »

fastball wrote: post #108
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…

I don't think I've ever had a problem with Python3's string handling, which is very robust.

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

Re: Zig 0.9.0

#138

Post by bnprks »

errantmind wrote: post #136

Congrats. Here's to hoping Zig gets explicit SIMD intrinsics in 1.0. It is one of the few things holding me back. That and the pedantic compiler errors around unused variables.

I'm pretty new to Zig, but after taking another look recently I was pleasantly surprised by the progress on SIMD operations via builtin Vector types [1],[2]. For an application of "I want to speed up my math-intensive code with SIMD while supporting x86-64, aarch64, and non-SIMD fallbacks" it might be suitable for you now, and Zig certainly exposes more readable SIMD syntax than with C intrinsics imho [3]. But if you have a particular CPU instruction in mind, you're still a little bit at the mercy of the compiler as operations on Vector types aren't explicitly tied to particular CPU instructions.

1: https://github.com/ziglang/zig/issues/903#issuecomment-45950...

2: https://ziglang.org/documentation/master/#Vectors

3: https://godbolt.org/z/P73MPncGP

Re: Zig 0.9.0

#139

Post by pcwalton »

AndyKelley wrote: post #103
pcwalton wrote: post #29

Earlier quoted context omitted.

That warning has caught bugs for me when I was copy and pasting code, or writing code on "autopilot". Usually it's pretty obvious mistakes though. Unused variable warnings are a good idea, but making them hard errors is a language design mistake. Warnings are good because they allow programmers to quickly make changes and test things, while providing a reminder to clean things up in the end (which is why the "just us…

Pretty bold to call it a language design mistake so confidently, when you have Rust users committing warning-emitting code to their source control. Does Rust emit warnings for cached compilation units?

Cargo doesn't enable warnings for crate dependencies, by design. In fact, it won't even emit them if those crates say #[deny(warnings)]--there's a special rustc flag called --cap-lints that it uses for this (RFC at [1]). The reason is that a lot of crates say #[deny(warnings)], and this was creating no end of backwards compatibility problems when new warnings were added.

There is an interesting thread with community consensus against the use of #[deny(warnings)] at [2]. The most important takeaway for me is that the right place to deny warnings is in CI. You don't want end users who compile your crate to be have their builds fail due to warnings, because they might be using a newer version of the compiler than you were. You don't want to fail developers' builds due to warnings while hacking on code, because of the overhead warnings-as-errors adds to the edit/compile/debug cycle. CI is the right place to deny warnings, because it prevents warnings from getting to the repository while avoiding the other downsides of warnings-as-errors.

[1]: https://rust-lang.github.io/rfcs/1193-cap-lints.html

[2]: https://www.reddit.com/r/rust/comments/f5xpib/psa_denywarnin...

Re: Zig 0.9.0

#140

Post by eyelidlessness »

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…

As a counterpoint from primarily experience with higher level languages, not being able to distinguish strings from just any blob of bytes is something that’s consistently put me off lower level languages. Sure you can just treat it as a blob of bytes but… you can’t do anything with it with certainty. That seems to be the class of bugs you’re describing? But this isn’t an issue in languages where a string is a distinct type (even if dynamic).
Post reply on HN