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

121–130 of 189 posts

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

#121

Post by tptacek »

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…

I think I follow. But why do I want general-purpose functions to ever be non-blocking in Go?

To me, idiomatic Go suggests that libraries, data structures, business logic, &c is encapsulated in blocking functions, and that concurrency is expressed in glue code.

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

#123

Post by iMiiTH »

kjksf wrote: post #2

For other stories of X => Go rewrites, I started keeping a list at https://quicknotes.io/n/vzb7-rewritten-tales-of-rewriting-s

You can add The New York Times to that list, although they rewrote from PHP, Python, Groovy, Java and C++ so no idea how it'll fit in that list.

https://www.youtube.com/watch?v=bAQ9ShmXYLY

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

#124

Post by brightball »

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

Ironically enough, given the recent improvements, performance and productivity...that's not really out of the question...

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

#125

Post by ashearer »

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…

I took it to mean that with Node, some functions have a traditional return value, like functions in most common languages. But if there's even the possibility that they may indirectly invoke an async function, they need to have a different signature using callbacks or promises. For example, here's a simple function:

  function isValidFoo(val) {
      ...return boolean
  }
This function is synchronous now, but its contract needs to change if it internally calls something async (say, it's updated to check a value from a cache, which may trigger a DB lookup). The new signature has to add a callback parameter and drop the return value, or return a promise. Then its callers have to change how they invoke the function, and if they were previously synchronous their signatures have to change as well. Every synchronous function up the call stack needs to care about this internal change.

To avoid a ripple effect, all functions have to be designed to be asynchronous from the beginning, but this increases program complexity significantly. It means avoiding built-in language features such as direct return values, and often means substituting async library functions for built-in looping constructs.

Other languages including Go aren't like that. You don't need to wrap a simple return value in a promise or callback just because retrieving it might someday involve I/O. Execution of the thread/goroutine simply resumes whenever the value is ready, and the function returns normally. In those languages, Node's distinction between sync and async is artificial and unnecessary.

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

#126

Post by KirinDave »

I think this is great engineering, and it shows that the Node runtime needs to consider how to actually address the needs of developers rather than smugly pointing to really frustrating solutions like Cluster that just don't provide equivalent functionality to what Go (and its predecessors in this style such as Erlang and Haskell) are providing.

There are actually a whole host of languages that would let you approach the problem with this technique and get there, so the only thing special about Go is that it is syntactically simple (although it's conceptually quite hard to build reusable code because of poor generic support the resulting bad error handling), so it makes for an easy migration.

We could see similar stories about going from Node.js to Erlang, Nim, Rust, F#, C#, Haskell, or even the newer Python & Ocaml runtimes. So it's not like Go is special here. But it's timing is special, because it's a harbinger of the industry's slow and reluctant admission that pretending everything is single threaded is okay. Even I/O multiplexing with coroutines simply cannot keep pace with even casual demands on modern infrastructure.

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

#127

Post by 0xmohit »

sah2ed wrote: post #115
0xmohit wrote: post #72

Some comments prompt adding another link here: " rel="nofollow">https://medium.com/@tjholowaychuk/farewell-node-js-4ba9e7f3e...

https://medium.com/@tjholowaychuk/farewell-node-js-4ba9e7f3e... FTFY

Thanks. Didn't realize that HN screws up links within angle brackets.

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

#128

Post by KirinDave »

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…

> But the thing the author fails to mention is that there are a lot of Node.js modules which help you easily scale across multiple CPU cores. E.g. PM2 https://www.npmjs.com/package/pm2

There are lots of bad things to say about Golang, but it's pretty wrong to suggest that PM2 makes it as easy to write performant systems as Go does. Go even has a really good race detector to help catch the few cases where you can get around channels.

The idea that a language cannot directly and transparently support scheduling across CPU cores is an antiquated one. Java is abandoning it. C# abandoned it long ago. Erlang showed long ago that we can do it reliably and with great performance.

Heck, even browser-level Javascript is moving away from this idea with async support, although everyone seems rather reluctant to make the plunge towards a stackless architecture.

> If you have a scalability problem with Node.js (or any language for that matter) and you can't find a simple solution that doesn't require rewriting your whole app, you're probably not qualified to manage this project at scale

I've got 13 years experience, 10 of which are as a distributed systems engineer. I've definitely hit the absolute edges of what off the shelf opensource software can manage, and more than once butted up against bugs and limitations of language runtimes. I'm extremely qualified to say that this is wrong.

Sometimes re-architecture and rewriting is the only way forward. That isn't necessarily a failure of the thing to be replaced. It's not even a failure of the architect if it is anticipated and managed correctly.

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

#129

Post by 0xmohit »

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.

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

#130

Post by ciokan »

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}

Results talk. We make the switch to whatever works. I don't take the hype, I'm just grateful we can consider options.
Post reply on HN