
Learning Go as a Node.js Developer - skellertor
https://nemethgergely.com/learning-go-as-a-nodejs-developer/
======
marcus_holmes
The biggest difference I see: the author immediately reached for a framework
instead of checking out the standard library.

In Node, the standard library is effectively non-existent, so Node devs get
trained and acclimatised to dependencies.

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.

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

~~~
mlevental
>In Golang, dependencies are minimised. Everyone tries to stick to the
standard library as much as possible.

i don't understand this. yes net/http is nice but there's no router, there's
no orm (yes i know that's not really possible at all because of strong
typing), yes database/sql exists but you know most everyone uses at least sqlx
and e.g. lib/pq. yes html/template is nice but we're all doing SPAs now
anyway. okay there's logging but e.g. no websockets. so in what sense is the
stl really complete? what modern web app could you write with just the stl?

~~~
marcus_holmes
You don't need a router (especially for an SPA with client-side routing). If
you've got less than 20 or so routes, then a big switch statement is all the
routing you _need_. Learning to write "proper" logic around routes instead of
parsing them with regexes was a learning milestone for me.

You don't need an ORM. Mapping database tables to objects directly is a really
bad idea. Write SQL, it's easy, simple and cheap. Yes, you'll repeat yourself.
Golang generally prefers some repetition to some dependency.

You don't need middleware. Once you get used to handling routes as logic, then
the need for middleware kinda vanishes.

You can use the semi-official google websockets package [0]. It's borderline
whether this could be considered part of the standard library or not (I use
the google uuid package all the time for the same reason). I believe there's
an intention to include these packages in the standard library at some point,
probably Go v2.

Try it out, it's liberating.

0:
[https://godoc.org/golang.org/x/net/websocket](https://godoc.org/golang.org/x/net/websocket)

~~~
yur83838
You don't need a router, but it is much more readable with one.

You don't need middleware, but it is much more readable with r.Use(jwtVerify)
then writing a deeply nested half router with logic.

If you're running a single endpoint, then the router is adding zero value.

~~~
dithering
Readability is, I think, a function of your expectations. If you're used to
seeing a particular incantation, it's readable. Personally (emphasis on the
personally, which is my point), I don't think it gets much more readable that
a great big switch statement.

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

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.

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.

Also the hyped features such as channels are nice, but nothing a simple Rx-
library couldn't do.

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:

Tons of "if err != nil" and for loops.

~~~
marcus_holmes
Yes. Go is all about writing simple, boring, code that works (to paraphrase
another comment here). And works really fast.

~~~
flavio81
>boring

Not boring. Just "full of boilerplate" which also means that it will be a
nightmare to maintain at a certain point of the lifecycle.

------
ingas
It's only natural that coming from such terrible mess as javascript ecosystem
author is trying to solve problems he encountered in past.

I wrote comment to him:

It's only natural that you're trying to find solutions for problems you
encountered in past.

But exploring new technology this way leads to absolutely natural mistakes.
You're are worring about wrong things.

Dependency management This problem is not (and never was) in such terrible
scale as in javascript.

You can forget about this problem while you learn go. I suppose that dep will
be released offically when you will really need this.

Asynchronicity I did the same mistake as you: I thought that channels and
messages are similar to Actor pattern in Erlang, Akka.

Don't try to think about promises, futures and other abstraction when you
programming in go.

In fact, you need learn synchronicity now, golang already asynchronous in its
nature.

------
sghiassy
Super helpful to learn about Go using my existing understanding of NodeJS.
Keep it up! Thx

------
todd_wanna_code
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?

~~~
eksemplar
I don’t see why you move away from Node unless it was for a JAVA spring boot
or .net core, especially now that node has actually begun to enter real world
usage and enterprise on a large scale.

Then again I would have said something similar about picking up Node in the
earlier days, so who knows.

I doubt Go and Ekixir will ever gain the same reach Node has though. Node has
the advantage of JavaScript being an unavoidable part of your web stack, so
it’ll always have value. With more and more IoT picking up Node as well, it
has a bright future.

Given the two choices, I’d go with Elixir. Golang is hyped in America, but it
has really terrible production times and isn’t really good at anything except
a few use cases.

This won’t be a popular opinion, but my context is Danish enterprise, and I’ve
never seen anyone hire a Go or Elixir programmer, and I honestly doubt I ever
will because the majority of our backend workforce is either JAVA or .Net.

Learning new tech is great of course, but I’d rather hire someone who was
really great at one particularly stack than someone who was mediocre at
multiple. Anyone can make a simple web-app in Go, Node, Elixir, Django, Asp or
Java, but what I would need my hires to do was things like OIOSAML
authentication with ADFS, and if you can’t do that because you learned Go
instead of playing around with passport.js, you’d quite honestly not get
hired.

~~~
thesmallestcat
Let us know how a passport.js hiring filter works out long-term.

~~~
badthingfactory
I think it would probably work out pretty well... for the candidate.

------
Teeer
Oh boy, another learning ___ as a ____ developer blog post.

~~~
dang
Could you please not post snarky dismissals to this site? We're trying for
better than that here.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

[https://news.ycombinator.com/newswelcome.html](https://news.ycombinator.com/newswelcome.html)

~~~
Teeer
I'm sure you're also trying for better content. I'll continue to embrace my
displeasure for posts like these, thank you very much.

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

~~~
gouggoug
> Why would this author feel compelled to write an article about this if
> they're just learning?

Why wouldn't they? They specifically claim lack of expertise, and that sets
the expectations for the reader.

The author is just telling their story about learning Go coming from
javascript/nodejs. Whether or not you like the book doesn't mean it shouldn't
have been written.

