The Way of the Gopher: Making the Switch from Node.js to Golang

Re:The Way of the Gopher: Making the Switch from Node.js to ... by erlich on Sunday March 27, 2016 @07:51AM (#11369680)

> What Go does better than Nodejs is a better standard library

What is so hard about `require('lodash')`, or `require('moment')`?

> true concurrency

The trade-off is you get great concurrency without thinking about it. If you are working in Go, you have to start thinking about it as you go. You can always think about it as you go with Node.js if you want, but you don't have to and you will still get quite far.

> static typing

See http://flowtype.org or http://www.typescriptlang.org. With more advanced type systems than Go.

> With Go it doesn't matter if an operation is blocking or non blocking, that fact can totally be abstracted from the client code. Writing callbacks is tedious, promises are tedious, co routines with yield need plumbing and async isn't in the spec.

You can use ES7 async/await and promises today. That it "isn't in the spec" probably won't be for too much longer.

  async function() {
    const {data} = axios.get('foo')
    const results = []
    const arr = ['foo', 'bar', 'baz']
    for (const i in arr) {
      results[i] = await axis.get(arr[i])
    } 
    return results
  }

[ Parent | on HN ]

Re:The Way of the Gopher: Making the Switch from Node.js to ... by skybrian on Sunday March 27, 2016 @12:53PM (#11370564)

A big advantage for Go is that the standard library has been stable since 1.0 and there are no plans for breaking changes.

This appears not to be true for lodash.

[ Parent | on HN ]

Re:The Way of the Gopher: Making the Switch from Node.js to ... by jdd on Monday March 28, 2016 @02:23AM (#11372997)

Lodash introduces breaking changes in major version bumps (following semver).

So upgrades are optional and not pulling the rug out from underneath the feet of devs.

Major releases allows the project to make corrections and avoid carrying around years of baggage.

[ Parent | on HN ]

Re:The Way of the Gopher: Making the Switch from Node.js to ... by skybrian on Tuesday March 29, 2016 @03:50PM (#11384334)

Yes, that's usually the best strategy for most of us.

But a standard library is a little different due to the sheer number of dependencies and level of coordination needed to upgrade them all. Go got it mostly right the first time, and the lack of churn is a major advantage.

[ Parent | on HN ]

Re:The Way of the Gopher: Making the Switch from Node.js to ... by gotchange on Sunday March 27, 2016 @10:25AM (#11370035)

    async function() {
      const {data} = axis.get('foo'),
            arr = ['foo', 'bar', 'baz'];
      return arr.map(ele => await axis.get(ele));
  }

I rewrote your async function making it more concise and compact. Isn't advisable not to use «for in» with arrays?

[ Parent | on HN ]

Re:The Way of the Gopher: Making the Switch from Node.js to ... by Arnavion on Sunday March 27, 2016 @03:31PM (#11371149)

    return arr.map(ele => await axis.get(ele));

is not legal - the await has no corresponding async. You may have wanted to write

    return arr.map(async ele => await axis.get(ele));

but that's the same as

    return arr.map(ele => axis.get(ele));

(Assuming axis.get returns a promise.)

That is, it returns an array of promises of values, not a promise of an array of values like erlich's function.

erlich's example is correct, with the replacement of for-in with for-of.

Edit:

Also, a solution using Array.map() is not impossible:

    return Promise.all(arr.map(ele => axis.get(ele)));

but this has different characteristics than the original function. The original ran the tasks in series whereas this runs them in parallel.

[ Parent | on HN ]