> value in Zig is its simplicity

IMO, there are things Zig just don’t care about, which in the surface makes it simple but its annoying and burdensome later on.

  * Manual interface implementation
  * Internals of a struct is public
  * No string types
  * anytype requires reading code
  * Error can’t carry information
  * The iteration abstraction in the std is all over the place
 * Unused declarations is compilation error

I resonate with you about interfaces and a String type. At least these two are so prevalent even on the simplest of programs to warrant some proper language and std lib support.

> For me the value in Zig is its simplicity as a language

I was reading an article about rust posted here yesterday and i realized: i have no clue what is going on in this code (also i presume "templage" is a typo):

    #[derive(Debug, Default)]
    pub struct Context {
        authed: bool,
    }

    #[derive(Template)]
    #[templage = "layout.jinja"]
    struct HomeTemplate {
        ctx: Context
    };

    pub async fn home() -> impl 
    IntoResponse {
        HtmlTemplate(
            HomeTemplate { ctx: 
    Context::default() }
        ).into_response()
    }

Looks like a small request handler for an HTTP framework using a page written with the jinja templating engine. I'm a bit rusty (pun intended) so I can't immediately place which HTTP framework that is though.

You're correct and the HTTP framework looks like Axum.

i mean i got that part :). my best guess is that the async function is some sort of factory? why you would need a factory to be async i have no idea.

Yes, while macros simplify some tasks, they also make it harder to really understand the code. Well, technically they hide the code in most languages as they're metaprogramming done in a separate language.

I love Rust and do some advanced code sometimes, but very rarely have I created a macro. I still see it more or less like "magic" that "super-human" library developers master to make their life easier. Typically not my use case.

This is another advantage of Zig. As you may know, metaprogramming in Zig doesn't use any special syntax, but rather the Zig language itself. This is often known as comptime and while not necessarily easy to grasp, as you're reasoning about compile time stuff, at least it's done in pure Zig.

to be fair you can generate a type in zig using a function that results in kinda obscure methods etc. i do think zig devs shy away from that kind of patterm though.

I personally think that the discovery of rust API is awfully as soon as macro is involve. It's impossible to know what argument is taken by macro. For example the "simple" `println!`, without example in the docstring it's impossible to guess what are the argument even when we have an IDE that show you the implementation.

Having skimmed it, I had the opposite reaction, the wording is clunky in a way that I haven't seen LLMs do, it feels very human to me.

Stuff like

> Also the learning curve for Zig can be steep, especially for those unfamiliar with low-level programming concepts.

I don't think an LLM would start a sentence with "also" like that

> The small and simple syntax is an important part of the maintenance, as it is a goal of the language to allow maintainers to debug the code without having to learn the intricacies of a language they might not be familiar with.

The wording here feels like someone who's a fan of Zig taking a sentence praising Zig's design and trying to rework it into a slightly more neutral encyclopedia style.

> Other challenges mentioned by the reviewers are interoperability with other languages…

This sounds exactly how llms have made comparisons for me. What reviewers?

Those points are taken from the article in the reference at the end of the sentence, it's just someone rewording a blog post.

“Someone rewording a blog post” is exactly the tone of an LLM summary.