What is the status of async with Zig?

I agree and I think it also just isn’t true (there are many more niche languages that do interesting things BQN, red, idris, roq, …), while there are plenty of old things that get rediscovered over and over again, I think that is somewhat natural because people learn through rediscovery, at least that has been true for me and I think a good way to acquire deep understanding about something, is to try and build it.

And that will involve making plenty of mistakes. you need to learn from and improve upon with later revisions, thinking you know everything now (or that there aren’t any new ideas) would become a self-fulfilling prophecy, because it would blind you towards some new ideas that you haven’t considered yet and seeing the value those ideas provide. (Just like some assembly programmers didn’t see the value in using C, some C programmers won’t see the value in using a language with actual modules etc. and so on) (And that can happen with every feature)

There are things about Go I disagree with and Zig seems more aligned with what I want from a language, but I still think Go is a good language that has evolved over the years and has created a combination of tradeoffs that make it more interesting then for example C++. (Which in my opinion lacks vision, clarity and focus)

Everyone will see the value of specifc languages differently and whether those solve things that are interesting to that individual, but I think it is good to stay open minded and realize that what you care about may not be what others care about.

Some want just a very ergonomic language that gives them every feature they want and that is a legitimate want, it just is something that Zig currently doesn’t give people who want a lot of features. Some other languages give you lots of features but also are implemented in a way that it would be difficult to learn, understand and change those implementations. My personal interest is in languages that are fairly minimal, because ideally I want to understand its implementation also and able to change or work on it.

I think it is good if a language can provide and give you lots of features, I just don’t want the language to take the easy route of “lets create a bloated language implementation so that we can provide lots of features”.

Having a small core of a few features that can be used for many things, is what makes the language and its implementation understandable and I think that is important for a good language, so that many people are able to understand the language and become contributors to it.

That doesn’t mean that certain things should never become full language features, it is more about what kind of additional complexity those features add to the language and whether this cost is low enough, or the feature is important enough and aligns with the goals of the language.

While many ideas have been tried, some of those ideas have only been tried in obscure languages that not many people have used, for example Icon’s and Unicon’s goal directed evaluation is an interesting concept that I haven’t seen in that way in other languages (Prolog/Datalog seems conceptually most similar and still quite different)

I guess my point is we shouldn’t get to entrenched in one way of thinking that other ways are never considered again, this talk makes it seem as maybe we tried more different things when we (as programmers) were still just playing around and figuring stuff out, instead of thinking of ourselves as people who know what they are doing (which we still often don’t):

I think it is important to keep that spirit of “what would happen if we did some things in a totally different way?” alive, the curiosity and joy that it enables alone are already great, but we may even find some really different ways to do things.

7 Likes