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

161–170 of 189 posts

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

#161

Post by AsyncAwait »

0xmohit wrote: post #129
romanovcode wrote: post #59

2010 - Making switch from PHP to Ruby 2013 - Making switch from Ruby to Node 2016 - Making switch from Node to Go 2019 - Making switch from Go to {hype}

This is inevitable. However, not everything is {hype}. Consider rust, for example. People have managed good stuff using that. Dropbox, Servo are widely known examples.

Spot on, while I see problems with many of the latest technologies myself, not EVERYTHING is hype and I am getting tired of people labeling it as such just because they don't want to learn it/make the switch but want to mask it like they would if it wasn't just hype.

I've seen this very recently personally, where I was accused of adopting hype for switching to Swift for a major rewrite of my app, where I'd pretty much start over in Objective-c anyways so I may just as well do it in a safer, much nicer language that's going to be the future of the platform eventually anyway...

It turns out that you don't have to switch - if your current stack works well for you stick with it. It doesn't make you "less cool". But it also doesn't mean that somebody else doesn't have a legitimate reason to adopt the new technology, and this is a pretty textbook example of what I'd call a justified switch.

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

#162

Post by conetwo »

rgbrgb wrote: post #139
forgettableuser wrote: post #65

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 r…

I think the disappointment here is that the OP seemed not to understand the root cause of the problem and implemented a solution in a different language (load balanced worker pool) that could have also worked in the original language without a total rewrite. Then the new language is trotted out as the savior. It sounds like the file fetch workers and request handlers were running on the same process, so the longer-ru…

Yes, the root cause analysis feels off. (Though the cause might be as simple as the cost of walking through the message queue.)

Something is definitely blocking or resource constrained and causing "thrashing": the (uncontrolled) number of requests allowed to spin up at a time (which creates resource contention) combined with the fan out (1 request = 100+ S3 requests/callbacks) seem like a likely causal factor. As you said, a worker approach (with limits on the number of concurrent requests) is going to be similar to the golang approach used.

The golang approach makes the average execution time of a given request more consistent but the overall wait time may still increase (dramatically) if the arrival rate grows too high. (Classic problem).

Say "easily" fixable by adding servers? Partly true. What happens if the S3 calls slows down dramatically?

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

#163

Post by prlin »

bitwize wrote: post #80
fooyc wrote: post #69

Earlier quoted context omitted.

Care to explain?

Two iron-clad rules of data processing: * All data has a type * All I/O is asynchronous and interrupt (event) driven At its inception Unix doubled down on stupid, first by encouraging data to be stored and migrated in the form of untyped text streams, which require ad-hoc parsing and unparsing logic at the endpoints; and secondly by failing to provide asynchronous I/O primitives to user space. POSIX later provided an…

For 1) how do other systems handle data being stored and passed between processes?

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

#164

Post by amalantony06 »

dalyons wrote: post #160

im obviously missing something here, hopefully someone can explain? I understand the eventloop/nexttick/etc architecture of node, but i dont understand how in this case he was blocking the loop? Shouldnt all the operations to S3 be async (and thus non-blocking, even if waiting for a timeout)? What was the specific part in this scenario that was causing the loop to stall?

If I understand correctly, the problem was that they were making several thousands of requests to S3. While the requests to S3 themselves were asynchronous, the callbacks for these requests were queued up for (synchronous) execution in the event loop. Due the large number of callbacks in the queue already, new callbacks for the incoming requests were queued up for execution behind the previous callbacks, leading to latencies in serving up responses.

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

#165

Post by dalyons »

amalantony06 wrote: post #164
dalyons wrote: post #160

im obviously missing something here, hopefully someone can explain? I understand the eventloop/nexttick/etc architecture of node, but i dont understand how in this case he was blocking the loop? Shouldnt all the operations to S3 be async (and thus non-blocking, even if waiting for a timeout)? What was the specific part in this scenario that was causing the loop to stall?

