It's an interesting point. My experience with it, though, is that if the language is too simple, the complexity gets pushed off into the application. The result is "boilerplate", a lot of code that gets routinely cut&pasted into applications.

The thing about complexity in the language, on the other hand, is once you do learn the language, that skill follows you with every app you work with. With complexity pushed to the app, you have to re-learn it with every app.

A screwdriver can do a lot of things - chisel, hammer, scraper, prybar, punch, paint stirrer, shim, etc. But I prefer having a set of tools designed to be chisels, hammers, etc. My projects come out a lot nicer.

This is a frequent complaint I hear about Go: they made the language too simple in certain places. People also tend to cite Rich Hickey's distinction between "simple" and "easy".

So the question about Zig becomes one of what exactly was kept simple, and what was allowed to become complex?

I think the world would benefit from a Hyperpolyglot-style comparison here. Rosetta Code is too much of a mess; ideally, I want to see a thoughtful side by side comparison of the same program written in several languages, with commentary.

And with respect to discussion of boilerplate, you can, of course, always have a "Zig++" language that patches over Zig. By cutting out its own metaprogramming functionality, it's much more straightforward to generate useful Zig source. There are a lot of advantages to restraint in the design, and Go does share that, too.

You can use a style in D that is even simpler than Go if you want, but it's nice to have the extra features for the times that they're handy. Just because the features are there doesn't mean it's a good idea to use them - and D allows you to program that way.

Even in a two person project, one person using a language feature will inadvertently force the other person to learn how that feature works. And they will not even know if the feature was appropriate to use until they have learned it.

With this small amount of reasoning we are back to the tired old argument of "Which is better? Ease of expression or ease or learning?"

Even if true, so what? "Personal projects" don't count?

But honestly, this is one of the worst programming language arguments there is. Any feature can be misused. There has to be discipline - full stop. Restricting the language is not the answer because that just leads to worse code, not better. Decades of C code demonstrates that lack of features does not translate into good programming practice.

That's more or less the reason I too don't find "multiple people projects may have problems with discipline" to be a good argument for anything. That's a culture issue and pretty much orthogonal to any technical factor of your environment, including the choice of programming language.

True, but the same is true of Go, which may be surprising to people. Despite its claims, Go didn't solve this problem.

One reason is that larger projects typically start to invent their own abstractions on top of the base language and Go is no exception here, in fact, what with its lack of some common abstractions, built-in support for code generation, frequent use of external add-ons (like go vet etc.), Go very much encourages this. And so you're going to have to learn specifics of larger projects just like with "complex" languages. The solution to this problem is meticulous and somewhat restricted code style standard, but that's a solution that works with "complex" languages just as well, in fact, I'd argue that even better.

The other reason is that the Go language is not just the Go language. That is, what with the lack of abstractions for error handling, code re-use, etc., people end up following a bunch of conventions, styles, patterns and using external tools (like the already mentioned go vet). And so in effect the language becomes "the base" + "lore". This is of course true of any language. With Go and early Java, for example, this becomes more pronounced, since the base part is very small, larger parts need to be taken care of by the "lore". This is why Design Patterns become so popular in the Java world. And this why it's not good to have the base part too small, which is the problem of Go. Of course, the other extreme is equally bad - that is, when the base part is too large, which is the problem of C++, where now "lore" has to take care of deprecating/removing language features.

I feel like the authors of Go decided to do the opposite of what C++ does and thought that since C++ is horrendous, doing the opposite would yield a great result. But unfortunatelly that's not the way things work. You can't just negate someone's bad approach and expect great results.

Then again, you are perhaps making a decent argument for using simple languages in multi person projects!

So yeah. I love feature-rich languages, but caution is prudent, and I can understand why Perl or D or what have you might be too feature-rich.

Consider the Go vs D comparison. D has good support for templates. Occasionally, templates are a big help, so every once in a while you should use them. In those cases, if you're writing D, you add a templated function and everything is concise and readable. In Go, you do one of several things, none of which is concise and readable. Future you will thank you for using D and taking advantage of it's features.

