4 ms·

"We don't need generics" "We don't need exceptions" "We don't need ORMs"

by midrus 6y ago

coldtea 6y ago
2 out of 3 right ain't bad. We really don't need ORMs
- midrus 6y ago
  Yep, I can see at work how fantastic are those hand written sql scripts wrapped in bash to run migrations, and those magnific joins and manual mapping of dates. That's great, until you realize you have an actual product to build.
  - coldtea 6y ago
    Well, no ORM != bash. And no ORM != manual mapping of dates. All kinds of drivers have custom adaptors for data types. (Also a query builder is not an ORM). >That's great, until you realize you have an actual product to build. That's exactly the problem with ORMs. You get worse SQL generated under the scenes, with worse performance, and less control. It's just hidden under the carpet. Plus, if you build your product with heavy domain objects in 2000s OO-style you're doing it wrong. And if you don't, and use, e.g. data classes and record structures, then you don't need an ORM since there's no "O" to map too.
    - midrus 6y ago
      All of this is an immense wheel reinvention, and the SQL I'm seeing is actually far worse than what ActiveRecord or Django's ORM would generate. Also, talking about such a low level performance issues makes me think we're already talking about very different problems. Maybe you're working for Google or Amazon or a pretty performance heavy application. Then ok, I agree with you. But my disconfort is with most startups, and most average companies chosing Go and doing all of this reinvention when what they are doing is basic CRUD for a web app that has less than 100 reqs a day. For the use cases I've seen of Go so far, the bottleneck was caused by using it, and it's ecosystem, because the slowest part of the system is the development time and the need to rebuild from scratch a lot of things you get for free otherwise.
    - oblio 6y ago
      > And no ORM != manual mapping of dates. All kinds of drivers have custom adaptors for data types. Yes, because that's what you want or need, your database drivers to implement custom adapters for data types. What do you do when your app supports multiple database types? What do you do when you have to switch driver for whatever reason? ORM/user friendly query builders are a layer on top of the driver, the driver shouldn't contain them...
geodel 6y ago
However you do need a different language.

"We don't need generics" "We don't need exceptions" "We don't need ORMs"

by midrus 6y ago

"We don't need generics" "We don't need exceptions" "We don't need ORMs"

coldtea 6y ago

2 out of 3 right ain't bad. We really don't need ORMs

midrus 6y ago
Yep, I can see at work how fantastic are those hand written sql scripts wrapped in bash to run migrations, and those magnific joins and manual mapping of dates. That's great, until you realize you have an actual product to build.
- coldtea 6y ago
  Well, no ORM != bash. And no ORM != manual mapping of dates. All kinds of drivers have custom adaptors for data types. (Also a query builder is not an ORM). >That's great, until you realize you have an actual product to build. That's exactly the problem with ORMs. You get worse SQL generated under the scenes, with worse performance, and less control. It's just hidden under the carpet. Plus, if you build your product with heavy domain objects in 2000s OO-style you're doing it wrong. And if you don't, and use, e.g. data classes and record structures, then you don't need an ORM since there's no "O" to map too.
  - midrus 6y ago
    All of this is an immense wheel reinvention, and the SQL I'm seeing is actually far worse than what ActiveRecord or Django's ORM would generate. Also, talking about such a low level performance issues makes me think we're already talking about very different problems. Maybe you're working for Google or Amazon or a pretty performance heavy application. Then ok, I agree with you. But my disconfort is with most startups, and most average companies chosing Go and doing all of this reinvention when what they are doing is basic CRUD for a web app that has less than 100 reqs a day. For the use cases I've seen of Go so far, the bottleneck was caused by using it, and it's ecosystem, because the slowest part of the system is the development time and the need to rebuild from scratch a lot of things you get for free otherwise.
  - oblio 6y ago
    > And no ORM != manual mapping of dates. All kinds of drivers have custom adaptors for data types. Yes, because that's what you want or need, your database drivers to implement custom adapters for data types. What do you do when your app supports multiple database types? What do you do when you have to switch driver for whatever reason? ORM/user friendly query builders are a layer on top of the driver, the driver shouldn't contain them...

geodel 6y ago

However you do need a different language.