4 ms·

I think Zig looks very interesting; I just don't do that sort of programming much so I have a hard time finding an interesting (to me) hobby project to try thes

I think Zig looks very interesting; I just don't do that sort of programming much so I have a hard time finding an interesting (to me) hobby project to try these languages on. But I see this sort of sentiment with `go` a lot: > However, I ended up finding these absences liberating — this is where the “fun” comes in. This just feels like a weird "it's not a bug, it's a feature!" Stockholm syndrome. "I actually LIKE that it doesn't do what I want it to do." Baffles me.

flohofwoe 6y ago
The absence of specific features for solving specific problems makes the language surface very small. Which is liberating in the sense that you don't subconsciously look for the "right language feature" for the current coding problem you're trying to solve. This sentence from the blog post is key: "For example, it’s now quite clear to me that Rust is a language which has a dedicated feature for everything." You always have that nagging doubt in the back of the head that you don't know the language good enough yet. And I never got rid of that feeling in over 20 years of coding C++. Turns out, it's not you, it's the language. Switching to a simpler language like C lets you focus on the problem solving again, not solving language puzzles. Zig is truly a "better C" in that sense, because in a way it is an even simpler language than C (while being much more correct), yet it enables fundamental features that C lacks (like comptime and generics).
- afavour 6y ago
  > Switching to a simpler language like C lets you focus on the problem solving again, not solving language puzzles. But you’re solving a puzzle in either case. Either with a solution you created yourself (much more rewarding!) or a premade one you pick off the shelf (higher chance of first time success, often less time involved) Everything is a trade off.
  - flohofwoe 6y ago
    I think libraries are a better place for this sort of code reuse than builtin language features though ;)
    - michaelcampbell 6y ago
      Distinction without a difference. Most of us are talking about "Provided by the language-ecosystem or not", not necessarily WHERE in that ecosystem it sits.
- michaelcampbell 6y ago
  > Switching to a simpler language like C lets you focus on the problem solving again, not solving language puzzles Or, read another way, "with simple language X I have to reimplement the things that language Y comes with" I guess it's all a matter of what level of abstraction one likes to work with. For me, re-implementing a "Set" implementation (eg: go) yet again doesn't count as "productive" just because I'm typing typing typing more more more.
  - flohofwoe 6y ago
    Such things are usually part of the language's standard library though, not part of the language. Important difference IMHO.
    - michaelcampbell 6y ago
      This my point; at least in the past, `go` did not provide a Set implementation. Some people assert that they feel "productive" because of all the typing they need to do to implement it, AGAIN. My stance is that HAVING to do that decreases productivity. I'm mis-quoting, but something Knuth said is to think of it not as "lines written" but "lines spent". I feel that `go`'s recent acquiescence on templates/generics is a bigger version of this, and related to the Stockholm Syndrome I mentioned earlier; this caused much anguish in some, and to me it felt like because having that feature would case people NOT GETTING to type in their bespoke, artisinal implementations of all that stuff that's been solved a million times over. To me that's just baffling.
      - michaelcampbell 6y ago
        (edit, but too late: The quote was by Dijkstra)
59nadir 6y ago
I've spent a fair amount of time learning C++ throughout the years (beginning in 2001) and Haskell. I mention these as examples of languages that seem to have no end to them. Using and learning Zig after about 1.5-2 years is many times more productive because I've already found the edges of the language and I'm able to focus more on my actual task instead of debugging my language knowledge. I say this not only in the context of a work task but for things of every scope. I personally have never felt like I "knew" Haskell, despite working with it and being able to create solutions in it. I know parts of it and there are big parts of it looming somewhere in the distance. There are language extension names that actually give me anxiety when I see them at the top of source files. I think the same feeling is common in C++ users, though admittedly I don't have my finger on that pulse anymore. Is it possible to create finished solutions that are shorter and where your solution seems to fit the problem more directly in these languages? Yeah, I guess, but at the same time I'm not sure it's ever finished and the anxiety this kind of thing can cause when using these languages I think is underestimated. There's a tension that this creates where you have to intentionally limit yourself (and suggest others to limit themselves, see "Simple Haskell") because you feel the weight of all of this complexity on you constantly. "Maybe if we read this 'Thinking in Types' book we can cut down on the amount of lines in our code base, guys?". Meanwhile people using intentionally small languages are provably super productive and you see a lot of coping mechanisms in the communities with these ever-growing colossi languages. (With all of this said I'm not entirely sure I'd be sold on Zig if it didn't at least have tagged unions and matching/unpacking of them via `switch`. There are language features that I've grown so accustomed to that I feel like I can barely program without them.)

