Gotchas from Two Years with Node
segment.com
Gotchas from Two Years with Node
1–10 of 125 posts
Re: Gotchas from Two Years with Node
#2> At any given time there’s only a single running code block.
> But here… there be dragons.
That's one of the things Erlang solves pretty well. Sometimes I sort of envision it as that robot dog/mule thing that they keep kicking and it gets back up and keeps going.
https://www.youtube.com/watch?v=cNZPRsrwumQ if you have never seen it before.
Re: Gotchas from Two Years with Node
#3"To further avoid event loop problems entirely, we’ve started switching more of our data processing services to Go".
This seems to become a common pattern... start with Node, hit some limits, rewrite microservices in Go.
Re: Gotchas from Two Years with Node
#4> At any given time there’s only a single running code block. > But here… there be dragons. That's one of the things Erlang solves pretty well. Sometimes I sort of envision it as that robot dog/mule thing that they keep kicking and it gets back up and keeps going. https://www.youtube.com/watch?v=cNZPRsrwumQ if you have never seen it before.
I'm sure once they finish migrating Node to Go, they'll migrate Go to Erlang.
Re: Gotchas from Two Years with Node
#5The one problem they use as an example wasn't solved by switching to Go. Go is great but let's be real, parsing and concurrency problems don't just magically go away by switching languages.
Re: Gotchas from Two Years with Node
#6Just curious though, I have seem quite a number of posts in the past year mentioned the switch from Node to Go, is there a pattern here?Why Go in particular?
Re: Gotchas from Two Years with Node
#7The one problem they use as an example wasn't solved by switching to Go. Go is great but let's be real, parsing and concurrency problems don't just magically go away by switching languages.
Concurrency issues don't magically go away by switching to another language, but they have a much better chance of getting cleanly addressed by switching to a language which has explicit/native features as part of its design to help address concurrency issues, via goroutines/channels in this case.
Re: Gotchas from Two Years with Node
#8Just curious though, I have seem quite a number of posts in the past year mentioned the switch from Node to Go, is there a pattern here?Why Go in particular?
> Why Go in particular?
Its the new shiny thing.
Re: Gotchas from Two Years with Node
#9Just curious though, I have seem quite a number of posts in the past year mentioned the switch from Node to Go, is there a pattern here?Why Go in particular?
Go appears to have a similar kind of momentum behind it as Node had/has. It's a small and "familiar" language, so devs pick it up easily, and has a healthy open-source package ecosystem.
It could also just be random chance. People and communities latch onto things for all sorts of reasons.
Re: Gotchas from Two Years with Node
#10The switch from Node to Go seems quite popular right now and it honestly makes me thing there's something wrong with the general perception of Node.
We are currently in a world where we have a huge amount of traffic on almost every web app with just a discrete success, but we still make the mistake to pick a technology that seems "good enough", instead to pick a "great one" because looks slightly harder to manage/learn/deploy. I know that during the early stage, pace is very important and RAILS or Node are easier and faster to handle compare to Scala or Erlang, but sometimes another technology at the beginning would save a lot of headaches and night calls. We still fail at the very early stage to choice the right technology, but nobody is afraid to admit it and to switch, I find this amazing.