3 ms·

You do understand that zig started out by removing things from C and then "adding rich constexprs" and that's it? It's arguably simpler than C, C is actually t

You do understand that zig started out by removing things from C and then "adding rich constexprs" and that's it? It's arguably simpler than C, C is actually two languages (C and C preprocessor), three if you add make, five if you add cmake and autoconf.

drfuchs 5y ago
What's the motivation for changing the visually appealing C syntax "ptr->field" to the whack "ptr.*.field"?
- sobeston 5y ago
  ptr.field works.
  - abaracadabi 5y ago
    Spoken like a true headstrong nerd. A little condescending sarcasm to boot. I’m sure you own a device running an OS with quite a few ptr->field’s working just fine.
abaracadabi 5y ago
So it started as “let me reinvent the C” with ugly syntax? Little fns in ziggys little async; dots everywhere; try expects everywhere; too much punctuation. All the esoteric punctuation after loop constructs.
10000truths 5y ago
make, cmake and autoconf are not not part of the C language, they are build tools.
- dnautics 5y ago
  In practice you can't be productive in a large project in C without make, increasingly cmake (at the very least for reading someone else's c project). And it's part of the zig agenda to unify build tools, too. We are now in the 2nd decade of the 21st century, it is not strange for programming languages to be opinionated about build tools, ruby has rake, rust has cargo, js has, well, js is a mess, don't copy js, elixir has mix, etc (and those are just the languages I know).
  - 10000truths 5y ago
    That doesn’t make those tools part of the C standard, though. The standard does not mandate the use of any particular build tool for C projects beyond a conformant C compiler. There is nothing stopping me from using meson, ninja, bazel, a Frankenstein shell script, etc. to build a C project. Hell, there is nothing stopping me from using make to build non-C projects - it was designed as a generic dependency resolution tool.
    - nicoburns 5y ago
      > There is nothing stopping me from using meson, ninja, bazel, a Frankenstein shell script, etc. to build a C project There is if you intend to use libraries as those libraries may well have chosen a build system other than the one you have chosen meaning you'd have to rewrite their build scripts. This is far from the experience of using libraries in languages with unified build systems which is typically as simple as adding a line with the version of the library you want to a manifest file.
    - dnautics 5y ago
      > That doesn’t make those tools part of the C standard, though So? I'm talking about the C experience, not the C standard.

drfuchs 5y ago

What's the motivation for changing the visually appealing C syntax "ptr->field" to the whack "ptr.*.field"?

sobeston 5y ago
ptr.field works.
- abaracadabi 5y ago
  Spoken like a true headstrong nerd. A little condescending sarcasm to boot. I’m sure you own a device running an OS with quite a few ptr->field’s working just fine.

abaracadabi 5y ago

So it started as “let me reinvent the C” with ugly syntax? Little fns in ziggys little async; dots everywhere; try expects everywhere; too much punctuation. All the esoteric punctuation after loop constructs.

10000truths 5y ago

make, cmake and autoconf are not not part of the C language, they are build tools.

dnautics 5y ago
In practice you can't be productive in a large project in C without make, increasingly cmake (at the very least for reading someone else's c project). And it's part of the zig agenda to unify build tools, too. We are now in the 2nd decade of the 21st century, it is not strange for programming languages to be opinionated about build tools, ruby has rake, rust has cargo, js has, well, js is a mess, don't copy js, elixir has mix, etc (and those are just the languages I know).
- 10000truths 5y ago
  That doesn’t make those tools part of the C standard, though. The standard does not mandate the use of any particular build tool for C projects beyond a conformant C compiler. There is nothing stopping me from using meson, ninja, bazel, a Frankenstein shell script, etc. to build a C project. Hell, there is nothing stopping me from using make to build non-C projects - it was designed as a generic dependency resolution tool.
  - nicoburns 5y ago
    > There is nothing stopping me from using meson, ninja, bazel, a Frankenstein shell script, etc. to build a C project There is if you intend to use libraries as those libraries may well have chosen a build system other than the one you have chosen meaning you'd have to rewrite their build scripts. This is far from the experience of using libraries in languages with unified build systems which is typically as simple as adding a line with the version of the library you want to a manifest file.
  - dnautics 5y ago
    > That doesn’t make those tools part of the C standard, though So? I'm talking about the C experience, not the C standard.