9 ms·

I've now written a lot of zig code (http.zig, websocket.zig, log.zig, zuckdb.zig, etc.) I think Zig falls into an "easy to learn, average/hard to master" catego

by latch 3y ago

I've now written a lot of zig code (http.zig, websocket.zig, log.zig, zuckdb.zig, etc.) I think Zig falls into an "easy to learn, average/hard to master" category. Some insiders underestimate the effort required for newcomers to build non-trivial things. I think this is because some of that complexity has to do with things like poor documentation, inconsistent stdlib, incompatible releases, slow release cycle, lack of package manager, etc. For an insider living and breathing Zig, not only aren't these huge challenges, they aren't really "Zig" - they are just transient growing pains. For someone getting started though, the current state of Zig is Zig. I wish Zig had a polished package manager (there's one in the current development branch, but you don't as much use it as fight it). They could then move some of the less polished code into official experimental packages, helping to set expectations and maybe focus the development efforts.

zoogeny 3y ago
I've lately thought that a package manager is as essential to a new language as a standard library. I would also add a LSP and standard code formatter to that list. It is a bit unfortunate because all of the above is a pretty tall order. We're getting to the point that new languages are expected to boil the ocean by the time they reach 1.0
- arp242 3y ago
  Zig has a pretty decent LSP. I'm not so sure a package manager is really all that essential; it can certainly be convenient but especially in the space Zig is looking at it's pretty workable without one (without complex deep dependency trees you can use git submodules or just copy a directory). Or let me put it this way: I never really missed a package manager in Zig.
  - ReleaseCandidat 3y ago
    > I'm not so sure a package manager is really all that essential; For open source software (libraries or programs, that depend on other libraries or programs), it is essential (if you're not distributing single functions like with Unison). For closed source it doesn't matter that much.
    - arp242 3y ago
      "cp -r ~/some-lib ~/my-project/" works well enough if some-lib doesn't have dependencies on its own. Or git submodules if you want something a bit more fancy. I sometimes do this even for languages with package managers, as it avoids a world of complexity. Obviously a package manager is useful, but Zig is relatively low-level and long dependency chains are much less common than in e.g. Python, Ruby, and of course NodeJS. So I'd argue it's not essential. All the other things mentioned in the to top comment are far bigger issues IMO.
      - TylerE 3y ago
        [flagged]
        tuckerpo 3y ago
        Why? A submodule can be frozen at a given commit. They're trivially updated or rolled-back, too.
  - BaculumMeumEst 3y ago
    > I'm not so sure a package manager is really all that essential I agree with you, but this is subjective. Not having a package manager will probably turn off many from the language. But it’s OK for the Zig folks to make a call that a lot of people won’t agree with if it doesn’t fit their vision of the language.
- adamrezich 3y ago
  package managers are relatively easy to put together and release with your language—provided that you want your new package manager and surrounding ecosystem to work exactly the same as other, popular ones, without putting any effort into improving the status quo. doing better than other languages' package managers takes significant effort, because it's both a computer engineering problem and a social engineering problem. it's nice when a new language has a package manager right out of the gate, but I would like to see more new languages take a more measured approach and aim to significantly improve upon past efforts, instead of merely replicating them out of some sense of obligation.
- chrsig 3y ago
  > I've lately thought that a package manager is as essential to a new language as a standard library. I would also add a LSP and standard code formatter to that list. Agreed. Especially on a formatter. The number of code review comments it cuts out is incredibly time and energy saving. > It is a bit unfortunate because all of the above is a pretty tall order. We're getting to the point that new languages are expected to boil the ocean by the time they reach 1.0 In order to get into production? yes. there are minimum requirements that must be met. those are higher now than in the past, because of lessons learned the hard way. those problems have been solved (for some value of solved) in existing ecosystems -- a new language wont change the need for them to be solved. it shatters the dream of hacking up something on a weekend and having it turn into a hit success, but it also removes the case of hacking up something in 10 days and suffering the consequences for the next 30 years. Until they have what you mentioned, the languages aren't ready for large scale use -- they need to grow into it. They can be useful prior to that -- enthusiasts and early adopters can reap what benefits are provided. That adoption is what fuels the development of things like a standard code formatter. edit: fixed omission of a unit of time after '30'
  - clessg 3y ago
    > but it also removes the case of hacking up something in 10 days and suffering the consequences for the next 30 years Ha, I thought this sounded distressingly familiar! "In September 1995, a Netscape programmer named Brandan Eich developed a new scripting language in just 10 days. It was originally named Mocha, but quickly became known as LiveScript and, later, JavaScript."
    - erhaetherth 3y ago
      I think JS was somehow salvaged after all that time. The event loop paradigm is lovely.
  - 6keZbCECT2uB 3y ago
    Not sure about lsp, but I think if you defined your language in tree sitter, you might be able to define a basic autoformatter generically on tree sitter to accelerate bootstrapping your language. You could also use an existing language agnostic package manager like nix, guix, or conda to bootstrap your language package manager. Lsp is something I don't know of a way to make that easy without overly constraining the design space.
