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

91–100 of 189 posts

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

#91

Post by meonkeys »

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-long workaround rather than a weeks-long rewrite.

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

#92

Post by maleck13 »

Just wanted to add my thanks to the author for writing this enjoyable piece. After working with node for 4 yrs & golang for 1yr, I think they both have their place. If forced to choose one, I would currently pick golang due to its excellent tooling, strict typing, excellent std lib and simple deployment.

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

#93

Post by ignoramous »

pka wrote: post #71
ignoramous wrote: post #61

Earlier quoted context omitted.

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

I would say the most natural is STM - you don't need to change much, just wrap your concurrent, shared memory accessing code in a STM transaction, be careful with IO (or use a language which prohibits IO in a STM block like Haskell) and you are done. Actors are pretty nice when it comes to distributed services, and Erlang/OTP is pretty much uncontested here. Threads with manual locking are only useful when speed is r…

Interesting point there. Latency vs Throughput. Using green-threads (Quasar on JVM) might be the best of both worlds then?

Akka.io on JVM could pretty much do what Erlang can on BEAM, functionality wise. Although some people have raised concerns over it being a "pseudo" solution and that it is a no match for Erlang.

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

#94

Post by dikaiosune »

bliti wrote: post #84
tptacek wrote: post #76

Earlier quoted context omitted.

"So what I'm saying is, we should all still be using PHP."

What is star fighter written in? Curious, no bad intentions.

IIRC, it's got some Go infrastructure and the trading chapters have bots written in Ruby.

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

#95

Post by Lukasa »

vishbar wrote: post #58
Lukasa wrote: post #57

Earlier quoted context omitted.

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

Go isn't just a threaded concurrency model, it uses an M:N greenthreads pattern. Also, when you say that Go I/O operations are blocking, it is true that they'll logically block a goroutine. However, under the hood, it uses the same libuv-style async IO (or IOCP on Windows) that Node does. An operating system thread doesn't get blocked; the goroutine is "shelved" and woken up again when the I/O is complete. It accompl…

Honestly, I think the distinction between M:N threading and straight OS threading is pretty minor. It grants some advantages to the language runtime: it can control the stack size, for example. But in terms of how it affects the development style and what kinds of bugs it encourages/discourages I don't think it dramatically differs from the OS threading model.

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

#96

Post by noir_lord »

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}

Still using PHP (and Python and some other stuff) in 2016.

I make it a rule to only jump on the new bandwagon when I know it's not going to explode in 3 months and currently isn't on fire.

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

#97

Post by fooster »

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…

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

Please explain.

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

#98

Post by fooster »

anton-107 wrote: post #39
mnutt wrote: post #34

Earlier quoted context omitted.

I generally agree with the sentiment about scaling across cores and nodes being the same; after all, you're eventually going to need to scale across nodes so you may as well go ahead and get that working. But there are times when it can be a pain. For instance, a node app I run at scale maintains an in-memory read cache that rarely gets updated. When we scale with processes, we end up having to duplicate the cache ac…

Or... just use the battle-tested tool that solves this exact problem well for you. Put your cache into Redis or other in-memory cache.

... and now you have two problems?

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

#99

Post by skewart »

jwdunne wrote: post #52
Fluda3 wrote: post #41

Earlier quoted context omitted.

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…

I agree. My voting policy reflects: I reserve down vote for comments that worsen the quality of discussion. Examples are rude or dismissive comments that fail to address any point in the OPs comment or article. At its worst, I've seen people get down voted for asking beginner level questions. The calibre of folk who post here can, by its nature, make commenting a nervous activity. Getting down voted for trying to exp…

I completely agree. I do the same thing for subjectively downvoted posts. I want HN to be a place where people share all kinds of ideas and ask questions at any level.

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

#100

Post by mwcampbell »

tptacek wrote: post #76
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}

"So what I'm saying is, we should all still be using PHP."

Or Perl, or C. After all, even PHP was once a new hipster language.

Of course, it's good to be skeptical of the current hyped flavor of the moment. But some languages really are better than others for specific tasks, and new languages do sometimes improve on their predecessors.

Post reply on HN