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

61–70 of 82 posts

Re: Learning Go as a Node.js Developer

#61

Post by marcus_holmes »

lloeki wrote: post #50
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…

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

>> you just write super boring code that works.

This. This is the essence of Go to my mind :)

Re: Learning Go as a Node.js Developer

#62

Post by marcus_holmes »

manigandham wrote: post #59
marcus_holmes wrote: post #54

Earlier quoted context omitted.

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

I think it's more 99% of databases are warped horribly to pretend that objects map to tables.

If you throw away the concept that anything in your database has to map to anything in your code base, then you design better databases. Different databases, more to the point.

Re: Learning Go as a Node.js Developer

#63

Post by marcus_holmes »

illuminati1911 wrote: post #53

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

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

Re: Learning Go as a Node.js Developer

#64

Post by marcus_holmes »

leaveyou wrote: post #51
marcus_holmes wrote: post #23

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

It's getting to the point where the Gorilla packages could be considered part of the standard library ;)

I agree, but the point is that you can do this with just the "almost official" package. It's not like you have to use the gorilla package because there's no standard library package.

Re: Learning Go as a Node.js Developer

#65

Post by timrichard »

heroprotagonist wrote: post #41
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

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…

Just to mention a third way - I've been happy with a QueryBuilder on recent projects.

The DB access parts of the code look similar to the rest of the codebase, rather than a chunk of text embedded that looks like ransom note (kidding - I know caps aren't mandatory). Enough fine control to closely influence the generated query. No real performance penalty. There's also a good mocking library available for tests.

Re: Learning Go as a Node.js Developer

#66

Post by imtringued »

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.

Mapping objects to tables and back is a solved problem.

Let me tell you one thing that isn't solved yet: Serialization of arbitrary objects to json and back.

How do you deal with two refererences pointing to the same object? Duplicate the data?

What about circular references? Give each object an id and save a symbolic reference?

What about polymorphism? Should a json array be turned into an array or an list or a json map turned into an object or a hashmap?

You need a type discriminator attribute.

ORMs have already solved those problems well.

The actual problem is that databases are distributed systems and you still have to write queries with the still 10 times better querybuilder of your ORM. Just try writing raw JDBC queries. It's so painful I'd still use the ORM even if my project only uses native SQL queries via the ORM api.

You will probably now ask what's the point of ORMs if you still have to write queries? Well, it's in the damn name. Object relational mapper. It maps stuff. It's not advertised as WYQFY. "Writes your queries for you"

Re: Learning Go as a Node.js Developer

#67

Post by [deleted] »

thesmallestcat wrote: post #55
eksemplar wrote: post #39

Earlier quoted context omitted.

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.

[deleted]

Re: Learning Go as a Node.js Developer

#68

Post by autarch »

yur83838 wrote: post #28
autarch wrote: post #24

Earlier quoted context omitted.

I wouldn't exactly call Go's standard library _good_. It's got a lot of stuff in it, which is nice, but the API design ranges from excellent (net/http) to "how much crack?!" (time.Format and .Parse) to not-quite-sufficient (various packages). And of course, standard library APIs age with time. Perl and Python are good examples. Both ship with packages that were really good in their day, but have long since been super…

> Go's refusal to embrace this is a huge pain point. Dep is a decent start, but without a community actually doing things like releases, changelogs, and all the other things that go into a solid ecosystem, it's a half measure at best. Go has indeed embraced it and is working on `dep` the officially sanctioned dependency manager. It's under the official golang github repository.

Yes, I know. But that doesn't help at all with the lack of releases, changelogs, etc. As I said, it's a decent start.

Re: Learning Go as a Node.js Developer

#69

Post by ta2384428 »

autarch wrote: post #68
yur83838 wrote: post #28

Earlier quoted context omitted.

> Go's refusal to embrace this is a huge pain point. Dep is a decent start, but without a community actually doing things like releases, changelogs, and all the other things that go into a solid ecosystem, it's a half measure at best. Go has indeed embraced it and is working on `dep` the officially sanctioned dependency manager. It's under the official golang github repository.

Yes, I know. But that doesn't help at all with the lack of releases, changelogs, etc. As I said, it's a decent start.

https://github.com/golang/dep/releases

https://github.com/golang/dep/graphs/commit-activity

Agreed that it's a decent start, however I disagree with the lack of releases. If you look at the git history there is a lot of activity in it.

Re: Learning Go as a Node.js Developer

#70

Post by badthingfactory »

thesmallestcat wrote: post #55
eksemplar wrote: post #39

Earlier quoted context omitted.

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.

I think it would probably work out pretty well... for the candidate.
Post reply on HN