- johnnyjeans 3y ago
  I disagree. I actively avoid languages that rely on package managers simply because they only give the illusion of being beneficial. It ends up being more boilerplate I have to learn to use an ecosystem, because they don't actually solve dependency hell and now there's a whole additional complicated tool with its own DSL I have to contend with in order to fix what's broken (or even diagnose issues.) The more peripheral crap I have to deal with to use your language, the less I'm likely to use it in the first place. I don't need, want or care to learn yet another idiosyncratic fragile system. Finding source tarballs is a complete non-issue, and inevitably I'm going to have to manually build things anyways to figure out what erroneous assumption a library is making about the underlying system which is causing the build to fail or the runtime to crash, so the package manager just ends up being extra steps. Without fail, that has always been my experience with language package managers. In the pursuit of making things simpler, we're really just making them harder.
  - zoogeny 3y ago
    I'm not sure I understand this issue. The existence of a standard package manager doesn't prevent you from manually vendoring dependencies if you want to. I have personal experience working on node.js projects where several dependencies were just `cp` into a directory and treated like local modules, no npm involved at all. It's like `apt` or `brew` for system dependency management. It is there if you want it but you can just as well download a tar and config/make/install yourself if you want. In many ways, it is like a standard lib. No one forces you to use it. If you prefer the simplicity of your own implementations then I see no reason why you can't just write your own. But when you want the advantages of a package manager, and there are advantages that you may not appreciate but others do, then having a standard one built into the language feels preferable to having a dozen non-standard independently competing variations that the community cobbles together.
    - uranusjr 3y ago
      Furthermore, having a package manager indicates there are some kind of specifications behind so each package and repository has an expected format (not necessarily _a_ standard package manager; in many ecosystems multiple managers share one standard). This helps vendoring a lot since the standard specification makes the vendoring process very easy to automate and validate. Dependency managers in their essence is really just automated vendoring (or vendoring is just less automated dependency management); it helps because you can pick it apart and choose to automate only the parts you want, even if you don’t like the fully automated solution.
- savolai 3y ago
  Would love to understand better what exactly is language specific about package managers? You would think a winner would emerge in this space like one has in version control to be used with all languages, just separate repos for different ecosystems?
  - anon84873628 3y ago
    I was also wondering this. Why does every language need to reinvent the wheel?
  - vineyardmike 3y ago
    Different languages do imports differently. There are different constructs for “exports” and modules and namespaces that prevent a common single directory structure. Pip used to store packages in a global location, now most of python used a Virtual Environment per project. Node uses a “vendor” directory within the project structure. This is probably the easiest case. Go used to store everything globally in the “go path” but now with go modules it does something else. Java doesn’t need source code, just single JAR files, but it needs it within the classpath. C/++ is very flexible, but varied depending on how you build and set up your project. Swift/ObjC requires doing whatever apple wants and dealing with their tooling. Everything is different. If you want “one winner” the closest you get it is the system package manager (of which multiple exist) and pointing your project to its package cache. But not all system package managers handle multiple concurrent versions of the same package. Maybe one day people will standardize against Nix which seems to be the closest?
- paulddraper 3y ago
  > new languages are expected to boil the ocean by the time they reach 1.0 The reason is that there are existing high-quality languages/ecosystems. (Which is a good thing!)
- latchkey 3y ago
  > I've lately thought that a package manager is as essential to a new language as a standard library. This was the approach Ceylon took. Sadly, despite a lot of effort, the language never took off.
- thayne 3y ago
  A lot of what a package manager does isn't really language dependent. It seems like it would be possible to build a generalized package manager that has hooks for a language specific plugin to control how the package is extracted, how to resolve transitive dependencies, and how to do any additional build steps. It would be sort of analogous to how instead of building a full IDE, you can implement an LSP server and get support from existing IDEs and editors.
  - throwaway2037 3y ago
    High level: I appreciate the point being made here. Challenge: If true, why does it not already exist? Idea: Apache Maven repositories use pom.xml to define dependency trees. Why don't these get used more for non-Java'ish languages? Mind you, I am not advocating to use Apache Maven as a build tool. I am noting that (remote) repos and their dependency metadata are a huge achievement in that ecosystem.
    - thayne 3y ago
      > If true, why does it not already exist? Because no has put in the effort to build it and get it adopted. You could also ask why we didn't have something like LSP earlier. In order for such a project to become widely adopted it would need to work well for at least a few popular languages, and work at least approximately as well as the native package management solutions for those languages. And it would need to be easy to use. You can kind of use some existing tools, such as maven, bazel, even npm, for other languages, but it usually isn't as nice of an experience.
