4 ms·
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 c
by mlevental 7y ago
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 7y agoDevelopers 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 7y agoDapper 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 7y agoThe sqlx package is a similar Go wrapper around SQL. Very handy for scanning into structs.
- buildzr 7y agoWhat 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 7y agoAnd almost every usage of Dapper relies heavily on generics.
- dimgl 7y agoThere'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 7y ago> 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 7y agoi said the go community - not the developer community. you couldn't have had that opinion as a go user before go came out.
- reificator 7y agoBut 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 7y ago“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 7y agoThe 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.