[mlevental]

That's because you write a particular kind of program. Notice that there are no good ORMs or numerical libraries. Both of these are use cases for generics. Of course it doesn't help that the go community is convinced that ORMs are evil (which is just posthoc rationalization for being unable to write one).

[dimgl]

Developers think ORMs are evil because they've had horrible experiences with ORMs in general. I'm one of them. The only ORM that I enjoyed using was Dapper, and it's barely an ORM.

[runevault]

Dapper really is such a weird edge case. You still write all the sql, all it does is the conversion from a type to the input parameters and the returned rows into objects where the row names match the parameters of the class. Frankly I feel like that's the right way to build ORMs in all languages that have the facilities to manage it (and maybe those that don't you pass in a function pointer to do the dumping of rows into type for you)

[throwaway8879]

The sqlx package is a similar Go wrapper around SQL. Very handy for scanning into structs.

[buildzr]

What sort of horrible experiences have you actually had with ORMs? Every time I've used one it's been an absolute joy, I hate repeating myself in my DB, in SQL, in mapping code and again in application code. The main thing I see people complaining about is performance edgecases, but for small and mid scale applications these can never take away the massive DRY principle gain good ORMs provide.

[twodave]

And almost every usage of Dapper relies heavily on generics.

[dimgl]

There's no denying most C# code makes heavy use of generics, but we've deviated from the actual topic. C# is not Go. Far from it.

I'm not advocating for bringing a Dapper-like library to Go. I'm pretty happy with the solutions we have right now to map data coming from a SQL database into structs in Go. I'm commenting specifically on the argument that Go developers don't like ORMs.

[reificator]

> Of course it doesn't help that the go community is convinced that ORMs are evil (which is just posthoc rationalization for being unable to write one).

Yep. I held this opinion before Go came out, only because I couldn't write an ORM in Go.

[mlevental]

i said the go community - not the developer community. you couldn't have had that opinion as a go user before go came out.

[reificator]

But I do still hold that opinion now as a go user. I'm saying I didn't develop it as a result of not being able to write/use an ORM.

Your wholesale dismissal of all go users that don't use ORMs is what I object to. There are a laundry list of reasons to not use them, simplicity being the largest in my eyes. If you're working with simple queries on a small number of tables/views/etc, there's really no reason to bring in a big heavy ORM.

As your usage scales that choice might change, but until then just do the simplest thing that has correct behavior and minimal magic involved.

[kfoo020njdj]

“I can see the value so those that can’t are inferior.”

You basically just post hoc rationalized their indifference for ORMs by making them sound incompetent

As if there are no other arguments for avoiding them that perhaps seem valuable to people that are not you?

It sounds reasonable to me you conjured the hot take, acknowledged it was post hoc rationalization on your part, but posted anyway, projecting your capacity for after the fact rationalizing onto ORM haters in the Go community.

[stouset]

The point wasn't that Go programmers are too incompetent to implement an ORM, it's that they are actually unable to given the limitations of the language.