[paradite]

Since we are going pedantic here, here are 3 bugs that I found in the blogpost:

1. Node.js result is out-dated. I run on Node.js v14.15.1 hello world code below on macOS and it reported exit code 1 correctly:

  // testlog.js
  console.log('hello world')
  process.exit(0)

  // bash
  $ node -v
  v14.15.1
  $ node testlog.js > /dev/full
  -bash: /dev/full: Operation not permitted
  $ echo $?
  1

2. Node.js is not a language. JavaScript is a language, and Node.js is a JavaScript runtime environment that runs on the V8 engine and executes JavaScript code outside a web browser.

3. Missing JavaScript result in the table, which is the most popular language on GitHub: https://octoverse.github.com/#top-languages-over-the-years

[0x0]

Since macOS does not have /dev/full, I think what is actually happening here is your bash shell fails to create a file named "full" in "/dev" and so the bash shell exits with an error; this has nothing to do with node.js.

[gwd]

Yeah -- that's bash that's reporting the error; it looks like node never actually gets run.

[paradite]

Yeah you are probably right.

Now I'm curious about another interesting question. Should bash be the one that handle the error and exit code in this case? Since it seems to be responsible for handing the piping operation.

[moonchild]

If by 'in this case' you mean the problem mentioned by the linked article, then no. The shell is not 'responsible for handling the piping operation'. It creates the pipe, but is not responsible for moving data through it.

[paradite]

Makes sense. Thanks for the explanation!

[dmurray]

> 2. Node.js is not a language. JavaScript is a language,

This criticism is the wrong way around. All of the author's "languages" are actually language implementations like NodeJS. You can tell because he produced the results by running the code, rather than by reading a spec.

[paradite]

Yes you are right about the differences.

So what I'm proposing is to put JavaScript in the language column (like other languages such as Java) and note the usage of Node.js as the implementation in the second column together with version (similar to Java -> openjdk 11.0.11 2021-04-20).

Would that make sense?

[dmurray]

That would certainly make sense, but the author hasn't followed that pattern consistently so far - e.g. the row for C doesn't list the compiler or architecture.

[ksbrooksjr]

On node 16.9 console.log doesn't produce a non-zero exit code, but process.stdout.write does, and gives me a decent error message as well:

  internal/fs/utils.js:332
      throw err;
      ^
  Error: ENOSPC: no space left on device, write
      at writeSync (fs.js:736:3)

[terinjokes]

This is because console.log isn't the equivalent to the post's printf. It is purposefully opaque to the application (and applications should not assume anything happens with the input).[0]

> Its main output is the implementation-defined side effect of printing the result to the console.

[0]: https://console.spec.whatwg.org/#logger

[jwilk]

It wouldn't make sense to include JavaScript, because it doesn't have the concept of stdout.