Features support the writing of disciplined code. Lack of features forces hacks, duplication, and crazy workarounds. The latter is what you're seeing when you look at ugly Perl code.

That's not to say that C crypto libraries don't suck for other reasons (I've used OpenSSL, I can't really defend that) but the language itself limits what you can do, in the standard library or otherwise. I mean, look at the many flawed or error-prone interfaces in the C standard library itself, I don't think stdcrypto.h would be the panacea.

There's a ton in Java, C++ and C#. One example in C is the proton implementation of AMQP.

An intro to one ingredient of the magic of D metaprogramming, compile-time function evaluation:

https://tour.dlang.org/tour/en/gems/compile-time-function-ev...

An example of the kind of introspection available in the D stdlib:

https://wiki.dlang.org/Finding_all_Functions_in_a_Module

This one's really cool, a library that lets you build an entire grammar of your choice and evaluate it at compile time:

https://github.com/PhilippeSigaud/Pegged

Nim's metaprogramming seems quite similar, and I sometimes wonder if perhaps it took some inspiration from D.

Lets you call top-level funtions as if they were metnks, with the receiver as the first argument.

For example, these two are equivalent:

    add(x, y)
    x.add(y)

Sorry, potentially stupid question incoming: I thought this was pretty standard for c++ optimizing compilers. What makes D's version of this special?

C++ has this with constexpr, but it's not as rich in terms of things that it can do. In D, IIRC, pretty much anything goes.

That being said, C++ template metaprogramming can be pretty elegant[1] (there was a video where she describes the template functional style, but it seems to have been deleted).

[1]: https://github.com/hanickadot/compile-time-regular-expressio...

https://en.cppreference.com/w/cpp/language/constexpr

https://dlang.org/spec/function.html#interpretation

No destructors means no smart pointers – and Zig doesn't seem to have a garbage collector, so I guess you need to free() things manually.

