6 ms·

As a seasoned Zig programmer, this is good information, though painful to read. A lot of the problems seem to be from a fundamental misunderstanding of Zig's ph

As a seasoned Zig programmer, this is good information, though painful to read. A lot of the problems seem to be from a fundamental misunderstanding of Zig's philosophy and very basic things about how the language works. Possibly Zig needs more emphasis on those things in its documentation. I also have to wonder about a fundamental misalignment of thinking when someone says downloading and replacing a single .exe is tedious, and isn't at all excited about 'Why Zig' list. If none of those things seem like compelling ideas to you then yeah, the language probably isn't for you.

SiVal 5y ago
If there are fundamental philosophies in a programming language (and there usually are), tutorials ought to begin with lots of tiny example programs that exemplify those fundamentals. They should continue with examples of gradually increasing complexity, but ALWAYS using those same fundamentals in various combinations to show how those fundamentals are intended to work together in all sorts of ways. If the tutorials aren't deliberately built up from the language's own defining philosophical fundamentals introduced singly and then in combination, then someone like me will just re-use the fundamentals I learned in whatever other languages I know that feel most similar to the new one. Most languages can be used in roughly parallel ways with just a change in syntax, even if that's not how they are supposed to be used, and if I (like most of us) have to get up and running ASAP in some new tool and don't have a quick on-ramp to establish the preferred patterns right from the start, I'll just have to re-use as much as I already know and just get on with it.
- llimllib 5y ago
  My understanding of the Zig's team's opinion is that Zig is not currently at a place where they want to solidify the design by doing such things as writing extensive tutorials documenting how to write it - tutorials that will need to be updated every time they make breaking changes, which they explicitly still want to do. A lot of this seems to be a mismatch between people's expectations of zig's stability and the reality?
  - snek_case 5y ago
    The way you handle that is by adding all your tutorials to the test of tests for the compiler. Then, whenever a breaking change happens, you have to update the tutorials for the tests to pass, which isn't difficult since you're probably only talking about minor, incremental changes.
    - all2 5y ago
      I like this idea quite a lot. If you can write the tutorial itself in a "literate code" sort of way, the test harness should be able to consume the entire tutorial and run tests against it. Presuming, of course, that there's a way to tangle/weave using standard comments in Zig. Sounds like it could be a fun project. Could also serve as a way to auto-doc (like JavaDocs or similar using documentation generators).
      - AnIdiotOnTheNet 5y ago
        Zig already does this with its current documentation and example code.
        all2 5y ago
        I saw that after reading further. Loris (I don't remember his user name here) also said he plans on rewriting it from scratch on Twitch. I may tune in just to see how his mind works. :D
        _vvhw 5y ago
        Well worth doing, I've learned a lot about coding from Loris.
- jibalt 5y ago
  You're talking about idioms, not philosophy ... the philosophy of Zig can be obtained by running `zig zen`. And the OP didn't even read the Hello World section of the Zig Reference Manual that has an example of printing.
dnautics 5y ago
Nah, I think it is fine. The problems are almost all (the author's) problems with zig's philosophy of "when to do things you need for a 1.0". Author mostly wants docs, guides, error messages, and package manager, which are supposed to be "late in the development process" according to my understanding of the unofficial zig roadmap.
- jibalt 5y ago
  The author didn't even read the Hello World section of the Zig Reference Manual that (of course) has an example of printing.
mst 5y ago
I have a feeling that Zig is sufficiently different to most other languages in the space that developing a mental model for the way things are supposed to fit together is something that involves "aha" moments - the sort that are tricky to produce for everybody via a single piece of documentation because the thing that makes it snap together in a particular person's head varies widely between people. Similar to the process of getting the concepts of git when you've come from other version control systems. (I have a horrible feeling that the solution to this is mostly going to be "lots of people writing tutorials that approach it in different ways until there's at least one tutorial out there that will work for (most values of) any given person", and having been there on projects of mine I sympathise with the unsatisfyingness of this conclusion)
- jibalt 5y ago
  When I saw the first line of some Zig code, it was unusual so I thought about it and got an inkling of the idea behind it and its power: const std = @import("std"); When I saw the second line and subsequent similar lines, I realized it was effing brilliant: const os = std.os; std and os here are names bound to types ... and you can have type variables and do compile-time manipulation and construction of types. This is confirmed in the manual when it talks about generic types being the return values of functions executed at compile time that take types (and/or other comptime values) as arguments -- while C++ templates are purportedly Turing complete, this is far more powerful in practice because it's vastly easier and more straightforward. Looking at code in the library like MultiArrayList--which implements AoS (array of structures) in the library rather than in the language--further confirms this. So what's going on with those `std` and `os` bindings? The answer is given at the beginning of the Zig Language Reference (https://ziglang.org/documentation/master/ https://ziglang.org/documentation/master/) (which the OP apparently didn't read since it has a Hello World program that is an example of how to print): "The @import("std") function call creates a structure that represents the Zig Standard Library". So essentially, every source file represents an anonymous struct (all Zig structs are anonymous), the members of which are the top level declarations in the file--or rather, @import(filename) presents the file as such a struct, which can be assigned to a type variable like `std`. And `std.os` is in turn a type variable whose value is @import("os.zig") ... except that the actual value of `std.os` is computed based on the target machine. By turning files into comptime data structures containing all of the file's top level declarations, and having Zig code executable at comptime, immense power is achieved and one of the consequences of this is that zig running on any host is a complete cross compiler that can generate code for any target, using an appropriate target-specific version of the library. And it only took me a little bit of reading of docs and code to get my "aha" about how this works.
thayne 5y ago
The biggest thing that stands out to me from the complaints is the lack of documentation, which is probably part of the misunderstanding of the philosophy.
jibalt 5y ago
>A lot of the problems seem to be from a fundamental misunderstanding of Zig's philosophy and very basic things about how the language works. Possibly Zig needs more emphasis on those things in its documentation. As a rank beginner, I had no problem learning these things ... they're mentioned repeatedly in material about Zig both from the project and from outside descriptions, the philosophy is the output of `zig zen` and in all the documentation, etc. The OP couldn't figure out how to print despite the Hello World program at the beginning of the Zig Reference Manual. I think most of the issues here are PEBKAC.

SiVal 5y ago

If there are fundamental philosophies in a programming language (and there usually are), tutorials ought to begin with lots of tiny example programs that exemplify those fundamentals. They should continue with examples of gradually increasing complexity, but ALWAYS using those same fundamentals in various combinations to show how those fundamentals are intended to work together in all sorts of ways. If the tutorials aren't deliberately built up from the language's own defining philosophical fundamentals introduced singly and then in combination, then someone like me will just re-use the fundamentals I learned in whatever other languages I know that feel most similar to the new one. Most languages can be used in roughly parallel ways with just a change in syntax, even if that's not how they are supposed to be used, and if I (like most of us) have to get up and running ASAP in some new tool and don't have a quick on-ramp to establish the preferred patterns right from the start, I'll just have to re-use as much as I already know and just get on with it.

llimllib 5y ago
My understanding of the Zig's team's opinion is that Zig is not currently at a place where they want to solidify the design by doing such things as writing extensive tutorials documenting how to write it - tutorials that will need to be updated every time they make breaking changes, which they explicitly still want to do. A lot of this seems to be a mismatch between people's expectations of zig's stability and the reality?
- snek_case 5y ago
  The way you handle that is by adding all your tutorials to the test of tests for the compiler. Then, whenever a breaking change happens, you have to update the tutorials for the tests to pass, which isn't difficult since you're probably only talking about minor, incremental changes.
  - all2 5y ago
    I like this idea quite a lot. If you can write the tutorial itself in a "literate code" sort of way, the test harness should be able to consume the entire tutorial and run tests against it. Presuming, of course, that there's a way to tangle/weave using standard comments in Zig. Sounds like it could be a fun project. Could also serve as a way to auto-doc (like JavaDocs or similar using documentation generators).
    - AnIdiotOnTheNet 5y ago
      Zig already does this with its current documentation and example code.
      - all2 5y ago
        I saw that after reading further. Loris (I don't remember his user name here) also said he plans on rewriting it from scratch on Twitch. I may tune in just to see how his mind works. :D
        _vvhw 5y ago
        Well worth doing, I've learned a lot about coding from Loris.
jibalt 5y ago
You're talking about idioms, not philosophy ... the philosophy of Zig can be obtained by running `zig zen`. And the OP didn't even read the Hello World section of the Zig Reference Manual that has an example of printing.

dnautics 5y ago

Nah, I think it is fine. The problems are almost all (the author's) problems with zig's philosophy of "when to do things you need for a 1.0". Author mostly wants docs, guides, error messages, and package manager, which are supposed to be "late in the development process" according to my understanding of the unofficial zig roadmap.

jibalt 5y ago
The author didn't even read the Hello World section of the Zig Reference Manual that (of course) has an example of printing.

mst 5y ago

I have a feeling that Zig is sufficiently different to most other languages in the space that developing a mental model for the way things are supposed to fit together is something that involves "aha" moments - the sort that are tricky to produce for everybody via a single piece of documentation because the thing that makes it snap together in a particular person's head varies widely between people. Similar to the process of getting the concepts of git when you've come from other version control systems. (I have a horrible feeling that the solution to this is mostly going to be "lots of people writing tutorials that approach it in different ways until there's at least one tutorial out there that will work for (most values of) any given person", and having been there on projects of mine I sympathise with the unsatisfyingness of this conclusion)

jibalt 5y ago
When I saw the first line of some Zig code, it was unusual so I thought about it and got an inkling of the idea behind it and its power: const std = @import("std"); When I saw the second line and subsequent similar lines, I realized it was effing brilliant: const os = std.os; std and os here are names bound to types ... and you can have type variables and do compile-time manipulation and construction of types. This is confirmed in the manual when it talks about generic types being the return values of functions executed at compile time that take types (and/or other comptime values) as arguments -- while C++ templates are purportedly Turing complete, this is far more powerful in practice because it's vastly easier and more straightforward. Looking at code in the library like MultiArrayList--which implements AoS (array of structures) in the library rather than in the language--further confirms this. So what's going on with those `std` and `os` bindings? The answer is given at the beginning of the Zig Language Reference (https://ziglang.org/documentation/master/ https://ziglang.org/documentation/master/) (which the OP apparently didn't read since it has a Hello World program that is an example of how to print): "The @import("std") function call creates a structure that represents the Zig Standard Library". So essentially, every source file represents an anonymous struct (all Zig structs are anonymous), the members of which are the top level declarations in the file--or rather, @import(filename) presents the file as such a struct, which can be assigned to a type variable like `std`. And `std.os` is in turn a type variable whose value is @import("os.zig") ... except that the actual value of `std.os` is computed based on the target machine. By turning files into comptime data structures containing all of the file's top level declarations, and having Zig code executable at comptime, immense power is achieved and one of the consequences of this is that zig running on any host is a complete cross compiler that can generate code for any target, using an appropriate target-specific version of the library. And it only took me a little bit of reading of docs and code to get my "aha" about how this works.

thayne 5y ago

The biggest thing that stands out to me from the complaints is the lack of documentation, which is probably part of the misunderstanding of the philosophy.

jibalt 5y ago

>A lot of the problems seem to be from a fundamental misunderstanding of Zig's philosophy and very basic things about how the language works. Possibly Zig needs more emphasis on those things in its documentation. As a rank beginner, I had no problem learning these things ... they're mentioned repeatedly in material about Zig both from the project and from outside descriptions, the philosophy is the output of `zig zen` and in all the documentation, etc. The OP couldn't figure out how to print despite the Hello World program at the beginning of the Zig Reference Manual. I think most of the issues here are PEBKAC.