4 ms·

IMHO the fact that Zig already gained a lot of track in software development does bring some responsibilities whether the devs like it or not. If you create a l

IMHO the fact that Zig already gained a lot of track in software development does bring some responsibilities whether the devs like it or not. If you create a language that good and something that is actually taken seriously for tackling the behemoth task of being the actual predecessor for C that has been around half a century, then you CANNOT simply excuse weak points with "the language is not done, yet.". No sorry for you guys, you made some freaking good stuff, people wanna use it in production already, deal with your success. And there aren't even many pain points with the language itself. Most of them are meta. Here are my pain points: - Documentation: Step it up... this is a mess. I might be able to learn it because I learned many languages over the years, but many people will just give up frustrated and never turn back. And even so I am mostly OK with the docs, I still miss stuff. One of the worst things could as well be its own point: Document the build system darn it. It is so hard to learn, that I prefer using any other build system or even creating manual zig commands. - ZLS needs to be merged as part of the project. The fact that it is not always on par with every commit is annoying. A language server should be an inseparable part of a language nowadays. - And now to one of the few pain points I have with the language itself: You cannot be serious about that "underscore, unused variable" solution. That is so extremely ugly and code polluting. I know this critique was harsh, but it is because I love this language and I think it will take off so heavily :). My fear is that if those things are not considered that at a certain point users will be annoyed by Zig and it will lose a big amount of userbase.

rofrol 2y ago
This may help - https://ziggit.dev/t/build-system-tricks/3531 https://ziggit.dev/t/build-system-tricks/3531 - https://ziggit.dev/t/how-to-package-a-zig-source-module-and-how-to-use-it/3457 https://ziggit.dev/t/how-to-package-a-zig-source-module-and-... - https://ziggit.dev/t/importation-and-dependencies/4067/14 https://ziggit.dev/t/importation-and-dependencies/4067/14
ngrilly 2y ago
Considering that the language is "not done yet", I think the documentation is quite ok for now. But I'd really like a proper language specification, similar to https://go.dev/ref/spec https://go.dev/ref/spec, updated in lockstep with the implementation. I also agree that the build system needs some minimal documentation. It is a bit arcane without it. Considering that a major goal of Zig is to build and maintain robust software, the decision of making unused variables an error is interesting and worth exploring. It works pretty well in practice when we use ZLS, which goes back to your point about making ZLS part of the standard toolchain. > deal with your success And how exactly should the Zig team deal with its success? That's a small team, with limited funding. Do you think they should prioritize the pain points you listed over the ones in their current roadmap?
ksec 2y ago
This isn't specific to Zig. But most thing you said is a feature not a bug. Let me quote from the release note. >This Release Contains Bugs, Zig has known bugs and even some miscompilations. >Zig is immature. Even with Zig 0.12.0, working on a non-trivial project using Zig will likely require participating in the development process. I dont think documentation should be priority for Zig at this stage, just read the Release Note and you will see how things are changing and breaking all the time. But I do agree certain things should be documented, as suggested in another reply is the Spec and build system.
geodel 2y ago
Seems, Java/C#/C++ more to your taste where corporate behemoths behind them can put more people on documentation and assorted tooling than zig has for core development. > My fear is that if those things are not considered that at a certain point users will be annoyed by Zig and it will lose a big amount of userbase. They won't use much user base as that kind of users will remain committed to using corporate managed languages.

rofrol 2y ago

This may help - https://ziggit.dev/t/build-system-tricks/3531 https://ziggit.dev/t/build-system-tricks/3531 - https://ziggit.dev/t/how-to-package-a-zig-source-module-and-how-to-use-it/3457 https://ziggit.dev/t/how-to-package-a-zig-source-module-and-... - https://ziggit.dev/t/importation-and-dependencies/4067/14 https://ziggit.dev/t/importation-and-dependencies/4067/14

ngrilly 2y ago

Considering that the language is "not done yet", I think the documentation is quite ok for now. But I'd really like a proper language specification, similar to https://go.dev/ref/spec https://go.dev/ref/spec, updated in lockstep with the implementation. I also agree that the build system needs some minimal documentation. It is a bit arcane without it. Considering that a major goal of Zig is to build and maintain robust software, the decision of making unused variables an error is interesting and worth exploring. It works pretty well in practice when we use ZLS, which goes back to your point about making ZLS part of the standard toolchain. > deal with your success And how exactly should the Zig team deal with its success? That's a small team, with limited funding. Do you think they should prioritize the pain points you listed over the ones in their current roadmap?

ksec 2y ago

This isn't specific to Zig. But most thing you said is a feature not a bug. Let me quote from the release note. >This Release Contains Bugs, Zig has known bugs and even some miscompilations. >Zig is immature. Even with Zig 0.12.0, working on a non-trivial project using Zig will likely require participating in the development process. I dont think documentation should be priority for Zig at this stage, just read the Release Note and you will see how things are changing and breaking all the time. But I do agree certain things should be documented, as suggested in another reply is the Spec and build system.

geodel 2y ago

Seems, Java/C#/C++ more to your taste where corporate behemoths behind them can put more people on documentation and assorted tooling than zig has for core development. > My fear is that if those things are not considered that at a certain point users will be annoyed by Zig and it will lose a big amount of userbase. They won't use much user base as that kind of users will remain committed to using corporate managed languages.