4 ms·

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 belo

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 https://octoverse.github.com/#top-languages-over-the-years

0x0 5y ago
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 5y ago
  Yeah -- that's bash that's reporting the error; it looks like node never actually gets run.
- paradite 5y ago
  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 5y ago
    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 5y ago
      Makes sense. Thanks for the explanation!
jwilk 5y ago
It wouldn't make sense to include JavaScript, because it doesn't have the concept of stdout.
ksbrooksjr 5y ago
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 5y ago
  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 https://console.spec.whatwg.org/#logger
dmurray 5y ago
> 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 5y ago
  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 5y ago
    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.

0x0 5y ago

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 5y ago
Yeah -- that's bash that's reporting the error; it looks like node never actually gets run.
paradite 5y ago
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 5y ago
  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 5y ago
    Makes sense. Thanks for the explanation!

jwilk 5y ago

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

ksbrooksjr 5y ago

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 5y ago
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 https://console.spec.whatwg.org/#logger

dmurray 5y ago

> 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 5y ago
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 5y ago
  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.