Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learning Go as a Node.js Developer

nemethgergely.com

Post reply on HN
Print view View original

51–60 of 82 posts

Re: Learning Go as a Node.js Developer

#51

Post by leaveyou »

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 agree with everything you said except the websocket.. the best websocket lib for golang until now is https://github.com/gorilla/websocket

Re: Learning Go as a Node.js Developer

#52

Post by masklinn »

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 Node, the standard library is effectively non-existent, so Node devs get trained and acclimatised to dependencies.

Have you ever actually taken a look at it? https://nodejs.org/api/index.html

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

Meh. The Python stdlib has been considered "good" for a long time[0], but the last few years people commonly reach out for external dependencies.

It's not because the stdlib has gotten less good (the opposite), it's because the experience of publishing and using external dependencies has significantly improved.

> I'd say the first thing every Node dev should know when learning Go is that they don't need a dependency manager.

They do, they just don't have one. Which is why people tend not to bring in external dependencies: bringing in external dependencies in Go is a traumatic experience, much as it used to be in Python a few years back.

[0] in fact this exact same argument was relatively common in the mid-to-late aughts, Java developers dipping their toes into Python would complain about the state of dependency management and get told that the stdlib is so good you don't need dependency management, the stdlib is almost all you need and there's no need for advanced dependency management for just one or two dependencies…

Re: Learning Go as a Node.js Developer

#53

Post by 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.

Re: Learning Go as a Node.js Developer

#54

Post by marcus_holmes »

manigandham wrote: post #48
donatj wrote: post #38

Earlier quoted context omitted.

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

> An ORM is literally throwing money out the window. What? Definitely the opposite. First of all, ORMs are just tools, as the name implies they are object-relational-mappers. That's it, you writing SQL to translate to objects is just you writing an ORM, although a very tiny one. Modern ORM frameworks are incredibly more productive with better security and reliability than hand-crafted SQL and mapping code. Unless you…

> That's it, you writing SQL to translate to objects is just you writing an ORM, although a very tiny one.

No. Absolutely not. This is the fundamental mess that ORMS create.

Objects DO NOT map cleanly to tables.

Eventually your code discovers this, and suddenly it's a world of pain because the ORM can't handle it.

Re: Learning Go as a Node.js Developer

#55

Post by thesmallestcat »

eksemplar wrote: post #39
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 unavoid…

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

Re: Learning Go as a Node.js Developer

#56

Post by oneweekwonder »

masklinn wrote: post #52
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 Node, the standard library is effectively non-existent, so Node devs get trained and acclimatised to dependencies. Have you ever actually taken a look at it? https://nodejs.org/api/index.html > 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. Meh. The Python stdlib h…

> much as it used to be in Python a few years back.

few years back being pre-2011, with pep 405[0] and virtualenv[1] solving most of the nostalgic py dep hell problems.

venv's been a option since 2007, only getting pep'ed later?

[0] https://www.python.org/dev/peps/pep-0405/

[1] https://virtualenv.pypa.io/en/stable/changes/#id54

Re: Learning Go as a Node.js Developer

#57

Post by masklinn »

oneweekwonder wrote: post #56
masklinn wrote: post #52

Earlier quoted context omitted.

> In Node, the standard library is effectively non-existent, so Node devs get trained and acclimatised to dependencies. Have you ever actually taken a look at it? https://nodejs.org/api/index.html > 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. Meh. The Python stdlib h…

> much as it used to be in Python a few years back. few years back being pre-2011, with pep 405[0] and virtualenv[1] solving most of the nostalgic py dep hell problems. venv's been a option since 2007, only getting pep'ed later? [0] https://www.python.org/dev/peps/pep-0405/ [1] https://virtualenv.pypa.io/en/stable/changes/#id54

virtualenv solved conflicting dependencies but pip is what made installing & managing them convenient. I see many people who use pip without virtualenvs.

Re: Learning Go as a Node.js Developer

#58

Post by oneweekwonder »

masklinn wrote: post #57
oneweekwonder wrote: post #56

Earlier quoted context omitted.

> much as it used to be in Python a few years back. few years back being pre-2011, with pep 405[0] and virtualenv[1] solving most of the nostalgic py dep hell problems. venv's been a option since 2007, only getting pep'ed later? [0] https://www.python.org/dev/peps/pep-0405/ [1] https://virtualenv.pypa.io/en/stable/changes/#id54

virtualenv solved conflicting dependencies but pip is what made installing & managing them convenient. I see many people who use pip without virtualenvs.

True, in my limited experience venv and pip goes hand in hand. But I can see use cases where you use them apart, more so with pip then venv.

Initial pip release was also 2011. Now I wonder what I used pre-pip?!

edit: easy_install, doh!

Re: Learning Go as a Node.js Developer

#59

Post by manigandham »

marcus_holmes wrote: post #54
manigandham wrote: post #48

Earlier quoted context omitted.

> An ORM is literally throwing money out the window. What? Definitely the opposite. First of all, ORMs are just tools, as the name implies they are object-relational-mappers. That's it, you writing SQL to translate to objects is just you writing an ORM, although a very tiny one. Modern ORM frameworks are incredibly more productive with better security and reliability than hand-crafted SQL and mapping code. Unless you…

> That's it, you writing SQL to translate to objects is just you writing an ORM, although a very tiny one. No. Absolutely not. This is the fundamental mess that ORMS create. Objects DO NOT map cleanly to tables. Eventually your code discovers this, and suddenly it's a world of pain because the ORM can't handle it.

And yet this is reality: again 99% of applications manipulate objects in code, persist the data in relational databases, and map rows to objects just fine. Some mapping is necessary anyway, and from my experience modern ORM frameworks actually handle complex objects and relations much better than fragile hand-written code.

As mentioned, if you're in the 1% scenario where this approach doesn't work then you already know you should be using something else. Not knowing when to use what is a far bigger issue than any problem an ORM can cause.

Re: Learning Go as a Node.js Developer

#60

Post by masklinn »

oneweekwonder wrote: post #58
masklinn wrote: post #57

Earlier quoted context omitted.

virtualenv solved conflicting dependencies but pip is what made installing & managing them convenient. I see many people who use pip without virtualenvs.

True, in my limited experience venv and pip goes hand in hand. But I can see use cases where you use them apart, more so with pip then venv. Initial pip release was also 2011. Now I wonder what I used pre-pip?! edit: easy_install, doh!

Yeah easy_install, which theoretically worked (kinda), but alongside pip there was also the overall pypa effort (both marketing and technical) to make the whole thing work e.g. update or even fork the more abstruse projects such that they could actually be installed via pip. IIRC that was the primary reason for Pillow forking PIL.
Post reply on HN