No operator overloading means, among other things, no custom numeric-like types – including wrapper types for units (e.g. Feet) unless the language provides separate support for those (e.g. Go does, Zig seemingly doesn't).

comex just noted that the design decision here has some tradeoffs. One of those tradeoffs is that you can't define wrapper types for units. Such a feature has clear use cases - it's not hard to find instances where unit conversion bugs have had severe consequences. "Most languages survived without that" is not a constructive comment.

Operator overloading is often misused and violates the principle of minimal surprise. You could even have side effects.

Still, type safety is totally possible. In Go, of your unit is Feet, you wrap your int into Feet and you cannot sum it with anything but feet. And that's all compile time, no cost.

Huge successful current languages don't have operator overloading now either. If anything, outside numerical/scientific work, it's even frowned upon.

And even in languages that do have them, it's not like people usually work with typed feet and such units. It is indeed safer, but I'm not sure it's mainstream (F#, Ada, Rebol, etc). Of course one can find such typed unit libs for other languages with Op. Overloading (C++ eg. has boost.units), but it's not like they're mainstream even where Operator Overloading is available.

In any case, it's not the first argument to make against a system language that it doesn't support Op. Overloading as a means for this use case.

In C++, if there weren't automatic destructor calls, you could still clean things up manually with a pseudo-destructor call, x.~T(), where T is the type of x.

In C, there are no (user-defined) generics, so you always know the concrete type of x, so you know whether it needs to have a destructor called and what the name of that destructor is.

In Zig, how would generic code create an instance of a generic type T that may or may not need to have a destructor called, ie. how do you know if you need to use defer and what the deferred expression should be? How would tooling be able to check that destructors were called if there is no special way of marking that a destructor exists?

I'm not sure how to reconcile this statement with the following claim from the linked article: "Zig has no macros and no metaprogramming yet still is powerful enough to express complex programs in a clear, non-repetitive way." Not only does it claim that Zig has no metaprogramming, it suggests that it sees metaprogramming as undesirable.

  fn max(comptime T: type, a: T, b: T) T {
      if (T == bool) {
          return a or b;
      } else if (a > b) {
          return a;
      } else {
          return b;
      }
  }

> You can always add a no-op dealloc method to your type if you want a generic function to handle it correctly

You're looking at it from the perspective of the generic consumer, not the generic author. The generic author generally does not have the ability to edit the type. Plus there are many types that do not have methods at all (integers, points, etc.).

> Moreover, Zig has awesome metaprogramming support so you can probably think of a way to check the type parameter for a dealloc method and only generate the dealloc call for those types.

Yes, you can detect and call a method called deinit that has the appropriate signature using @reflect. You can even put this in a function and call it a pseudo-destructor. But there's no guarantee that deinit has the actual semantics of a destructor without some kind of language-level agreement between class authors.

This will work fine. Do you have a more specific example?

To answer my question, no, they're not deinited. All deinit does is call self.allocator.free on the slice of elements, and for many allocators that's a nop. In fact none of ArrayLists methods take any kind of ownership of its elements. If you shrink an ArrayList(ArrayList(i32)) by one you leak the last ArrayList(i32). None of the methods call destructors on the elements because there is no generic notion of a destructor, only particular ad-hoc ones like deinit methods. ArrayList appears to solve the problem I mentioned above about generics not knowing if a generic type needs to have a destructor called by only supporting types that don't.

In C++, you'd write the function that clears a vector something like

    void clear() {
        for (auto p = ptr; p != ptr + len; ++p) {
            p->~T();
        }
        len = 0;
    }

I believe what he was wasking was "given an ArrayList(i32), how would you expect it to call deinit on the member i32s?". The answer, of course, is that you don't, which is also true of ArrayList(ArrayList(i32)). ArrayList absolutely supports heap-allocated types, you just have to free them yourself before calling deinit() on the ArrayList itself.

But if you did, you could use `@TypeInfo` to inspect the inner type for a function named `deinit`, or some other criteria that made sense for this determination.

I already mentioned that hack. All you're doing there is introducing the ad-hoc notion of a destructors as a method named deinit. Again, in order for that to work in generic code that convention needs to be blessed by the language.

Technically it only needs to be blessed by the standard library in this case.

C has had generics since C11. I’ve got a clone of “the good parts” of the std C++ template library (vector, unordered_map, ...) laying around somewhere.

    _Generic(x, type : value, ..., [default : value])

You usually wrap the call to '_Generic' in a macro. For instance:

    #define vec_push_back(vec, val) \
        _Generic(&vec, \
        vecint : vecint_push_back, \
        vecdbl : vecdbl_push_back, \
        default : assert_vwrap)(&vec, val)

The nice part, over C++, is that the generic instantiation is localized to a single translation-unit file, so you don't have to yell at the junior devs for instantiating templates without using an 'extern' construct.

For local variables, I'd say `defer` is an okay but not great substitute. If you call malloc() yourself, then sure, it's not hard to remember to stick a "defer { free(ptr); }" afterwards. But what if you call a function that returns an owned value? Can you tell just from looking at it that you're meant to free the thing afterward?

CoreFoundation, a C library on Apple platforms, has a cute solution to this: a strict naming convention. [1] If a function returns a value at "+1" reference count, i.e. you have to release it yourself, the function's name should include "Create" or "Copy", even where that would otherwise seem unnatural. For example, "CFSocketCopyAddress" returns a socket's address as a CFDataRef, returned at +1. You might expect it to be called "CFSocketGetAddress", but "Get" is reserved for functions that return values at +0.

As I said, cute – but fundamentally a workaround for language limitations. Distinguishing between two kinds of functions is exactly the sort of menial bookkeeping that computers excel at, whereas humans are prone to making mistakes. And – while CoreFoundation is forever stuck with the goal of C compatibility, Objective-C, which used to rely on a very similar system of manual retain/release and naming conventions, did ultimately transition to automatic reference counting.

But it doesn't have to be automatic. One use for destructors is to automatically release locks, and an interesting alternative design for that exists in Clang's "thread safety" annotations. These are annotations you can add to existing C or C++ code that uses mutexes; their main purpose is to catch you if you access a variable protected by a mutex without owning the mutex, but they can also complain if you lock something and forgot to unlock it. You can annotate functions as "requires mutex" (i.e. you must call it with the mutex locked, and it stays locked after the function), "acquire" (call with it unlocked, returns with it locked), "release" (the opposite), and so on. I think I once tried to abuse the annotation system to enforce reference counting, but it was broken. But I'd love to see a more thorough and robust design along these lines.

[1] https://developer.apple.com/library/archive/documentation/Co...

Note that this is also true of Rust. Programs build using `no_std` and `libcore` don't have an allocator. A surprising amount of functionality is still available, like sorting and string splitting.

There are discussions about implementing something similar in Rust, but it doesn't exist yet...

[1] https://ziglang.org/documentation/master/#Hello-World

    const std = @import("std");

    pub fn main() !void {
        // If this program is run without stdout attached, exit with an error.
        var stdout_file = try std.io.getStdOut();
        const stdout = &stdout_file.outStream().stream;
        // If this program encounters pipe failure when printing to stdout, exit
        // with an error.
        try stdout.print("number: {}\n", i32(1234));
    }

  const print = @import("std").print;

  pub fn main() void {
      print("Hello, world!\n");
  }

  pub fn main() !void {
    try print(...)
  }

    pub fn warn(comptime fmt: []const u8, args: ...) void {
        const held = stderr_mutex.acquire();
        defer held.release();
        const stderr = getStderrStream() catch return;
        stderr.print(fmt, args) catch return;
    }

This tradeoff is not appropriate for stdout.

Also the decision to use the mutex is not appropriate for stdout. The application may be single-threaded, or have its own synchronization strategy that makes the mutex redundant.

Zig is optimal.

This trade-off is not self-evidently correct... it's easily boiled down to personal preference. Consistency would be nicer. Zig is not "optimal" just because someone says it.

So, suppose warn() fails. What can you do about it - try to print a warning that you can't print warnings?

If you want something different, use a library or some other parts of the stdlib. Making that super common use case painful is not obviously a good decision.

The super common use case is std.debug.warn, not printing to stdout.

I would actually even argue that the meaning of "print" as printing to stdout by default is an unfortunate historical artifact. For the kind of stuff print is usually used by most of the code, it really should go to stderr, and "print" kinda implies some kind of logging IMO.

From that perspective, my suggestion would be to add a no-failure @import("std").debug.print that is an alias for warn. I don't think it's likely that breaking the established convention of print-defaults-to-stdout would cause issues in practice - in programs where this matter (like cat), the developer will quickly discover the issue the moment they try using it in a pipeline. And for programs where it doesn't, defaulting to stderr is actually the right thing.

But if you'd rather not break the convention, how about adding debug.log that is an alias for debug.warn? Or debug.say, or something like it.

stderr is the one that is not likely to be redirected somewhere that might fail - that's the whole point of keeping it distinct from stdout! And if it does get redirected, than the person that is requesting redirection is responsible for ensuring lack of failures in that channel.

I think you're approaching this from the perspective of stdout as a place for diagnostic output. It's not - it's a place for actual output (i.e. a function of program's input - the useful result of its operation). Yes, in practice, people routinely use it for diagnostics, but that's exactly the problem that Zig is trying to fix here by being opinionated about it, so far as I can tell.

