The Way of the Gopher: Making the Switch from Node.js to Golang • Hacker News Board

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

#151

Post by zaphar » Sun, Mar 27, 2016, 7:48 PM UTC

meonkeys wrote: post #91

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.

Another idea: stress-test a Node.js process then hard-limit the number of requests each Node.js process handles based on that stress test. Add more Node.js processes (one per core on the same or other servers) until there is sufficient capacity to handle all requests. This assumes the Node.js code is already distributable across cores and servers, which seems to be the case based on the article. Might have been a day…

Part of the goal was fixing this without having to just throw hardware at it. Every Node process has a non-trivial amount of overhead that requires additional hardware resources. Overhead that the Go app doesn't have. They could have thrown more machines at this but that costs money. The better solution technology wise was Go. It was better suited to their workload.

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

#152

Post by zaphar » Sun, Mar 27, 2016, 7:50 PM UTC

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…

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.

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

#153

Post by _ak » Sun, Mar 27, 2016, 7:54 PM UTC

kasey_junk wrote: post #81

tptacek wrote: post #75

Earlier quoted context omitted.

Can you please explain why, exactly, I would want to take a simple function like "DoSomeStuff" and make it non-blocking with futures in Go? Are you sure you're not just explaining how to write a Node program in Go? Write Node programs in Node.

He is speaking to the idea that you don't need to care about whether a function blocks or not. It's simply untrue (I'd go further and say if its untrue in all languages but that's a digression). To have an abstraction where you really don't care about blocking or not you need promises/futures. Go's futures are bad. Real bad. If you don't want the function to be non-blocking then you are fine with either method signat…

...what? The point is that when any function in Go is blocking, it will obviously block the current flow of your own program until it returns. But it only ever blocks the flow of the current goroutine. Other goroutines will continue running just fine, and the runtime will schedule all the ready-to-run goroutines over the OS threads it has available, and that's nothing you need to take care of in your Go program. It essentially abstracts away what Node.js does in its event loop and the programmer does by manually splitting up the program into a series of function callbacks. Just use that knowledge to structure your program accordingly, and don't tried to badly reinvent futures.

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

#154

Post by _ak » Sun, Mar 27, 2016, 7:59 PM UTC

spullara wrote: post #146

sagichmal wrote: post #107

Earlier quoted context omitted.

Go is not a single threaded language.

Obviously. I was just pointing out that switching to Go wasn't the interesting bit. Maybe everyone misread my comment.

If you didn't want your comment to be misread, you should have been more specific after the "another".

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

#155

Post by tbrock » Sun, Mar 27, 2016, 8:12 PM UTC

awjr wrote: post #32

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…

I'm also finding the amount of open source "solved this problem already for you" solutions available for Node is phenomenal.

In my experience, critical problems required by successful language ecosystems that are solved by nodejs modules are either solved poorly or abandoned by the original author. The ones solved by go packages are solved elegantly and maintained.

Your mileage may vary but the JS ecosystem is mostly garbage from where I'm standing.

Want examples?

- Distributed worker queue

- Minimal web framework

- etc...

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

#156

Post by kasey_junk » Sun, Mar 27, 2016, 8:22 PM UTC

_ak wrote: post #153

kasey_junk wrote: post #81

Earlier quoted context omitted.

He is speaking to the idea that you don't need to care about whether a function blocks or not. It's simply untrue (I'd go further and say if its untrue in all languages but that's a digression). To have an abstraction where you really don't care about blocking or not you need promises/futures. Go's futures are bad. Real bad. If you don't want the function to be non-blocking then you are fine with either method signat…

...what? The point is that when any function in Go is blocking, it will obviously block the current flow of your own program until it returns. But it only ever blocks the flow of the current goroutine. Other goroutines will continue running just fine, and the runtime will schedule all the ready-to-run goroutines over the OS threads it has available, and that's nothing you need to take care of in your Go program. It e…

How is that different than any language that supports parallel concurrency?

You can literally say that about every labguafe that has concurrency abstractions.

The whole point of the argument is that golangs abstractions just push the callbacks (or blocking sync) to the application layer.

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

#157

Post by jksmith » Sun, Mar 27, 2016, 8:32 PM UTC

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…

Good point. Let's consider another side to that with just some general observational comments. Golang seems to have a habit so far for revealing answers for devs with varying skills for internet applications that other languages don't.

I've moved from writing code (including golang) to managing large projects. My biggest concern now is meeting the three metrics of project ecstacy: 1) correct solution, 2) on time, 3) within budget. If one language appears to get me better performance on these metrics over another, then I'm interested, whether that language has generics or not.

Another concern from the business perspective is whether or not a language is easy to hire for, and gets devs more productive in less amount of time without creating a lot of technical debt in the process. I have a gruesome time dealing with this very issue, and if golang was the basis for my toolchain, my guess is my hiring concerns would probably be minimized to enough degree that it would have a positive impact on my business -- looping back around to metrics I mentioned.

Maybe the solution should have been kept in js, but I guess it wouldn't surprise me if the golang effort these folks just went through will probably continue to pay off in a substantive way.

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

#158

Post by diroussel » Sun, Mar 27, 2016, 8:47 PM UTC

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…

I would guess it was the immaturity of the java IO layer that didn't play well with green threads. You need a good asycn IO layer on all the platforms that java was supporting (solaris and windows, plus others) for the green threads to work well.

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

#159

Post by woah » Sun, Mar 27, 2016, 8:54 PM UTC

awjr wrote: post #32

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…

I'm also finding the amount of open source "solved this problem already for you" solutions available for Node is phenomenal.

Left pad

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

#160

Post by dalyons » Sun, Mar 27, 2016, 9:30 PM UTC

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?