JC770 3y ago
I just start to learn Zig,any suggest to beginners?Bro
- hiccuphippo 3y ago
  Other than the main documentation, check ziglearn.org and ziglings.org. Also read the std code, specially the tests when you want to know how to use something.
- sskras 3y ago
  If you learning by doing, I would add these to the @hiccuphippo links: https://zigbyexample.github.io/ https://zigbyexample.github.io/ https://zig-by-example.com/ https://zig-by-example.com/ Their coverage is not very broad (in comparison to eg. Go by Example), but might be enough to get yourself started.
VyseofArcadia 3y ago
I used Zig for a weekend project and loved it, but I am resolved to not use it for anything else until it hits 1.0. I don't have time to write and re-write and re-re-write my code as the language and stlib stabilize.
- Tozen 3y ago
  If that's the thinking, looks like it will be a long wait. Appears to be another 2 to 3 years before 1.0 hits. And it publicly came out in 2016, so add all those years up.
cassepipe 3y ago
To get an idea, what is your programming background ? Are you a C or C++ programmer ?
2h 3y ago
here is this persons GitHub. posting because its missing from their blog for some reason: https://github.com/karlseguin https://github.com/karlseguin
throwaway2037 3y ago
I think Zig falls into an "easy to learn, average/hard to master" Thank you for sharing an insider's account. I naively assume that Zig is not your first language. Regarding "average/hard to master", can you think of any of languages where this is not true? Zero trolling, I promise. My point: No language is any less than average to master. Even VBA has some weird stuff in it that used to catch me off guard when I wrote Excel apps years ago. To be clear, I would classify VBA as similar, but I would classify Python as "easy to learn, very hard to master", and Perl as "average to learn, impossible to master"(!).
cztomsik 3y ago
In my case, Zig was super-simple to pickup, I've been using rust for few years so I was already in the systems programming (as a hobby), and I also had to read some C/C++ during that time, that probably helped me too. Other than that, I was and I am, mostly a frontend developer with ECMAScript and TypeScript experience. I think Zig is very close to both, because Zig has anytype, so you can do duck-typing like you do in JS, and it has programmable type system, just like TS. Not to mention that reflection is basically your daily bread in JS/TS. TLDR: If you have some systems programming experience and you've done a bit of TS, I'd definitely recommend you to give Zig a try. One weekend should be enough. I did that literally single-handed, as I was recovering after wrist surgery.

by latch 3y ago

zoogeny 3y ago

I've lately thought that a package manager is as essential to a new language as a standard library. I would also add a LSP and standard code formatter to that list. It is a bit unfortunate because all of the above is a pretty tall order. We're getting to the point that new languages are expected to boil the ocean by the time they reach 1.0

arp242 3y ago
Zig has a pretty decent LSP. I'm not so sure a package manager is really all that essential; it can certainly be convenient but especially in the space Zig is looking at it's pretty workable without one (without complex deep dependency trees you can use git submodules or just copy a directory). Or let me put it this way: I never really missed a package manager in Zig.
- ReleaseCandidat 3y ago
  > I'm not so sure a package manager is really all that essential; For open source software (libraries or programs, that depend on other libraries or programs), it is essential (if you're not distributing single functions like with Unison). For closed source it doesn't matter that much.
  - arp242 3y ago
    "cp -r ~/some-lib ~/my-project/" works well enough if some-lib doesn't have dependencies on its own. Or git submodules if you want something a bit more fancy. I sometimes do this even for languages with package managers, as it avoids a world of complexity. Obviously a package manager is useful, but Zig is relatively low-level and long dependency chains are much less common than in e.g. Python, Ruby, and of course NodeJS. So I'd argue it's not essential. All the other things mentioned in the to top comment are far bigger issues IMO.
    - TylerE 3y ago
      [flagged]
      - tuckerpo 3y ago
        Why? A submodule can be frozen at a given commit. They're trivially updated or rolled-back, too.
- BaculumMeumEst 3y ago
  > I'm not so sure a package manager is really all that essential I agree with you, but this is subjective. Not having a package manager will probably turn off many from the language. But it’s OK for the Zig folks to make a call that a lot of people won’t agree with if it doesn’t fit their vision of the language.