When developing, "print" is more commonly used as an aid for the developer. Most "print" messages should either be removed or outsourced to a library when the program nears completion. "warn" fills a similar purpose as "print".

If you really want "print", a small function that writes to stdout is quick to write.

Quoting the docs linked above:

> Usually you don't want to write to stdout. You want to write to stderr. And you don't care if it fails. It's more like a warning message that you want to emit. For that you can use a simpler API:

    const warn = @import("std").debug.warn;
    
    pub fn main() void {
        warn("Hello, world!\n");
    }

A while ago, I tried to figure how how to do the equivalent of C's

    int n = 42;
    printf("n = %d\n", n);

https://github.com/ziglang/www.ziglang.org/issues/15

If you classify all C-programs by what output they use (multiple counts allowed), printf/puts shows up with the highest percentage long before ncurses, X or anything else.

Granted, I'm dyslexic and apparently dyslexia only affects characters which are phonetic. This has also been my experience and I love Chinese characters in Japanese text because it's much more comfortable for me to read. So that's why I might prefer symbols.

I'm wondering, though, why people dislike symbols (and I know it's a very common thing). It's just like any other letter, except that it has a meaning. I wonder, it is because it's hard to read phonetically (just the opposite of my problem)? Whenever I've asked people they say "Symbols are ugly", which is kind of an unhelpful response. It's like saying, "I don't like it because it is unlikable". I hope someone has a slightly deeper insight into the reasons.

