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

111–120 of 189 posts

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

#111

Post by jwdunne »

madgar wrote: post #78
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…

pg believes downvoting is an appropriate expression of disagreement: https://news.ycombinator.com/item?id=117171

I'm not sure there's an awareness the effect a down vote can have on someone new here. I remember when I made a comment after joining and it got a down vote. I didn't comment for about 6 months.

The fact that down votes are silent makes things worse. Great, you've been down voted. Why? Ask why, down vote again. It's almost a recipe for gradual shaping to conformity of group opinion for anyone who wants to participate here. It can then come across as say these things, don't say these things and you'll be sailing.

I don't know, perhaps an explanatory comment should be encouraged so that real education happens. Otherwise its almost Pavlovian in nature, especially for the less confident and highly anxious.

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

#112

Post by bliti »

akshatpradhan wrote: post #89
bliti wrote: post #85

Wait until they discover Elixir and Phoenix. It's the power of Go (a bit more I think) without the ugly syntax.

What sets Elixir apart from Go?

IMO, it's simpler to write and easier to read. It's been a bit faster in t he tests I've run but not by a lot. Probably due to my skills. I just find its nicer all around. It does not carry over anything from C.

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

#113

Post by ungzd »

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}

2013 - switch from sane, stable, mature language to weirdest scripting engine extracted from web browser. Because lol that's cool to tear out javascript from browser and put to server lol rofl. 2016 - switch to low-level language, much lower-level than PHP, Ruby and Javascript. Because computers became slow lol.

2019 - switch to PL/1 and raw disk sector addressing because bigdata smoothie silicon googley disrupt the world

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

#116

Post by cloverich »

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}

And as long as new ideas come about (in the form of languages / platforms), people will keep trying, learning, and sharing. Thankfully.

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

#117

Post by 59nadir »

zongitsrinzler wrote: post #53
59nadir wrote: post #49

Earlier quoted context omitted.

> Since the application relies heavily on sharing resources between sockets... Which resources?

Connections are grouped in various ways. A lot of maps, etc. You can't even use a regular int safely, need to use an atomic for that. I'm not bashing Go here, the memory usage is about 3x lower (which was the most important for me). And for a static language it's pretty cool.

Am I understanding you correctly when I assume that you mean you share data across threads?

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

#118

Post by mnutt »

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.

"helper process and have it manage the cache over a socket" is essentially redis, and another thing that introduces latency and can fail.

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

#119

Post by skybrian »

erlich wrote: post #64
spriggan3 wrote: post #30

Earlier quoted context omitted.

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

A big advantage for Go is that the standard library has been stable since 1.0 and there are no plans for breaking changes.

This appears not to be true for lodash.

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

#120

Post by ysolo »

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 the case of next tick deferred callbacks - due to the single-threaded nature of the model. This necessitates passing around context via closures (or god forbid global variables!). The "context" in a threaded language is typically just the stack. With Node's async Promises and equivalents we can trick ourselves into simulating linear program flow, but it's a pale imitation of the real thing.

This got me thinking - why did the single-threaded "green" threading programming model like how the Java JVM was initially implemented all those years ago fall out of favor? It would be as performant as Node presently is but without the difficult async logic for the end user programmer. Async programming and green threads are duals - both use event queues behind the scenes to drive the scheduling. The complexity of the actual I/O and timer event callbacks is hidden from the programmer in green threads. The pseudo "thread" context switches would only be done upon blocking I/O. No need for actual mutexes as the program is still actually single threaded. Stack traces of green threads within a program would be easy to decipher. Computation on a green thread would also block all I/O as it would in Node, but we'd know that going in - no different from Node in that regard. Just the programming model would be simpler.

Post reply on HN