Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bugs in Hello World

blog.sunfishcode.online

Post reply on HN
Print view View original

51–60 of 262 posts

Re: Bugs in Hello World

#51

Post by 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

Re: Bugs in Hello World

#55

Post by nojs »

boloust wrote: post #45
xlii wrote: post #32

I’m disappointed. I expected some obscure edgecase (like “Main is usually a function…” [1]) but instead that’s about scope handling, contract design and responsibility shift. “Hello world” method simply calls an API to a text interface. It uses simple call, to a simple interface that is expected to be ever present. I don’t find any bug there. It won’t work if such interface isn’t available, is blocked or doesn’t exis…

The bug is not that the program failed, it's that the program failed but reported a success.

I think they are arguing that it didn’t fail, it did everything you asked of it (it didn’t claim to successfully print hello world in every scenario, just to attempt to write to the buffer you gave it, which it did).

Re: Bugs in Hello World

#57

Post by boloust »

nojs wrote: post #55
boloust wrote: post #45

Earlier quoted context omitted.

The bug is not that the program failed, it's that the program failed but reported a success.

I think they are arguing that it didn’t fail, it did everything you asked of it (it didn’t claim to successfully print hello world in every scenario, just to attempt to write to the buffer you gave it, which it did).

No, I think the argument was pretty clearly that "the program failed but it can't possibly be expected to work under every conceivable scenario".

Re: Bugs in Hello World

#58

Post by dotancohen »

boloust wrote: post #45
xlii wrote: post #32

I’m disappointed. I expected some obscure edgecase (like “Main is usually a function…” [1]) but instead that’s about scope handling, contract design and responsibility shift. “Hello world” method simply calls an API to a text interface. It uses simple call, to a simple interface that is expected to be ever present. I don’t find any bug there. It won’t work if such interface isn’t available, is blocked or doesn’t exis…

The bug is not that the program failed, it's that the program failed but reported a success.

To quote one of my favorite books:

  > [Hello, world] is the big hurdle. To leap over it you have to be able to
  > create the program text somewhere, compile it successfully, load it, run
  > it, and find out where your output went.
Those are the goals of "Hello, world!". Create the program, compile it, load it, run it, and find the output. Things that are not goals of "Hello, world!" are handling user input, reusable components (functions), network access, etc etc etc, error handling.

It's fine that the error is not handles, just as it is fine that the output went to stdout. Error handling was not a goal of the program.

Re: Bugs in Hello World

#59

Post by HellsMaddy »

You all joke that this doesn’t happen in practice, but something like this literally just bit me and it took me a few too many minutes to figure out what was going on.

I use a bash script as my BROWSER which calls another bash script to launch or communicate with my browser that I run inside a container. The script that my BROWSER script calls has some debug output that it prints to stderr.

I use mutt as my email client and urlscan [0] to open URLs inside emails. Urlscan looks at my BROWSER environment variable and thus calls my script to open whatever URL I target. Some time recently, the urlscan author decided to improve the UX by hiding stderr so that it wouldn’t pollute the view, and so attempted to pipe it to `/dev/null`. I guess their original code to do this wasn’t quite correct and it ended up closing the child processes’ stderr.*

I generally use `set -e` (errexit) because I want my scripts to fail if any command fails (I consider that after an unhandled failure the script’s behavior is undefined, some other people disagree and say you should never use `set -e` outside of development, but I digress). My BROWSER scripts are no exception.

While my scripts handle non-zero returns for most things that can go wrong, I never considered that writing log messages to stdout or stderr might fail. But it did, which caused the script to die before it was able to launch my browser. For a few weeks I wasn’t able to use urlscan to open links. I was too lazy to figure out what was wrong, and when I did it took me a while because I looked into every possibility except this one.

Luckily this wasn’t a production app. But I know now it could just as feasibly happen in production, too.

I opened an issue[1] and it was fixed very quickly. I love open source!

*No disrespect to urlscan, it’s an awesome tool and bugs happen to all of us!

[0]: https://github.com/firecat53/urlscan

[1]: https://github.com/firecat53/urlscan/issues/122

Re: Bugs in Hello World

#60

Post by 0x0 »

paradite wrote: post #51

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…

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.
Post reply on HN