Once I've learned the language and internalized the semantics they mostly fade away, except in cases like C++ where you get multiple asterisks and whatnot.

I'm not the above poster but I also dislike the symbols usage I've seen in Rust. I'm on mobile so I can't show examples (and I don't know the language at all) but it has the same smell as symbols in C++ though not as bad. Like character silhouettes in Team Fortress 2, symbols need to appear distinct. Chains of them should be limited. My first impressions of Rust felt like the symbols or operators were less than ergonomic. Small or blending together.

Disclaimers about preference, solo vs team, personal vs enterprise, APL vs La-Z-Boy.

The more symbols, the harder it is to unpack the code into (and restate in a) human language. Even in your head. IOW, if you're mostly monoligual, and you think about code in English (or whatever your preferred language is), more symbols can actually make it harder to think about the code.

Trivial example: a = a+b is slightly easier to say (and think) in English than a += b

I read this as “the more symbols used, the more it looks like mathematics”. I guess this is really a matter of personal taste :)

Native English speaker here.

"+=" is pronounced "plus equals", meaning that you've got it backwards, with the margin being by the number of mental syllables taken by a - though if a really is "a", then that's only 1.

However, the above considerations only cover recitation.

Comprehension, especially in real-world scenarios, is another matter entirely. "a" might be some other, longer name (and probably amongst a set of long names with a common prefix/accessor). When I read "a = a + b", it takes me some amount of effort to verify whether the lvalue is in fact the same word as the lhs of the operator. When I read "a += b", that effort is not needed. The difference again is proportional to the length of a.

Most people can detect noise and arbitrarity. But if you are making something really original, giving you are being a pioneer into something, in that case you can define the direction of something, where that direction should serve as a guide to things that will follow.

I dont know about others, but my brain tend to be anti-noise (and i fell this pattern in a lot of other people too), because theres too much information for us to consume, that having to handle some people "cheating" to give a apparent originality, can make anyone who feel its the "noisy arbritrary sort of change" that is being presented, to dislike the "noise" almost immediatly.

Technology should be aiming toward zen-budism, less ego and therefore, less disonesty and less noise.

To be fair, some of these are in Zig too, such as &.

Your "horror example" is actually very readable for most programmers familiar with either Java, C# or c++, I think. In java or C# it would be something like

    T largest<T>(T[] list)

I love the fact that it's obvious where macros are being used.

_, => and () are originally from ML, so I know it from my university days, but these days you also find some or all of them in C#, Java, Kotlin, ES6. So a lot of programmers have already been exposed to them.

* :: is the same as in many other languages

* & too

* ! is unique, I guess

* The format string stuff is based on ... C#/Python stuff? I forget exactly.

* _ => () is composing three other bits of syntax that aren't unusual on their own

* <> is genrics, like in many languages

* [T] is slices, which are not entirely unique but are also similar to array stuff which uses []s

