3 ms·

Sql? It does all the wrong things; singletons, no testability, cgo for implementations, side effects and you have to use every database differently based on th

Sql? It does all the wrong things; singletons, no testability, cgo for implementations, side effects and you have to use every database differently based on their individual semantics. Virtually everyone I've ever spoken to either uses a high level wrapper around the sql library or a no-sql solution. That's the definition of 'stdlib is where packages go to die'. It's not that the API is unusable, it's just basically not used by the community because there are other better things out there...but you're stuck with it forever, because it's there and some people do use it, and changing or removing it would be a breaking change. Anyhow, we're just speculating. Does anyone actually collect metrics about the usage of different parts of the stdlib for any language? Without hard data to back it up, you couldn't really make a strong argument either way.

saysjonathan 10y ago
I didn't see anyone actually mention sql so I'll just assume your first line is to be interpreted as "sql is the counterexample of why Go's standard library is not as great as it may seem." >Virtually everyone I've ever spoken to either uses a high level wrapper around the sql library or a no-sql solution. How does that reflect the quality of the std lib implementation? All the high-level wrappers I've seen still utilize database/sql, they just provide convenience methods on top of the existing functionality. Are people using NoSQL databases because database/sql is so bad or merely because that technology fits their project's requirements? >That's the definition of 'stdlib is where packages go to die'. steveklabnik's example of Ruby XML parsing libraries is a better example of this, if only because the std lib implementations are almost completely ignored by all other gems. Go's database/sql is actively used outside of the std lib to great affect, whether in wrappers and ORMs or in implementing other SQL databases (like Postgres).
ZenoArrow 10y ago
> "Sql? It does all the wrong things; singletons, no testability, cgo for implementations, side effects and you have to use every database differently based on their individual semantics." SQL has its flaws, but it is testable. The testing approaches available vary depending on the implementation. For example, can write unit tests for SQL Server (using tSQLt, to give one example: http://tsqlt.org/ http://tsqlt.org/ ).
- shadowmint 10y ago
  yeah no. If you have an interface and you need a separate test suite for each implementation of that interface, it's a terrible interface.
  - ZenoArrow 10y ago
    The point is, there's nothing inherent in the design of SQL that stops it being testable, it just hasn't reached the SQL standards yet. Plus, there are plenty of ways to test standard SQL, you can easily do so through stored procedures.
    - shadowmint 10y ago
      I'm not talking about SQL in general, I'm talking about the golang sql module. Read this if you think I'm wrong: https://github.com/bradfitz/go-sql-test/blob/master/src/sqltest/sql_test.go#L149 https://github.com/bradfitz/go-sql-test/blob/master/src/sqlt... Great abstraction, right? Love how you have to mangle the raw SQL right? no. It's a bad abstraction. When you test the implementation and you have to know the details of the implementation to test it, that's like, the definition of a bad abstraction. It is what it is. ...and ultimately, we're stuck with it because its part of the standard library. /shrug

saysjonathan 10y ago

I didn't see anyone actually mention sql so I'll just assume your first line is to be interpreted as "sql is the counterexample of why Go's standard library is not as great as it may seem." >Virtually everyone I've ever spoken to either uses a high level wrapper around the sql library or a no-sql solution. How does that reflect the quality of the std lib implementation? All the high-level wrappers I've seen still utilize database/sql, they just provide convenience methods on top of the existing functionality. Are people using NoSQL databases because database/sql is so bad or merely because that technology fits their project's requirements? >That's the definition of 'stdlib is where packages go to die'. steveklabnik's example of Ruby XML parsing libraries is a better example of this, if only because the std lib implementations are almost completely ignored by all other gems. Go's database/sql is actively used outside of the std lib to great affect, whether in wrappers and ORMs or in implementing other SQL databases (like Postgres).

ZenoArrow 10y ago

> "Sql? It does all the wrong things; singletons, no testability, cgo for implementations, side effects and you have to use every database differently based on their individual semantics." SQL has its flaws, but it is testable. The testing approaches available vary depending on the implementation. For example, can write unit tests for SQL Server (using tSQLt, to give one example: http://tsqlt.org/ http://tsqlt.org/ ).

shadowmint 10y ago
yeah no. If you have an interface and you need a separate test suite for each implementation of that interface, it's a terrible interface.
- ZenoArrow 10y ago
  The point is, there's nothing inherent in the design of SQL that stops it being testable, it just hasn't reached the SQL standards yet. Plus, there are plenty of ways to test standard SQL, you can easily do so through stored procedures.
  - shadowmint 10y ago
    I'm not talking about SQL in general, I'm talking about the golang sql module. Read this if you think I'm wrong: https://github.com/bradfitz/go-sql-test/blob/master/src/sqltest/sql_test.go#L149 https://github.com/bradfitz/go-sql-test/blob/master/src/sqlt... Great abstraction, right? Love how you have to mangle the raw SQL right? no. It's a bad abstraction. When you test the implementation and you have to know the details of the implementation to test it, that's like, the definition of a bad abstraction. It is what it is. ...and ultimately, we're stuck with it because its part of the standard library. /shrug