4 ms·

I've dabbled a lot with Go. I've found it _very_ effective to a wide variety of problems I don't really have most of the time. If I wanted to implement RAFT I

by inglor 9y ago

I've dabbled a lot with Go. I've found it _very_ effective to a wide variety of problems I don't really have most of the time. If I wanted to implement RAFT I would probably pick Go. If I want a simple REST/GraphSQL server then Node.js is so much easier. `async/await` is nicer for me than goroutines and I find my code easier to reason about. Full disclosure: I'm a Node.js core team member and a Go fan. Part of my reasoning might be how much nicer Node.js got these last couple of years.

dullgiulio 9y ago
Channels are basically the primitive with which you can implement futures, thread-safe queues, etc. Can you elaborate on why you think async/await is easier (for you) to reason about than a goroutine and a channel?
- inglor 9y ago
  Yes, An async function is explicitly async (in its definition). The syntax is obvious which is why JavaScript chose to go that route (rather than adopt channels at a language level for example). Plus, 95% of the time I care about the singular return value of a function - I just want something that's a function but async - and not a green thread that's using a channel to send information back. Both conceptually and in the code it's a lot simpler.
  - anonymoushn 9y ago
    Most of the time you write `let x = await foo()` in js should become `x, err := foo() if err != nil then return nil, err end` in go, not anything to do with channels
    - always_good 9y ago
      What about `const [a, b] = await Promise.all([thing2(), thing2()])`. Or const results = await Promise.map(xs, x => process(x), { concurrency: 2 }) Or having 2 concurrent loops processing some data? All things that require more boilerplate in Go while trivial in Node.
  - Vendan 9y ago
    http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
Cthulhu_ 9y ago
I think it's a decision between levels of abstraction, with Node being a level higher than Go in that area. Probably easier to use it to link services together (glue apps), because with Go you'll probably have to define types and such a lot.

by inglor 9y ago

dullgiulio 9y ago

Channels are basically the primitive with which you can implement futures, thread-safe queues, etc. Can you elaborate on why you think async/await is easier (for you) to reason about than a goroutine and a channel?

inglor 9y ago
Yes, An async function is explicitly async (in its definition). The syntax is obvious which is why JavaScript chose to go that route (rather than adopt channels at a language level for example). Plus, 95% of the time I care about the singular return value of a function - I just want something that's a function but async - and not a green thread that's using a channel to send information back. Both conceptually and in the code it's a lot simpler.
- anonymoushn 9y ago
  Most of the time you write `let x = await foo()` in js should become `x, err := foo() if err != nil then return nil, err end` in go, not anything to do with channels
  - always_good 9y ago
    What about `const [a, b] = await Promise.all([thing2(), thing2()])`. Or const results = await Promise.map(xs, x => process(x), { concurrency: 2 }) Or having 2 concurrent loops processing some data? All things that require more boilerplate in Go while trivial in Node.
- Vendan 9y ago
  http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

Cthulhu_ 9y ago

I think it's a decision between levels of abstraction, with Node being a level higher than Go in that area. Probably easier to use it to link services together (glue apps), because with Go you'll probably have to define types and such a lot.