If I understand correctly, the problem was that they were making several thousands of requests to S3. While the requests to S3 themselves were asynchronous, the callbacks for these requests were queued up for (synchronous) execution in the event loop. Due the large number of callbacks in the queue already, new callbacks for the incoming requests were queued up for execution behind the previous callbacks, leading to l…

Ah ok! Perfect, thanks, that's what I was missing. Makes total sense now. In any lang (even in ruby!) you could have separate thread pools(or EM loops, whatever) for the s3 requests & web handlers. But because node only has one EL, and node interprocess comms is awkward, its tricky. Gotcha, cheers.

I wonder if using something like async.eachLimit would have helped; it might prevent the s3 batches from flooding the loop & give a chance for web reqs to interleave, but probably at a cost to the median resp time.

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

#166

Post by CydeWeys »

planetjones wrote: post #74

> for each request, Octo typically fetches somewhere between 10–100 keys from S3 I'm really curious as to why this is neccessary - what are the 10-100 keys you are fetching per request ? Just reading the high level article it sounds like there is some issue with what this service is doing, irrespective of the language it's doing it in.

Well, it's Digg, so maybe each key is a comment? That's entirely reasonable. I can think of any number of sample web applications that would require loading dozens of objects from a DB per page load.

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

#167

Post by ilaksh »

zaphar wrote: post #152
rgbrgb wrote: post #139

Earlier quoted context omitted.

I think the disappointment here is that the OP seemed not to understand the root cause of the problem and implemented a solution in a different language (load balanced worker pool) that could have also worked in the original language without a total rewrite. Then the new language is trotted out as the savior. It sounds like the file fetch workers and request handlers were running on the same process, so the longer-ru…

But using a process pool is far more heavyweight than threads. There is a cost there that you pay in hardware. Using Go allowed them to do this with less hardware cost than Node. That's a win that continuing to use Node would not have been able to provide.

Node does actually have threads with modules like webworker-threads.

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

#168

Post by ilaksh »

ysolo wrote: post #120

I've been coding in Node for a couple of years. I find it interesting. But I'm aware that the async model of Node inverts the flow of control, turning code inside out and makes application logic difficult to scrutinize and reason about. Stack traces in traditional multithreaded languages are easy to understand, whereas in Node a stack trace is necessarily filled with unrelated calls - or perhaps no stack at all in th…

    let result = await call();
    nextCall(result)
Not really a pale imitation, works just as well. The async and await keywords could be shorter. Toffeescript and Livescript are more concise than the new ECMAScript with their operators for async but it's just a little more text to read.

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

#169

Post by ilaksh »

tankenmate wrote: post #143
ysolo wrote: post #120

I've been coding in Node for a couple of years. I find it interesting. But I'm aware that the async model of Node inverts the flow of control, turning code inside out and makes application logic difficult to scrutinize and reason about. Stack traces in traditional multithreaded languages are easy to understand, whereas in Node a stack trace is necessarily filled with unrelated calls - or perhaps no stack at all in th…

Node's javascript engine v8 can only run in one thread, if you want to access it from a different thread you need to take a lock (for example in Chrome / Chromium you need to take an isolate lock; each page runs it's own isolated v8 engine (read only code pages are shared, all other javascript pages (data plus read/write code pages) are private); in this sense it is very similar to the GIL in Python. So although node…

See webworker-threads

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

#170

Post by justicezyx »

XorNot wrote: post #50
justicezyx wrote: post #5

Another evidence that the language that is narrowly focused and force "more" correct practices tends to work better in practice. Or, coders are getting worse at master the more powerful language...

99% of the time what is called "mastering" is actually a whole bunch of stuff you shouldn't do if you want a maintainable codebase. Tricks are just that: tricks. No one sets up a business based on how you pull a rabbit out of hat, nor should they.

No, mastering a complex and powerful language means use the minimal feature for the majority of your needs, and knows how and when to use the "dangerous" part for a small fraction of your needs.

I do not know much of JS, but people write C++ with loads of patterns are prominent examples of people who do not master the language. That's not trick. That's real engineering with (often) bitter experience.

Post reply on HN