Learning Go as a Node.js Developer • Hacker News Board

Re: Learning Go as a Node.js Developer

#31

Post by ingas » Fri, Feb 09, 2018, 5:30 AM UTC

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.

Re: Learning Go as a Node.js Developer

#32

Post by yur83838 » Fri, Feb 09, 2018, 5:30 AM UTC

todd_wanna_code wrote: post #21

mzzter wrote: post #10

Earlier quoted context omitted.

I’d say it depends on what you want to build (disclaimer: I have written a lot of Go but have only read Elixir source). If full stack monolith, use Elixir because of Phoenix; if microservice arch, use Go with gRPC protobufs for messaging. IMO, both languages seem to result in very readable source code; and many examples of how to do either exist on GitHub.

Awesome, one thing, what is the advantage of microservices, to lets say, modular monolith?

The difference is in the network boundaries. I write most of my code as microservices, but it would be incredibly easy to wrap it all up into a single binary.

It's not uncommon for go code to have one binary for separate microservice functions (see OKLog). This way you can change between a microservice, or a monolith (ish) with a CLI flag.

Re: Learning Go as a Node.js Developer

#33

Post by jjoonathan » Fri, Feb 09, 2018, 5:34 AM UTC

marcus_holmes wrote: post #23

mlevental wrote: post #17

Earlier quoted context omitted.

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

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

I still remember the first time I had to pick apart a gigantic chunk of java code and found a big switch statement at the center instead of a web of introspectively discovered implicitly wired reactively chained bean factory factory factories or some such nonsense. The relief was almost palpable.

Re: Learning Go as a Node.js Developer

#34

Post by beckler » Fri, Feb 09, 2018, 5:35 AM UTC

todd_wanna_code wrote: post #20

beckler wrote: post #18

Earlier quoted context omitted.

I built a web app in Go recently, and while it was enjoyable, progress was pretty slow. I eventually decided to change gears and rebuild it in Elixir, and so far I have no regrets. Phoenix is pretty fast, awesome, and powerful. There are a few concepts you have to learn, but overall it's been a much simpler experience and way faster to prototype with.

I am also thinking about going the elixir way, what did you use to get started?

Honestly, I think the phoenix guides cover pretty much everything you would possibly need (https://hexdocs.pm/phoenix/overview.html). Docs for most popular libraries (including phoenix) are pretty high-quality. I would also brush up on the language syntax as well (https://elixir-lang.org/getting-started/introduction.html).

I don't think getting started is hard, but diving into the heavy concepts could be overwhelming. Macros can be weird, and I still have to think through a lot whenever I make a foreign table relation in Ecto, since you have to create the migration (which is a way to build your database with code) AND the changeset (which is basically an elixir object that maps to the table).

Anyways, Elixir is functional, which isn't that difficult. Javascript is partially functional, but if you're used to Java or C++ you'll want to approach it with an open mind. If you've ever used F#, or C# with LINQ before, then you'll be familiar waters.

I bought the Programming Phoenix book, and it does a pretty good job, but with Phoenix 1.3 it's already out-of-date. However, it's still good reference material for the underlying concepts.

This list of open-source phoenix apps has saved my ass a couple times as well. I probably look at changelog.com's source the most since it's by far the most active project here: https://github.com/droptheplot/awesome-phoenix

I know it's not the most helpful information, but truth be told there's no secret to learn it, you just gotta do it and fuck it up a few times to get it right.

Re: Learning Go as a Node.js Developer

#35

Post by yur83838 » Fri, Feb 09, 2018, 5:36 AM UTC

marcus_holmes wrote: post #23

mlevental wrote: post #17

Earlier quoted context omitted.

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

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

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.

Re: Learning Go as a Node.js Developer

#36

Post by akmittal » Fri, Feb 09, 2018, 5:39 AM UTC

marcus_holmes wrote: post #23

mlevental wrote: post #17

Earlier quoted context omitted.

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

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

I see Go community pushing for no framework everywhere. I agree Go std library is good enough but some people prefer the framework magic because they want the stuff done faster.

Community should better be saying try std library if you find it verbose try framework(router+ORM)

Re: Learning Go as a Node.js Developer

#37

Post by rqs » Fri, Feb 09, 2018, 5:58 AM UTC

mlevental wrote: post #17

marcus_holmes wrote: post #5

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 perf…

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

First, I don't think net/http is nice, but you know what's good about Go? It's so modular that you can replace the builtin HTTP server with other one you like (gorilla/http for example) and your code _can_ just continue to work without modification.

And, Go had many third-party Router, ORM, Websocket and Template Engine implementations out there, many of them are also proud to be ... independent, so you're less likely to end up in a Dependency Hell.

Go standard library is not there to force people to use it, rather, it's there to setup a standard so different people can work together more effectively.

So:

> in what sense is the stl really complete? what modern web app could you write with just the stl?

1, It's huge, but not complete;

2, You can actually do it with just Go standard library (No third-party package) if you REALLY wants to. It's not very hygiene though, you will end up wrap many things up for better project structure (And resulting many packages that you might later proudly put on your GitHub page): Use net/http as HTTP server (Request handling and parsing); use net.Dial to connect database and cache (And write their protocol); html/template for outputting rendered HTML landing page; encoding/json for parsing and outputting API request and respond.

Re: Learning Go as a Node.js Developer

#38

Post by donatj » Fri, Feb 09, 2018, 6:09 AM UTC

mlevental wrote: post #17

marcus_holmes wrote: post #5

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 perf…

>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 is totally a router, ServeMux, which while basic is enough for 90% of basic tasks if you structure your requests REST-y.

As for ORM, you should basically never use an ORM, ever. They’re a crutch. Learn SQL, write some basic mappers and your SQL will be so much quicker and more optimized than an ORM can generate. An ORM is literally throwing money out the window.

https://golang.org/pkg/net/http/#ServeMux.Handle

Re: Learning Go as a Node.js Developer

#39

Post by eksemplar » Fri, Feb 09, 2018, 6:14 AM UTC

todd_wanna_code wrote: post #6

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?

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.

Re: Learning Go as a Node.js Developer

#40

Post by donatj » Fri, Feb 09, 2018, 6:18 AM UTC

ralusek wrote: post #3

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.

I myself know I learn better when I write things I have learned down. I have written very similar blog posts myself, a couple of which actually ended up on HN.

It’s a really weird experience writing something you figure no one will ever read, and suddenly one day months later having to field mass criticism.