> (unless one actually feels they can write something
> better than, say ActiveRecord, from scratch).
The point is that ActiveRecord's method of modeling, especially when it comes to dynamically mapping language constructs to a storage layer via SQL, is too implicit. Too costly. Actively harmful! The point is to get developers to stop thinking in terms of ORM abstractions, and start thinking in terms of the actual transforms and manipulations that are occurring.
> You certainly wouldn't use it for an MVP.
I think you overestimate the cost of pressing buttons on your keyboard.
The point is to get developers to stop thinking in terms of ORM abstractions, and start thinking in terms of the actual transforms and manipulations that are occurring.
Isn't the point also to encourage code re-use and abstraction? I mean, golang has packages for a reason. I suppose my question is more along the lines of whether we'll ever see a package in go that would standardize the data-object divide or whether this will always be a "roll your own" domain?
I think you overestimate the cost of pressing buttons on your keyboard.
> I suppose my question is more along the lines of whether
> we'll ever see a package in go that would standardize
> the data-object divide
There is no lucid standardization possible for the data-object divide, in Go or any other language. Too much depends on the semantics of the object and data system. Or, rather said: that standardization (that abstraction) is SQL itself.
what sagichmal is basically saying without saying it is go cant do what you want, you just cant write a generic Active Record framework in go,nor a generic data mapper.
the right approach ,when a language cant do what you want, IS code generation with a third party dynamic language.
If you know ruby for instance, ruby excels at code generation,so you could generate go code from a SQL schema or any manifest,then augment it with custom code in another go file that import the generated code.
