function logAppendResult( err ) {
  	if (err) console.err('Failed to update file');
  	else console.log('Successfully updated file');
  }

  function logWriteResult( err ) {
  	if (err) console.err('Failed to create file');
  	else console.log('Successfully created file');
  }

  function handleFile( filename, fileExists ) {
  	const timestamp = new Date().toISOString();
  	( fileExists )
  		?	fs.appendFile( filename, `Updated file on ${timestamp}\n`, logAppendResult )
  		:	fs.writeFile( filename, `Created file on ${timestamp}\n`, logWriteResult );
  }

  function main() {
    const filename = './example.txt';
    exists( filename, (fileExists) => handleFile(filename, fileExists) );
  }

Well, who are we to deprive you from the joy of writing lots of boilerplate code?

(There are lots of other reasons to use the promise abstraction – having a type that can be transformed is extremely useful and natural – but that one’s pretty significant.)

    if (err) console.err('Failed to create file');

The real value for promises is async/await.

You've repeated the if(err) check in three places.

None of your error handling bubbles up so the handlers (i.e. Logging to console.error) are buried in the individual functions.

You've pretended to avoid nested callbacks by inlining them using arrow functions.

For your sake I hope that was sarcastic.

Inlining with arrows is just a more functional approach, as I would write in Coffee:

  exists filename, (fileExists) -> handleFile filename, fileExists

I just try very hard to keep my code as simple as possible.

I hope you know it's trivial to write a log function that accepts different callees so you end up with only 1 'if (err)'.

I didn't test, but I wouldn't be surprised if my example runs times faster as well btw.

And if you replace the if(err) lines with a log(...) function it doesn't reduce them to one place. It makes you repeat the log(...) function everywhere. And you'd still need the if statement to handle the control flow.

Simple code is great, but not handling errors doesn't cut it for non throwaway applications.

We can refactor another round:

  function logFsResult( type, err ){
  	var msg= '';
  	switch ( type ) {
  		case 'append': msg= ( err ) ? 'Failed to update file' : 'Successfully updated file';
  			break;
  		case 'write': msg= ( err ) ? 'Failed to write file' : 'Successfully created file';
  			break;
  		default: msg= 'logFsResult error, missing or invalid first argument: '+ (type || '')
  	}
  	( err ) ? console.err( msg ) : console.log( msg );
  }

  function handleFile( filename, fileExists ) {
  	const timestamp = new Date().toISOString();
  	( fileExists )
  		?	fs.appendFile( filename, `Updated file on ${timestamp}\n`, logFsResult.bind(null, 'append') )
  		:	fs.writeFile( filename, `Created file on ${timestamp}\n`, logFsResult.bind(null, 'write') );
  }

For example you could do something like this (sorry, don't have time to open my IDE to try the code i'm going to write):

    logFsResult = (type, err) => {
        map_action = {
          "append": { 
            True: "Succesfully updated file.",
            False: "Failed to update file."
          },
          "write": {
            True: "Successfuly created file.",
            False: "Failed to write file."
          }
        }

        message = map_action[type][(err != null)] // obtain the message
          method = (err)? console.err : console.log // choose logger
          method(err) //invoke the correct logger with the message

    }

You could say this example was more "idiomatic" ES2016.

That's a trap, I should rather make my code as readable, scalable and bug free as possible regardless of ESxxx.

I can refactor in 10 other ways (different styles) coming to the same result, but that's not what my point was about. Using promises and so is just taste or preference, if you like it you use can it, if not do without. I've seen amazing spaghetti with promises and callbacks as well.

Easy to nitpick btw:

you compare err != null?? besides not using strict mode, what should err be? a String? So, what will happen if err is undefined or an empty String?

Then you call logFsResult with err while it is not used.. Did you even consider what happens if the value of type is not available in map_action? I'll be the end of the feast!

last one: True and False as an object key are not Booleans, so if you have your IDE up and running, the code will fail.

Now, you can try to solve this with promises, just as you can try brush your teeth with a broomstick.

YOU are the one who made that comparison, not me. You originally wrote the following line:

   ( err ) ? console.err( msg ) : console.log( msg );

> Then you call logFsResult with err while it is not used..

It seems you don't understand the code. I'm not calling "logFsResult", i am defining a function called logFsResult. You also did the same, you defined logFsResult to receive the "err" parameter.

  function logFsResult( type, err ){
  	var msg= '';
  	switch ( type ) {

ES6 allows you to write more readable code than ES5. Take a look at the features.

[0]: https://github.com/nextorigin/el-borracho/blob/master/src/re...

P.S. Iced3 compiles to ES6 await so all of this has been working together for quite a while.

Using `try`/`catch` with `async`/`await` is a bit awkward, though, which is especially unfortunate because it's the #1 place you should be handling errors.

LightScript has a language feature[0] that makes it less awkward (sort of an`Either`/`Result` type) that I'm thinking about submitting to TC39.

[0] – http://www.lightscript.org/docs/#safe-await