Hacker News Reader

Comment by kachapopopow | Hacker News Reader

I could never get into zig purely because of the syntax and I know I am not alone, can someone explain the odd choices that were taken when creating zig?

the most odd one probably being 'const expected = [_]u32{ 123, 67, 89, 99 };'

and the 2nd most being the word 'try' instead of just ?

the 3rd one would be the imports

and `try std.fs.File.stdout().writeAll("hello world!\n");` is not really convincing either for a basic print.

View on HN

I will never understand people bashing other languages for their syntax and readability and then saying that they prefer Rust. Async Rust is the ugliest and least readable language I've ever seen and I've done a lot of heavily templated C++

> Async Rust is the ugliest and least readable language I've ever seen and I've done a lot of heavily templated C++

No, this is a wild claim that shows you've either never written async Rust or never written heavily templated C++. Feel free to give code examples if you want to suggest otherwise.

Every language i am not deeply familiar with is disgusting.

But for real the ratings for me stem from how much arcane symbology i must newly memorize. I found rust to be up there but digestible. The thought of c++ makes me want to puke but not over the syntax.

  template<auto V>
  concept non_zero = (V != 0);

  template<typename T>
  concept arithmetic = std::is_arithmetic_v<T>;

  template<arithmetic T>
  requires non_zero<T{42}>
  struct complicated {
      template<auto... Values>
      using nested_alias = std::tuple<
          std::integral_constant<decltype(Values), Values>...,
          std::conditional_t<(Values > 0 && ...), T, std::nullptr_t>
      >;

      template<typename... Ts>
      static constexpr auto process() {
          return []<std::size_t... Is>(std::index_sequence<Is...>) {
              return nested_alias<(sizeof(Ts) + Is)...>{};
          }(std::make_index_sequence<sizeof...(Ts)>{});
      }
  };

I most definitely agree.

The difference is that nobody really writes application code like that, it's a tool for writing libraries and creating abstractions. If all of the ugliness of async Rust was contained inside Tokio, I would have zero problems with it, but it just infects everything it touches

Unfortunately it makes the libraries difficult (or at least very tedious) to read. I find zig's standard library a very good reference for figuring out to do things in application space, from what I've seen it's been very clear and useful.

I don't really prefer rust, but I'd take that syntax over zig, c++ templating is just evil though. Also it's not about readability, but rather the uniqueness to it.

Concur, but non-async rust is a different matter!

Yeah, I like rust but I hate async. I wish it had never been added to the language, because it has so thoroughly infected the crate ecosystem when most programs just do not need async.

I will never understand people who bash someone's preference of a language after claiming they don't understand people who bash other languages for their syntax. Turns out language syntax preferences are subjective and most likely not black and white.

For example, Pythons syntax is quite nice for the most part, but I hate indentation being syntax. I like braces for scoping, I just do. Rust exists in both camps for me; I love matching with Result and Option, but lifetime syntax confuses me sometimes. Not everyone will agree, they are opinions.

> and the 2nd most being the word 'try' instead of just ?

All control flow in Zig is done via keyword

These are extremely trivial, to the point that I don’t really know what you’re complaining about. What would expect or prefer?

it's not about triviality, but why not use what is generally accepted already, why did zig decide to be different?

What is "generally accepted" though?

If you mean C-style declarations, the fact that tools such as https://linux.die.net/man/1/cdecl even exist to begin with shows what's wrong with it.

<auto/type/name> <name/type> (array?) (:)= (value)

<fn> <generic> <name>(<type/argument>[:] <type/argument> [(->/:) type]

[import/use/using] (<package>[/|:|::|.]<type> | "file") (ok header files are a relic of the past I have to admit that)

I tried writing zig and as someone who has pretty much written in every commonly used language it just felt different enough where I kept having to look up the syntax.

There’s almost countless languages that don’t do anything like this, whereas Zig is very similar. It’s fine to prefer this syntax or that, but Zig is pretty ordinary, as languages go. So yes, the differences are trivial enough that it’s a bit much to complain about. You can’t have spent much time with Zig or you’d have learned the syntax easily.

The same goes for go, though. And out of the two, I find Zig is still closer to any sane existing language schema. While go is like, let's write C-style types, but reverse the order, even though there is a widely accepted type notation that already reverses it with a :, that even let's you infer types in a sane way.

'const expected = [_]u32{ 123, 67, 89, 99 };'

constant array with u32, and let the compiler figure out how many of em there are (i reserve the right to change it in the future)

'const expected: []const u32 = &.{ 123, 67, 89, 99 };' also works.

Reply on news.ycombinator.com