5 ms·

A “Better C” Benchmark

20 points by Liskni_si 6y ago

kristoff_it 6y ago
Copied from my reply on Lobsters (https://zserge.com/posts/better-c-benchmark/ https://zserge.com/posts/better-c-benchmark/) --- For what it's worth, we do understand that the lack of stdlib documentation is a problem. Before I expand on that, here's the current "workarounds" to be immediately productive: https://ziglearn.org https://ziglearn.org is a structured introduction to Zig that covers an introduction to Zig that is very friendly to newcomers. Chapter 2 in particular helps solving common problems and showcases some parts of the standard library while doing so. On the Zig SHOWTIME YouTube channel there are a few videos that can help. One video in particular is about how to approach the Zig standard library today [1], while we wait for better docs. Asking for help in a Zig community [2] is so easy it's like cheating, and it's also a door to knowing when new resources pop up. So, what's up with the stdlib docs? We have an experimental build [3] and, as the name implies, they're incomplete and not considered good. Why are we not working on them? Because the docs are a JS interface to a bunch of metadata generated by the compiler during the build phase. We are currently transitioning to a self-hosted implementation [4] of the compiler and, until it's complete enough, we are stuck with the incomplete and buggy metadata that the current C++ compiler generates. I personally plan to get involved in the docs effort once the situation gets unblocked. > I wish Zig had a better documentation to gain popularity before it becomes too niche and obscured. Oh, don't worry about that :) [1] https://www.youtube.com/watch?v=NQgju_2mX-8 https://www.youtube.com/watch?v=NQgju_2mX-8 [2] https://github.com/ziglang/zig/wiki/Community https://github.com/ziglang/zig/wiki/Community [3] https://ziglang.org/documentation/master/std/ https://ziglang.org/documentation/master/std/ [4] https://kristoff.it/blog/zig-new-relationship-llvm/ https://kristoff.it/blog/zig-new-relationship-llvm/
coldtea 6y ago
I was fairly hyped up about Zig with various HN pieces I've read and wanted to check it out. After reading the status of strings in Zig in this post, and going on and reading this ludicrous exchange: [1], I wouldn't touch it with a 100-ft pole. Half of the brokage of C is in the string handling (safety aside), and this is what passes for a 'better C' candidate in 2021? And don't get me started on their discussion on Unicode support. It's like some bizarro alternative universe, where ASCII or a bag of bytes is good enough... [1] https://github.com/ziglang/zig/issues/234 https://github.com/ziglang/zig/issues/234
- AndyKelley 6y ago
  People who act like this are always the same ones that try to implement string handling and do it incorrectly. Zig is saving people like you from handling strings incorrectly.
  - coldtea 6y ago
    How so, though, as the discussion seems to show a lack of knowledge on Unicode on the part of the language's team - bigger than even a "guy like me" has. As an example there's reading and outputing the same byte sequence unmodified and concluding: "See? unicode totally works with a byte array, why would we ever need anything else?" (meanwhile the byte array could just as well have any crap that's not a valid utf-8 string for example, and 100s of ways to mess it up further, with the existing byte manipulation functions). As for delegating it to the std lib, that at least would be something (though not as convenient as a first class type for something as important as strings), well, where is it, for a language nearing 1.0? I see Zig as inviting everyone to make their own string handling and mess it up in unique and wonderful ways, or have several string libs with subtly incompatible handling used in different third party projects... Now, as always I came to regret my whining when the other side replies in person (damn you, HN), and I would like to say that I am a huge fun of most design decisions in Zig nonetheless and I was very excited to evaluate it and put it to use. But the string situation seems like a major oversight or under-estimation, when I saw the string manipulations (or lack thereof) in the example code, and this thread. BurntSushi seems to think it can be fixed in the std lib alone (and if someone knows about strings, he would be it) -- but I think that even for that, a more serious consideration towards strings should be taken compared to the one shown in the thread.
    - burntsushi 6y ago
      I kind of think you're maybe reading a bit more out of that thread than maybe what's there. From what I can tell, the only thing that came out of that thread is that they aren't convinced that language support for string types is necessary. I've seen the Zig folks acknowledge that the standard library needs work/polish, and that they're focusing on the compiler right now. If the standard library doesn't have good string support (I don't know, I haven't looked that closely), then I would basically assume that they'll get that figured out before 1.0 unless I see a really explicit declaration otherwise. Because I think that would be surprising to me if they didn't. But even with Rust, there are multiple string libraries. I even made one. :P https://docs.rs/bstr https://docs.rs/bstr is really just a bunch of API functions defined on a bundle of bytes. There's no language support to help make it work, but it doesn't really need it. The only language support Rust really gives to strings is maybe carving out its own type and string literals themselves. Rust demands that its string type be UTF-8, where as Go doesn't, for example. Either choice is reasonable. But that's pretty much where the language level support ends. Everything else is just library goop. But yes, if Zig's standard library doesn't have the kind of bare bones string handling that already exists in places like Rust's and Go's standard library, then I would hope/expect they will get to that at some point. If they didn't do that at least, then yeah, okay, I'll either be surprised or I'm misunderstanding something.

20 points by Liskni_si 6y ago

Copied from my reply on Lobsters (https://zserge.com/posts/better-c-benchmark/ https://zserge.com/posts/better-c-benchmark/) --- For what it's worth, we do understand that the lack of stdlib documentation is a problem. Before I expand on that, here's the current "workarounds" to be immediately productive: https://ziglearn.org https://ziglearn.org is a structured introduction to Zig that covers an introduction to Zig that is very friendly to newcomers. Chapter 2 in particular helps solving common problems and showcases some parts of the standard library while doing so. On the Zig SHOWTIME YouTube channel there are a few videos that can help. One video in particular is about how to approach the Zig standard library today [1], while we wait for better docs. Asking for help in a Zig community [2] is so easy it's like cheating, and it's also a door to knowing when new resources pop up. So, what's up with the stdlib docs? We have an experimental build [3] and, as the name implies, they're incomplete and not considered good. Why are we not working on them? Because the docs are a JS interface to a bunch of metadata generated by the compiler during the build phase. We are currently transitioning to a self-hosted implementation [4] of the compiler and, until it's complete enough, we are stuck with the incomplete and buggy metadata that the current C++ compiler generates. I personally plan to get involved in the docs effort once the situation gets unblocked. > I wish Zig had a better documentation to gain popularity before it becomes too niche and obscured. Oh, don't worry about that :) [1] https://www.youtube.com/watch?v=NQgju_2mX-8 https://www.youtube.com/watch?v=NQgju_2mX-8 [2] https://github.com/ziglang/zig/wiki/Community https://github.com/ziglang/zig/wiki/Community [3] https://ziglang.org/documentation/master/std/ https://ziglang.org/documentation/master/std/ [4] https://kristoff.it/blog/zig-new-relationship-llvm/ https://kristoff.it/blog/zig-new-relationship-llvm/

coldtea 6y ago

I was fairly hyped up about Zig with various HN pieces I've read and wanted to check it out. After reading the status of strings in Zig in this post, and going on and reading this ludicrous exchange: [1], I wouldn't touch it with a 100-ft pole. Half of the brokage of C is in the string handling (safety aside), and this is what passes for a 'better C' candidate in 2021? And don't get me started on their discussion on Unicode support. It's like some bizarro alternative universe, where ASCII or a bag of bytes is good enough... [1] https://github.com/ziglang/zig/issues/234 https://github.com/ziglang/zig/issues/234

AndyKelley 6y ago
People who act like this are always the same ones that try to implement string handling and do it incorrectly. Zig is saving people like you from handling strings incorrectly.
- coldtea 6y ago
  How so, though, as the discussion seems to show a lack of knowledge on Unicode on the part of the language's team - bigger than even a "guy like me" has. As an example there's reading and outputing the same byte sequence unmodified and concluding: "See? unicode totally works with a byte array, why would we ever need anything else?" (meanwhile the byte array could just as well have any crap that's not a valid utf-8 string for example, and 100s of ways to mess it up further, with the existing byte manipulation functions). As for delegating it to the std lib, that at least would be something (though not as convenient as a first class type for something as important as strings), well, where is it, for a language nearing 1.0? I see Zig as inviting everyone to make their own string handling and mess it up in unique and wonderful ways, or have several string libs with subtly incompatible handling used in different third party projects... Now, as always I came to regret my whining when the other side replies in person (damn you, HN), and I would like to say that I am a huge fun of most design decisions in Zig nonetheless and I was very excited to evaluate it and put it to use. But the string situation seems like a major oversight or under-estimation, when I saw the string manipulations (or lack thereof) in the example code, and this thread. BurntSushi seems to think it can be fixed in the std lib alone (and if someone knows about strings, he would be it) -- but I think that even for that, a more serious consideration towards strings should be taken compared to the one shown in the thread.
  - burntsushi 6y ago
    I kind of think you're maybe reading a bit more out of that thread than maybe what's there. From what I can tell, the only thing that came out of that thread is that they aren't convinced that language support for string types is necessary. I've seen the Zig folks acknowledge that the standard library needs work/polish, and that they're focusing on the compiler right now. If the standard library doesn't have good string support (I don't know, I haven't looked that closely), then I would basically assume that they'll get that figured out before 1.0 unless I see a really explicit declaration otherwise. Because I think that would be surprising to me if they didn't. But even with Rust, there are multiple string libraries. I even made one. :P https://docs.rs/bstr https://docs.rs/bstr is really just a bunch of API functions defined on a bundle of bytes. There's no language support to help make it work, but it doesn't really need it. The only language support Rust really gives to strings is maybe carving out its own type and string literals themselves. Rust demands that its string type be UTF-8, where as Go doesn't, for example. Either choice is reasonable. But that's pretty much where the language level support ends. Everything else is just library goop. But yes, if Zig's standard library doesn't have the kind of bare bones string handling that already exists in places like Rust's and Go's standard library, then I would hope/expect they will get to that at some point. If they didn't do that at least, then yeah, okay, I'll either be surprised or I'm misunderstanding something.