adamrezich 3y ago
package managers are relatively easy to put together and release with your language—provided that you want your new package manager and surrounding ecosystem to work exactly the same as other, popular ones, without putting any effort into improving the status quo. doing better than other languages' package managers takes significant effort, because it's both a computer engineering problem and a social engineering problem. it's nice when a new language has a package manager right out of the gate, but I would like to see more new languages take a more measured approach and aim to significantly improve upon past efforts, instead of merely replicating them out of some sense of obligation.
chrsig 3y ago
> I've lately thought that a package manager is as essential to a new language as a standard library. I would also add a LSP and standard code formatter to that list. Agreed. Especially on a formatter. The number of code review comments it cuts out is incredibly time and energy saving. > It is a bit unfortunate because all of the above is a pretty tall order. We're getting to the point that new languages are expected to boil the ocean by the time they reach 1.0 In order to get into production? yes. there are minimum requirements that must be met. those are higher now than in the past, because of lessons learned the hard way. those problems have been solved (for some value of solved) in existing ecosystems -- a new language wont change the need for them to be solved. it shatters the dream of hacking up something on a weekend and having it turn into a hit success, but it also removes the case of hacking up something in 10 days and suffering the consequences for the next 30 years. Until they have what you mentioned, the languages aren't ready for large scale use -- they need to grow into it. They can be useful prior to that -- enthusiasts and early adopters can reap what benefits are provided. That adoption is what fuels the development of things like a standard code formatter. edit: fixed omission of a unit of time after '30'
- clessg 3y ago
  > but it also removes the case of hacking up something in 10 days and suffering the consequences for the next 30 years Ha, I thought this sounded distressingly familiar! "In September 1995, a Netscape programmer named Brandan Eich developed a new scripting language in just 10 days. It was originally named Mocha, but quickly became known as LiveScript and, later, JavaScript."
  - erhaetherth 3y ago
    I think JS was somehow salvaged after all that time. The event loop paradigm is lovely.
- 6keZbCECT2uB 3y ago
  Not sure about lsp, but I think if you defined your language in tree sitter, you might be able to define a basic autoformatter generically on tree sitter to accelerate bootstrapping your language. You could also use an existing language agnostic package manager like nix, guix, or conda to bootstrap your language package manager. Lsp is something I don't know of a way to make that easy without overly constraining the design space.
johnnyjeans 3y ago
I disagree. I actively avoid languages that rely on package managers simply because they only give the illusion of being beneficial. It ends up being more boilerplate I have to learn to use an ecosystem, because they don't actually solve dependency hell and now there's a whole additional complicated tool with its own DSL I have to contend with in order to fix what's broken (or even diagnose issues.) The more peripheral crap I have to deal with to use your language, the less I'm likely to use it in the first place. I don't need, want or care to learn yet another idiosyncratic fragile system. Finding source tarballs is a complete non-issue, and inevitably I'm going to have to manually build things anyways to figure out what erroneous assumption a library is making about the underlying system which is causing the build to fail or the runtime to crash, so the package manager just ends up being extra steps. Without fail, that has always been my experience with language package managers. In the pursuit of making things simpler, we're really just making them harder.
- zoogeny 3y ago
  I'm not sure I understand this issue. The existence of a standard package manager doesn't prevent you from manually vendoring dependencies if you want to. I have personal experience working on node.js projects where several dependencies were just `cp` into a directory and treated like local modules, no npm involved at all. It's like `apt` or `brew` for system dependency management. It is there if you want it but you can just as well download a tar and config/make/install yourself if you want. In many ways, it is like a standard lib. No one forces you to use it. If you prefer the simplicity of your own implementations then I see no reason why you can't just write your own. But when you want the advantages of a package manager, and there are advantages that you may not appreciate but others do, then having a standard one built into the language feels preferable to having a dozen non-standard independently competing variations that the community cobbles together.
  - uranusjr 3y ago
    Furthermore, having a package manager indicates there are some kind of specifications behind so each package and repository has an expected format (not necessarily _a_ standard package manager; in many ecosystems multiple managers share one standard). This helps vendoring a lot since the standard specification makes the vendoring process very easy to automate and validate. Dependency managers in their essence is really just automated vendoring (or vendoring is just less automated dependency management); it helps because you can pick it apart and choose to automate only the parts you want, even if you don’t like the fully automated solution.
savolai 3y ago
Would love to understand better what exactly is language specific about package managers? You would think a winner would emerge in this space like one has in version control to be used with all languages, just separate repos for different ecosystems?
- anon84873628 3y ago
  I was also wondering this. Why does every language need to reinvent the wheel?