flohofwoe 6y ago

The absence of specific features for solving specific problems makes the language surface very small. Which is liberating in the sense that you don't subconsciously look for the "right language feature" for the current coding problem you're trying to solve. This sentence from the blog post is key: "For example, it’s now quite clear to me that Rust is a language which has a dedicated feature for everything." You always have that nagging doubt in the back of the head that you don't know the language good enough yet. And I never got rid of that feeling in over 20 years of coding C++. Turns out, it's not you, it's the language. Switching to a simpler language like C lets you focus on the problem solving again, not solving language puzzles. Zig is truly a "better C" in that sense, because in a way it is an even simpler language than C (while being much more correct), yet it enables fundamental features that C lacks (like comptime and generics).

afavour 6y ago
> Switching to a simpler language like C lets you focus on the problem solving again, not solving language puzzles. But you’re solving a puzzle in either case. Either with a solution you created yourself (much more rewarding!) or a premade one you pick off the shelf (higher chance of first time success, often less time involved) Everything is a trade off.
- flohofwoe 6y ago
  I think libraries are a better place for this sort of code reuse than builtin language features though ;)
  - michaelcampbell 6y ago
    Distinction without a difference. Most of us are talking about "Provided by the language-ecosystem or not", not necessarily WHERE in that ecosystem it sits.
michaelcampbell 6y ago
> Switching to a simpler language like C lets you focus on the problem solving again, not solving language puzzles Or, read another way, "with simple language X I have to reimplement the things that language Y comes with" I guess it's all a matter of what level of abstraction one likes to work with. For me, re-implementing a "Set" implementation (eg: go) yet again doesn't count as "productive" just because I'm typing typing typing more more more.
- flohofwoe 6y ago
  Such things are usually part of the language's standard library though, not part of the language. Important difference IMHO.
  - michaelcampbell 6y ago
    This my point; at least in the past, `go` did not provide a Set implementation. Some people assert that they feel "productive" because of all the typing they need to do to implement it, AGAIN. My stance is that HAVING to do that decreases productivity. I'm mis-quoting, but something Knuth said is to think of it not as "lines written" but "lines spent". I feel that `go`'s recent acquiescence on templates/generics is a bigger version of this, and related to the Stockholm Syndrome I mentioned earlier; this caused much anguish in some, and to me it felt like because having that feature would case people NOT GETTING to type in their bespoke, artisinal implementations of all that stuff that's been solved a million times over. To me that's just baffling.
    - michaelcampbell 6y ago
      (edit, but too late: The quote was by Dijkstra)

59nadir 6y ago

I've spent a fair amount of time learning C++ throughout the years (beginning in 2001) and Haskell. I mention these as examples of languages that seem to have no end to them. Using and learning Zig after about 1.5-2 years is many times more productive because I've already found the edges of the language and I'm able to focus more on my actual task instead of debugging my language knowledge. I say this not only in the context of a work task but for things of every scope. I personally have never felt like I "knew" Haskell, despite working with it and being able to create solutions in it. I know parts of it and there are big parts of it looming somewhere in the distance. There are language extension names that actually give me anxiety when I see them at the top of source files. I think the same feeling is common in C++ users, though admittedly I don't have my finger on that pulse anymore. Is it possible to create finished solutions that are shorter and where your solution seems to fit the problem more directly in these languages? Yeah, I guess, but at the same time I'm not sure it's ever finished and the anxiety this kind of thing can cause when using these languages I think is underestimated. There's a tension that this creates where you have to intentionally limit yourself (and suggest others to limit themselves, see "Simple Haskell") because you feel the weight of all of this complexity on you constantly. "Maybe if we read this 'Thinking in Types' book we can cut down on the amount of lines in our code base, guys?". Meanwhile people using intentionally small languages are provably super productive and you see a lot of coping mechanisms in the communities with these ever-growing colossi languages. (With all of this said I'm not entirely sure I'd be sold on Zig if it didn't at least have tagged unions and matching/unpacking of them via `switch`. There are language features that I've grown so accustomed to that I feel like I can barely program without them.)