Comment by ksec

Comment by ksec a day ago

16 replies

View on Hacker News

I think it is a trade off for between zig's development speed and documentation. It is Pre 1.0, extreme beta mode with lots of breaking changes.

Generally speaking I think it is the right trade off for now. Purely inferring from Andrew and the Zig's team online character as I don't know them in person, I think they do care a lot of DX, things like compiling speed and tools. So I think once 1.0 come I won't be surprised if it will have extremely good documentation as well.

And I would argue, writing good, simple, clear, detailed documentation is actually harder than writing code itself.

brabel a day ago

I've written many APIs. Never have I got it right without first writing lots of tests, finding the rough corners, improving it... and so on. Writing documentation after that is absolutely mandatory for the end result to be a high quality API. As you write how it is meant to work, you will definitely find things that don't really make sense, or that should not be as hard ( I think this post shows just such an API that hasn't gone through this process ). IMHO documentation is NOT optional. The implementation is NOT how you mean for the API to be used.

Reply View 0 replies
hardwaresofton a day ago

On the one hand, I totally get that pre 1.0 is the wild west (somewhat) and should be. The team is right in jealously guarding their ability to make changes.

That said, others have pointed out that writing documentation and tests helps improve quality quite a bit, and in this case it would also increase usability. I think I'd agree with this stance, but there is no way I could make the statement that even most of the code I've written for public consumption had excellent documentation or examples. So I've got no leg to stand on there, just the armchair.

> And I would argue, writing good, simple, clear, detailed documentation is actually harder than writing code itself.

All the more reason why it must be done! A little silly but from my armchair maybe it's one of those "start with the interface you want and work backwards", but the problem is that approach can be at odds with mechanical sympathy and we know which side Zig lands on (and arguably should land on based on it's values).

Reply View 0 replies
LambdaComplex a day ago

My quick skim of Wikipedia may not be telling the complete story, but it says the initial release was 9 years ago (February 2016). After nearly a decade, I would hope that things would be out of "extreme beta mode," but I guess this isn't the case?

Reply View 12 replies
  • ksec a day ago

    For most of its time it is simply a single person and part time project. Even to this day the team is nowhere near Rust or Go's resources.

    Reply View 3 replies
    • tialaramex a day ago

      In 2016, nine years ago, Andrew announced he'd been working on the new language "Zig" for a couple of months.

      In 2018, seven years ago, Andrew announced he'd go full-time on Zig and quit his paying job to live off donations instead.

      In 2020, so five years ago, Zig's 501(c)3 the ZSF was announced, to create a formal structure to hire more people in addition to the few already on Zig.

      So, "most of its time" is just not true. For "most of its time" Zig was a small, largely independently funded project for multiple people, for a tiny period it was a part-time project, and for a while after that it was solo, but those weren't the majority of its existence.

      Reply View 1 reply
      • throwawaymaths a day ago

        yeah but i think you can count on one hand how many full time zig developers are paid by the foundation.

        Reply View 0 replies
    • LambdaComplex a day ago

      Huh, I actually expected there to be a bigger team working on it. In that case: I'm really impressed.

      Reply View 0 replies
  • HumanOstrich a day ago

    What's the benchmark for how long something can be pre-1.0? Seems like a nonsense argument.

    Reply View 6 replies
    • Dylan16807 a day ago

      It's the combination of pre-1.0 and having rapid development speed that is being questioned here. And it's a good question, not nonsense.

      If you keep up the development pace you're going to approach stability. Unless you're in a manic spiral of rewrites.

      Reply View 0 replies
    • yxhuvud a day ago

      Something can be pre-1.0 as long as there are no stability guarantees.

      Reply View 0 replies
    • pharrington a day ago

      There is no benchmark. As a species, we don't even know know what a good programming language is, let alone how to reliably develop one. This stuff takes time, and we're all learning it together.

      I like to compare this to real world cathedral building. There are some cathedrals that are literally taking centuries to build! It's OK if the important, but difficult thing takes a long time to build.

      Reply View 2 replies
      • Dylan16807 a day ago

        Cathedrals are the opposite of extreme beta mode with lots of breaking changes.

        Reply View 1 reply
        • pharrington a day ago

          Yes. I guess what I meant is that cathedrals are a complex system that we know how to do, and still they take ages to build properly.

          Reply View 0 replies
  • littlestymaar a day ago

    Same as Rust being almost a decade old when the first 1.0 was published.

    Making a programming language from scratch is a long endeavor when it's a one man project.

    Reply View 0 replies
sshine a day ago

Unstable APIs are a good example of something that's extremely valuable early on.

They unarguably cause confusion for everyone as they change.

But it lets you choose the right abstractions that are going to stick for decades.

If you're going to make a python2 -> python3 transition in your language, make sure it's X0 -> X1.

Reply View 0 replies