- vineyardmike 3y ago
  Different languages do imports differently. There are different constructs for “exports” and modules and namespaces that prevent a common single directory structure. Pip used to store packages in a global location, now most of python used a Virtual Environment per project. Node uses a “vendor” directory within the project structure. This is probably the easiest case. Go used to store everything globally in the “go path” but now with go modules it does something else. Java doesn’t need source code, just single JAR files, but it needs it within the classpath. C/++ is very flexible, but varied depending on how you build and set up your project. Swift/ObjC requires doing whatever apple wants and dealing with their tooling. Everything is different. If you want “one winner” the closest you get it is the system package manager (of which multiple exist) and pointing your project to its package cache. But not all system package managers handle multiple concurrent versions of the same package. Maybe one day people will standardize against Nix which seems to be the closest?
paulddraper 3y ago
> new languages are expected to boil the ocean by the time they reach 1.0 The reason is that there are existing high-quality languages/ecosystems. (Which is a good thing!)
latchkey 3y ago
> I've lately thought that a package manager is as essential to a new language as a standard library. This was the approach Ceylon took. Sadly, despite a lot of effort, the language never took off.
thayne 3y ago
A lot of what a package manager does isn't really language dependent. It seems like it would be possible to build a generalized package manager that has hooks for a language specific plugin to control how the package is extracted, how to resolve transitive dependencies, and how to do any additional build steps. It would be sort of analogous to how instead of building a full IDE, you can implement an LSP server and get support from existing IDEs and editors.
- throwaway2037 3y ago
  High level: I appreciate the point being made here. Challenge: If true, why does it not already exist? Idea: Apache Maven repositories use pom.xml to define dependency trees. Why don't these get used more for non-Java'ish languages? Mind you, I am not advocating to use Apache Maven as a build tool. I am noting that (remote) repos and their dependency metadata are a huge achievement in that ecosystem.
  - thayne 3y ago
    > If true, why does it not already exist? Because no has put in the effort to build it and get it adopted. You could also ask why we didn't have something like LSP earlier. In order for such a project to become widely adopted it would need to work well for at least a few popular languages, and work at least approximately as well as the native package management solutions for those languages. And it would need to be easy to use. You can kind of use some existing tools, such as maven, bazel, even npm, for other languages, but it usually isn't as nice of an experience.

JC770 3y ago

I just start to learn Zig,any suggest to beginners?Bro

hiccuphippo 3y ago
Other than the main documentation, check ziglearn.org and ziglings.org. Also read the std code, specially the tests when you want to know how to use something.
sskras 3y ago
If you learning by doing, I would add these to the @hiccuphippo links: https://zigbyexample.github.io/ https://zigbyexample.github.io/ https://zig-by-example.com/ https://zig-by-example.com/ Their coverage is not very broad (in comparison to eg. Go by Example), but might be enough to get yourself started.

VyseofArcadia 3y ago

I used Zig for a weekend project and loved it, but I am resolved to not use it for anything else until it hits 1.0. I don't have time to write and re-write and re-re-write my code as the language and stlib stabilize.

Tozen 3y ago
If that's the thinking, looks like it will be a long wait. Appears to be another 2 to 3 years before 1.0 hits. And it publicly came out in 2016, so add all those years up.

cassepipe 3y ago

To get an idea, what is your programming background ? Are you a C or C++ programmer ?

2h 3y ago

here is this persons GitHub. posting because its missing from their blog for some reason: https://github.com/karlseguin https://github.com/karlseguin

throwaway2037 3y ago

I think Zig falls into an "easy to learn, average/hard to master" Thank you for sharing an insider's account. I naively assume that Zig is not your first language. Regarding "average/hard to master", can you think of any of languages where this is not true? Zero trolling, I promise. My point: No language is any less than average to master. Even VBA has some weird stuff in it that used to catch me off guard when I wrote Excel apps years ago. To be clear, I would classify VBA as similar, but I would classify Python as "easy to learn, very hard to master", and Perl as "average to learn, impossible to master"(!).

cztomsik 3y ago

In my case, Zig was super-simple to pickup, I've been using rust for few years so I was already in the systems programming (as a hobby), and I also had to read some C/C++ during that time, that probably helped me too. Other than that, I was and I am, mostly a frontend developer with ECMAScript and TypeScript experience. I think Zig is very close to both, because Zig has anytype, so you can do duck-typing like you do in JS, and it has programmable type system, just like TS. Not to mention that reflection is basically your daily bread in JS/TS. TLDR: If you have some systems programming experience and you've done a bit of TS, I'd definitely recommend you to give Zig a try. One weekend should be enough. I did that literally single-handed, as I was recovering after wrist surgery.