Do you not like those because they're unfamiliar? What about the syntax indicates over-engineering?

Here's what I see in your example:

- @ indicates built-in function, which avoids namespace collisions.

- Optional types via the ?, which solves the null pointer problem.

- Real iterators, which are less error-prone and nicer to read than traditional for loops in a lot of common applications.

- The || syntax is better than something like `for (type var : array)` in Java, don't you think? Especially since it works with any iterator?

- anyerror!void is a nice way of saying that the function can return an error. Remember that we don't have exceptions here.

- It has interoperability with (multiple standards of) C.

- Error handling is higher-level and less error-prone than in C without exceptions that can create hidden jumps in your code.

So it clearly solves issues that people run into frequently in C. It brings in a nice sampling of high-level language features without doing anything that would compromise its niche as a systems language. It still has manual memory management and does not have exceptions. The behavior is simpler and requires that you language-lawyer the specification for undefined behavior far less often than in C. Your knowledge of C isn't necessarily enough to be able to immediately read Zig code, but that's because Zig isn't C. It's not hard to learn.

Thanks for spending your time explaining this. I think a lof people will understand those lines better.

I actually already knew everything. I watched closely the development of Zig, and just give up when I realized all those decisions where made carelessly in my view or I just simply disagree with the direction of the syntax.

Since you took your time I will take mine to address what I don't like:

- There is no way to write "int" by default. I understand why. But I don't agree.

- struct and enum statements (within braces) are separated by a comma which is inconsistent with statements in function separated with ",". In my view expect a difference between parameters and statements. parameters (a,b,c) statement {a;b;c}

- You have to type "var" or "const" everywhere, but not in struct statement and enum statement. Sometimes it's like a "def" sometimes not.

- You have to type const when importing module:

  const std = @import("std"); // Why ? Why should I specify const, this should be inferred. Same when I define a struct. 

- the "undefined" keyword when it means "uninitialized" even in the documentation.

  var my_var: i32 = undefined;

- The worst, no default values for struct.

- The list of keywords is insane: errdefer, allowzero, orelse, unreachable, anyerror

- About iterator I was doing well with:

  while(get_next(context,  &item)) { /* ... */ }

It's like everything has been carefully design to be even less readable than C code. I have the feeling that the syntax help more the compiler than de developer.

I wish I could bet thousands of dollars that there will be only one compiler in the whole life of Zig language (also because it relies way too much to LLVM).

> It's like everything has been carefully design to be even less readable than C code.

D is designed to be very readable to the C programmer. Some changes, like replacing:

    (int)(expression)

with:

    cast(int)(expression)

is designed to make the code more readable, and greppable. Cast is a fundamentally dangerous operation, so being able to grep-and-check for such is worthwhile.

The D compiler actually recognizes the C form and suggests using the D form to fix it.

Converting C to DasBetterC is largely just a) eliminating use of the preprocessor and then b) making the syntax changes suggested by the compiler.

Yes, I can see the design of D was made carefully.

D is actually a great language. I just "don't understand" why it's not massively used instead of more recent versions of C++, I consider newer version of C++ as a totally different language with more drawbacks than advantages. Half of new features are present to fix previous half baked features. This is quite embarrassing.

Sorry for my selection of words (and for the unrelated opinion, I had to rant), I'm not good at spending time to rephrase when the end content is the same.

I remember one time I spent the whole day browsing the website of D, everything actually make sense. There are still features that I wouldn't use, but this is what I expect from a programming language design. I was impressed by a lot of decisions.

I seemed to remember that I was a bit sad to not find proper performance benchmarks against other languages. I was intrigued because the documentation was so complete, it was just lacking this (maybe I just couldn't find them). It was a long time ago so it has probably been fixed. I will give it a try at some point.

The performance of D vs C and C++ should be identical for code written the same way, as they share the same optimizer and code generators.

Also, we used to publish benchmarks. These inevitably did not produce illumination, but long ripostes from people arguing that the benchmark was unfair, inaccurate, nobody would write code that way, we sabotaged other languages, etc.

We encourage people to run their own benchmarks on their own code and let the results speak for themselves.

One issue with moving to D is it takes a while for people to learn "the D way". For example, if they come from C they write C style code in D. From C++, they write C++ style in D. From Python they write Python style in D. Inevitably they'll run into some difference where D doesn't have an analogous feature, and would get a bit frustrated (even though in D the task would be accomplished a different way).

It takes a bit of perseverance and faith to get through that until one discovers "the D way" and then they're hooked.

One of the reasons for DasBetterC was to reduce this issue as much as possible, though the people who like metaprogramming with the C preprocessor will have more work to do in getting adapted to D's powerful metaprogramming features, which of course work nothing like text macros.

> Also, we used to publish benchmarks. These inevitably did not produce illumination, but long ripostes from people arguing that the benchmark was unfair, inaccurate, nobody would write code that way, we sabotaged other languages, etc.

Oh, this is pretty sad...

Anyway thanks for your time. Was nice to interact with the author of D. I truly believe what you've done will inspire a lot of people.

I hope you didn't encounter too many people saying creating D was foolish.

I spent time checking about a lot of languages and only D (and Jai, but it's not released) would restore my joy of programming.

> The worst, no default values for struct.

This is incorrect. There are other factual errors here as well.

Thanks for replying! Most of what you wrote makes reasonable sense to me. I guess that a lot of the syntax decisions are subjective. Even if I don’t necessarily agree with all of them, I can appreciate your viewpoints better now.

I'm not interested in spending time fixing something that is not considered broken by someone else. They are not bugs that have been introduced by mistakes.

Don't get me wrong, I like to help people. But I learnt to not help people that do not seek help.

You get a plumber fixing your pipes because you need your pipes to be fixed, but if every single plumbers were offering there help it would be annoying.

There are already more that three hundreds proposals:

https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen...

A lot of them are about the syntax. Maybe this won't be endless but I'm sure a lot of time are being wasted. The root of the issue I point seems to be bound to the way the devs are working. Not sure if it will be efficient to tell them to "think more carefully". I do believe my time can be more profitable elsewhere (like commenting here, ah ah).