The biggest difference I see: the author immediately reached for a framework instead of checking out the standard library.<p>In Node, the standard library is effectively non-existent, so Node devs get trained and acclimatised to dependencies.<p>In Golang, dependencies are minimised. Everyone tries to stick to the standard library as much as possible. Because the standard library is so good, for most projects this is perfectly reasonable.<p>I'd say the first thing every Node dev should know when learning Go is that they don't need a dependency manager. If you can't do it with the standard library then you're probably doing it wrong (at least until you've got some experience with the library).
Is there really anything else in Go than "pretty good standard library". Looking at this and many other Go discussion it seems there isn't.<p>I've been using Go for a while now and while standard library is ok and definitely better than the one in Node.js and I really like strong typing, I still have to say Go is probably one of the worst programming languages I have ever seen in my life.<p>Error handling is from the stone age, no support for generics, no support for functional programming, no real enum but instead "a hack" you have build by yourself, dependency management without versions etc.<p>Also the hyped features such as channels are nice, but nothing a simple Rx-library couldn't do.<p>Due to the language limitations it's also nearly impossible to write elegant code with Go. If you take a look at any codebase, build by experienced senior developer or junior dev straight out of college/high school the code is almost always the same:<p>Tons of "if err != nil" and for loops.
It's only natural that coming from such terrible mess as javascript ecosystem author is trying to solve problems he encountered in past.<p>I wrote comment to him:<p>It's only natural that you're trying to find solutions for problems you encountered in past.<p>But exploring new technology this way leads to absolutely natural mistakes.
You're are worring about wrong things.<p>Dependency management
This problem is not (and never was) in such terrible scale as in javascript.<p>You can forget about this problem while you learn go.
I suppose that dep will be released offically when you will really need this.<p>Asynchronicity
I did the same mistake as you: I thought that channels and messages are similar to Actor pattern in Erlang, Akka.<p>Don't try to think about promises, futures and other abstraction when you programming in go.<p>In fact, you need learn synchronicity now, golang already asynchronous in its nature.
So I am trying to move away from NodeJs for my next project and I can't decide between Elixir and Go. Can't decide what to choose, any idea if there is any advantage for a noob to learn one or the other?
Why would this author feel compelled to write an article about this if they're just learning? That asynchronous Go code which is meant to be analogous to the handful of Node lines looks super verbose. Because the author has claimed a lack of expertise, I have no idea if that is actually the correct way to write something like that out...but it certainly doesn't make Go look good.