Live data from Hacker News

Learning Go as a Node.js Developer

nemethgergely.com

41–50 of 82 posts

Re: Learning Go as a Node.js Developer

#41
post #38

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…

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

I've seen teams of Go developers shoot themselves in the foot so many times with their hand-crafted SQL. Yes, they should know SQL and be better. And if they think about it, and focus on it, they are.

But it's the mistakes they don't anticipate making that end up causing impacts on their users. Then they create a fix, but the damage is done.

I think the goal behind a good ORM is not to replace making SQL queries entirely. It's to stop stupid mistakes that result from an uneven distribution of expertise. And if they find some area where performance is particularly sensitive and the ORM is not optimal, they can drop down to raw SQL again.

If your team members all have expertise and your test coverage and code review processes are very thorough, it's probably not necessary. An ORM is not a magic bullet for every team. In the same vein, the dogmatic advice to "always handcraft your SQL" is also not a magic bullet.

Re: Learning Go as a Node.js Developer

#42

Earlier quoted context omitted.

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.

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.

Re: Learning Go as a Node.js Developer

#43

Earlier quoted context omitted.

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)

> some people prefer the framework magic because they want the stuff done faster.

Those people should try being maintenance programmers sometime /curmudgeonly-grumble

Re: Learning Go as a Node.js Developer

#44
post #18

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

To counter this point, I knocked out a web app in Go recently in a few hours. I think the speed of development depends on your familiarity.

Having said that, I would suggest the GP try both. I'm keen to try my hand at Elixir soon.

Re: Learning Go as a Node.js Developer

#45
post #38

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…

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

[deleted]

Re: Learning Go as a Node.js Developer

#46
post #26

Earlier quoted context omitted.

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

Scaling parts of the application independently from each other. If traffic spikes in one part of the application (e.x.: your image categorization web app was posted in a cat forum) more nodes can be added to that one resource to handle the load. Another reason could be worker processes that ran intermittently at midnight every day (e.x.: to email users top pics they missed that day).

Isn't that the whole point of the Erlang/Elixir/OTP actor model and BEAM VM? It seems like many systems with microservice architecture are reinventing that wheel only worse - except in the cases where the system needs to use legacy or polyglot services.

Re: Learning Go as a Node.js Developer

#47
post #14

Earlier quoted context omitted.

> they don't need a dependency manager. For not needing a dependency manager, Go sure has developed an amazing number of them! https://github.com/golang/go/wiki/PackageManagementTools https://github.com/avelino/awesome-go/blob/master/README.md#... In fact, Go probably has the most package managers of any language I've ever seen.

Perhaps everyone coming from other languages who can't imagine a world with a good standard library!

Go's standard library is pretty thin compared with Java and .NET, both with quite good dependency management tools.

Re: Learning Go as a Node.js Developer

#48
post #38

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…

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're working at serious scale, doing custom reporting, or other complex scenarios, they handle 99% of CRUD database operations perfectly well. Wasting time reimplementing an existing tool is quite literally throwing money out the window.

Re: Learning Go as a Node.js Developer

#49
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

I've seen teams of Go developers shoot themselves in the foot so many times with their hand-crafted SQL. Yes, they should know SQL and be better. And if they think about it, and focus on it, they are. But it's the mistakes they don't anticipate making that end up causing impacts on their users. Then they create a fix, but the damage is done. I think the goal behind a good ORM is not to replace making SQL queries enti…

yeah, but... same for any code. A team of coders who don't know javascript will create buggy, insecure Node apps. There's nothing about SQL as a coding language that creates this.

It's more that modern coders are used to not having to learn SQL and trusting the ORM to do the thing for them. So when they encounter actual SQL (usually because they need to break the object table mapping) it's all scary and weird.

Back in the day, of course, we had DBA's (DataBase Administrators) to make sure that application devs who didn't know enough SQL to not make a mess of things, didn't actually make a mess of things. And yes, we hated the DBA's because they were always telling us our SQL sucked. Great training though.

So, yeah, your point is valid, but there's a better solution to that problem: hire a DBA

Re: Learning Go as a Node.js Developer

#50

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…

> yes net/http is nice but there's no router, there's no orm... yes database/sql exists but you know most everyone uses... yes html/template is nice but we're all...

Three fallacies of dependencies: https://www.youtube.com/watch?v=yi5A3cK1LNA

> what modern web app could you write with just the stl?

Lots. You just have to change your frame of mind.

> i know that's not really possible at all because of strong typing

Once you realise the above, you also realise that most of the time you don't need all that fancy stuff and you just write super boring code that works.

Post reply on HN