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

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

medium.com

Post reply on HN
Print view View original

61–70 of 189 posts

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

#61

Post by ignoramous »

ldehaan wrote: post #42
cryptica wrote: post #12

I have read so many articles which incentivize switching from Node.js to Go and every single one of them (this one included) blabber on about the Node.js event loop becoming congested - This is completely misguided - It only shows that the engineer didn't understand the problem. A single Node.js instance runs its business logic in a single process. A single Go instance can run its business logic in multiple processes…

what about just using the built in cluster functionality already in nodejs? I've used it many times with great results and it is really easy to implement.

The clustering module on NodeJs cannot compete with speed that threading, or STM, or Actors offer. The thing with NodeJs is, it is not suited for CPU bound workloads. It's a great fit for I/O bound workloads (where most of the hardwork is done by, say, a DB).

Process to process communication has tremendous cost, although shared-memory does make that faster, but at the cost of complicating the interaction. Message-queue (ZeroMQ) based interaction also an option but, by definition, it cannot be as fast as languages that have concurrency support built-in.

Reasoning about concurrency is hard, and languages like Go (via CSP), Erlang and Scala (via Actors), Java (via Threads), Rust, and Clojure (via STM) take different approaches to make this less of a pain.

CSP and Actors are what seem the most 'natural' of solutions. And that's a major reason why Go and Erlang are frontrunners in the concurrency race.

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

#62

Post by philipov »

Lukasa wrote: post #57
agentS wrote: post #54

Earlier quoted context omitted.

> But you cannot write a non-blocking Go function in the same way. The caller can make function "non-blocking" by wrapping the call in a goroutine themselves. (There's some subtle differences, but they are mostly irrelevant here). For this reason, I'd say there is (almost) no reason to introduce asynchrony in your API in the way you suggest. The rest of your post built on this example seems shaky to me, since it seem…

> The caller can make function "non-blocking" by wrapping the call in a goroutine themselves. Sure, but if they want the return value then either they need to construct the Future-y wrapper I just described or they need to assemble it together in a collection of other function calls wrapped inside a function that itself is either Future-y or uses a long-lived channel to communicate results. It is not novel to build u…

In your opinion, how does Python 3.5's async/await syntax compare to Go for writing concurrent programs? I work primarily with Python3 these days and have no Go experience.

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

#63

Post by lucio »

Fluda3 wrote: post #41
jondubois wrote: post #16

Earlier quoted context omitted.

Totally agree! I would say the same thing if someone had a whole app written on Python and were having performance issues (I definitely wouldn't advise them to switch to Node.js or Golang) - If your ecosystem offers the tools to solve the problem, it's better to use these.

Why on earth are both of you getting downvoted so hard? I am so tired of reading hacker news articles with comments that are so pushed down because of subjective opinionated voting that is so obviously skewed towards one personality type. I have so many thoughts and opinions I want to contribute to these discussions but I have zero confidence it will fit within this type of environment that's been created. It really…

https://news.ycombinator.com/item?id=11273354

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

#64

Post by erlich »

spriggan3 wrote: post #30
cryptica wrote: post #12

I have read so many articles which incentivize switching from Node.js to Go and every single one of them (this one included) blabber on about the Node.js event loop becoming congested - This is completely misguided - It only shows that the engineer didn't understand the problem. A single Node.js instance runs its business logic in a single process. A single Go instance can run its business logic in multiple processes…

> Node.js on the other hand doesn't need any marketing/propaganda; it just sells itself. If Node.js used language X,Y,Z instead of Javascript, it would certainly not have been the success it was. "Javascript on the server" was the marketing/propaganda . Nodejs came at the right moment, Js was exploding, websockets were exploding, coffeescript and co were exploding in popularity. What Go does better than Nodejs is a b…

> 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
  }

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

#65

Post by forgettableuser »

I'm disappointed by the overall tone here. It's as if this were some kind of failure that everybody is piling up on.

- She made three passes to fix the existing code base.

- After that didn't work, with the CTO's involvement, this Go solution was devised.

- It took only 2 weeks to ramp up with Go and build a replacement that solved the problem.

- The number of instances needed dropped from 4 to 2

This sounds like a resounding success.

So congratulations Alexandra and Digg. And thank you for sharing. The article was well written and I learned some things about how the Node.js event system works under the hood.

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

#68

Post by douche »

erlich wrote: post #24

Long live Node.js! As everyone has mentioned this seems to be a simple case where the rewrite is a completely different architecture, which could have been done in Node.js. I'm interested in why this continues to happen. Seems like Node.js is a victim of its own simplicity. The baked-in non-blocking concepts of Node.js makes everyone feel like single-threaded is the only way to go, and think that Node.js is inherentl…

> Seems like Node.js is a victim of its own simplicity

NodeJS is a victim of basing itself on a terrible scripting language that was thrown together to wire up basic event handlers to HTML buttons.

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

#70

Post by mh- »

illumen wrote: post #33

I think the author made a pretty good decision to choose a solution which was proven to meet the requirements by another author. However Amazon does provide a tool to batch download multiple things from S3 though. Let's pretend for a moment those tools don't exist already... Let's also pretend Amazon doesn't suggest another solution for when there are lots of GET requests [0]. Let's pretend that using something like…

>However Amazon does provide a tool to batch download multiple things from S3 though.

out of curiosity, what tool are you referring to here?

Post reply on HN