Thanks for elaborating, it's helpful to understand the perspective.

It also has less or equal amounts compared to other languages, of course, but I dislike that aspect of those languages too :)

Compare these two listings:

http://rosettacode.org/wiki/Stack#Simple_implementation

http://rosettacode.org/wiki/Stack#Nim

You can see directly that Rust has a lot more there. Obviously Nim skips out on braces so that's a gimme, but I don't really count block braces when I'm talking about special characters. It's more stuff like Option<&'a Frame<T>> or &'a mut T or ->

Yeah, thanks, I think this is at the root of a lot of it.

> It's more stuff like Option<&'a Frame<T>> or &'a mut T or ->

Yeah; some of the stuff isn't needed anymore; you can drop the : 'a s, for example. And we have been talking about allowing some more elision, so

  pub struct Iter<'a, T: 'a> { 
      next: Option<&'a Frame<T>>,
  }

  pub struct Iter<'_, T> { 
      next: Option<&Frame<T>>, 
  }

I want to say I like you how you guys develop in the open and how you in particular are out and about in the discussions here.

Also, can you make a post someday about your experience with WSL?

Could you expand on this, I don't quite know what you mean, but I'm interested!

> I want to say I like...

Thanks!

> your experience with WSL?

My experience was, "This is pretty cool!" but, in the end, I don't use WSL anymore and just use regular old Windows. I can elaborate more if you'd like, but it boils down to "basically everything has windows native versions anyway and it works a bit better that way."

    a::b::c::<T>()?  // Rust
    try a.b.c(T)   // Zig

The :: and <> are also not particularly unusual syntax for their respective features either.

You asked what bothered us, not what was unusual :)

I've just started working in Rust and found it to have the right number of features compared to C++.

> Zig has no macros and no metaprogramming

but then in another place about zig[1]:

> Compile-time reflection and compile-time code execution

This does sound arbitrary more complex than macros (and is what actually got me interested in zig).

[1] https://www.patreon.com/andrewrk

* https://github.com/bluenote10/nim-stringinterpolation/blob/m... This one does string interpolation and a printf-like syntax with compile time type checking. It does call out to C but only after it's already parsed and validated and transformed the format string.

* https://github.com/kaushalmodi/strfmt/blob/master/strfmt.nim This one implements a more complex string formatting syntax with lots of convenience functions. It's more complex but provides a lot more functionality than the previous one without relying on FFI.

I'm not a Nim programmer but I imagine those two demonstrate how Nim metaprogramming works even if neither exactly duplicates the behavior of printf.

I bit hard to follow without the syntax highlighting, but seems a good example of what a larger application would look like.

Also here's a game: https://gitlab.com/dbandstra/oxid/

For production code I have learned to choose programming languages that are first class citzen in the platform or libraries that are required for a given project.

While it might seem boring or outdated, it is much more productive and future proof than picking the language and then sort out how to integrate them.

What I do know is that it's one of precious few things in software that I still find interesting enough to bother [0]. I'm guessing part of the answer is that this is where you end up sooner or later.

And then we have the internet, which is a big part of the equation. It's easy to get numb, but I remember a time when information about implementing interpreters/compilers was VERY hard to come by.

It's all good from my perspective, we're barely scratching the surface of what is possible and there are plenty of good ideas left to rediscover in our history.

But I do wish that more designers would dare to step outside of the box more. Creating a language isn't about cherry picking features from existing languages, it's about finding better ways of solving problems.

[0] https://github.com/codr4life/snabl

The barrier to entry is higher, the expectations on the size of the standard library are higher, the expected quality of tools is higher.

(I say this as just an observer, having written interpreters but no compiled languages.)

Maybe, maybe not, but luckily that question's not very important. Here's what is:

Where is the cleverness and beauty in Yet Another Boring LLVM Frontend(tm)? Zig and Rust are more than that, I'll readily grant - but that description does fall under the umbrella of "implementing a language".