A “Better C” Benchmark

https://zserge.com/posts/better-c-benchmark/

by Liskni_si • 5 years ago

20 14 5 years ago

Copied from my reply on Lobsters (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 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 [2] https://github.com/ziglang/zig/wiki/Community [3] https://ziglang.org/documentation/master/std/ [4] https://kristoff.it/blog/zig-new-relationship-llvm/

coldtea4• 5 years 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

AndyKelley3• 5 years 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.

coldtea4• 5 years 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.

kristoff_it3• 5 years ago

where ASCII or a bag of bytes is good enough...

You are definitely misunderstanding both Zig's stance on this, and how unicode works in a more general sense.

coldtea4• 5 years ago

Well, everything is a "big bug of bytes" in computing in the "more general sense", so there's that.

I don't think handling unicode (and even more importantly, specific encodings) in this level of abstraction, and delegating things to second-tier lib support is the way to go. But I don't even see this second-tier support prioritized - for something one would think is half of programming: dealing with strings.

burntsushi3• 5 years ago

What specifically looks bad there? The only decision I see is that string handling doesn't need to be in the language and that it should be a concern of the standard library. That doesn't seem unreasonable to me. Or at least, not as unreasonable as you make it sound. It's true that Rust and Go have language level support for Unicode strings, but the actual language features for it are quite light. It buys a little bit of convenience maybe. But the vast majority of the burden of those string types is carried by the standard library.

A “Better C” Benchmark

Related Stories