25 ms·

I wish more programming languages provided interfaces for building libraries around the std library like what Go does. It makes using libraries a lot better bec

I wish more programming languages provided interfaces for building libraries around the std library like what Go does. It makes using libraries a lot better because you aren't dependent on that library as long as it uses the std library interface. This is huge for things like database drivers which might become outdated or not support certain features. In Go switching database drivers in as simple as importing the new library. You dont have to change your code. In rust for example you have to go out and pick a database driver and no two libraries will work the same. If you pick one postgres library and it becomes outdated you have to go rewrite you code to support the next one to move too. This is why I would never use Rust, or Zig for being things like http servers.

jtanza 3y ago
As someone who only has some minor experience with Go, can you maybe elaborate a bit on what you mean by the stdlib providing such interfaces? I don’t recall any such paradigm being called out when first learning the language and it sounds pretty interesting.
- 2h 3y ago
  https://github.com/mattn/go-sqlite3/blob/master/_example/simple/simple.go https://github.com/mattn/go-sqlite3/blob/master/_example/sim... notice that the SQLite package isn't used directly, its only imported to handle the database behind the scenes. all the actual code is written using only the standard library
themerone 3y ago
Python, Java, and all of the .NET language have standardized database APIs.
- xyproto 3y ago
  Go also have standardized HTTP handlers, and a standardized io.Writer interface for writing to anything, like a file, buffer or a HTTP reply.
- impulser_ 3y ago
  Yeah, but Go provides this for almost everything in the STD. io, networking, http, sql, and so on.
  - slimsag 3y ago
    If you are familiar with Go, you're gonna be at home with Zig's standard library in general. `std.io.writer`, `std.io.reader`, `std.io.multiWriter`, etc. are all there and pretty similar to Go's interfaces.
  - pjmlp 3y ago
    It still fails short of GUIs and full blown Web frameworks, messaging, like the above.
    - themerone 3y ago
      A lot of people in the Go community consider web frameworks to be an anti-pattern. I haven't done any web stuff in Go, but it definitely looks like the standard library is much better suited than any other language.
andrewchambers 3y ago
While in general I agree, database libs are probably the worst example of this - in practice you can't just swap sqlite for postgres or mysql. I usually avoid the generic driver wherever possible and use one specific to my database.
- impulser_ 3y ago
  You actually can, you might have to update some of your queries but if you use basic SQL queries you can switch drivers without changing code.
  - ilyt 3y ago
    SQLite to Postgres ? maybe Postgres to SQLite ? Maybe too Any of those to MySQL ? Yeah nah I got bitten way too many times by that. And massively surprised that SQLite had some features MySQL didn't...
  - chatmasta 3y ago
    Parts of the library are interchangeable, but inevitably much of it is not. A Postgres and SQLite client might be able to share some query parsing logic between the two databases, but the wire protocol (or lack thereof for SQLite) is not the same, nor is the exact sub/super-set of the SQL standard implemented by each. Basically the only code you could reliably share is an AST parser for the most common subset of the SQL standard that's implemented by both.
    - riceart 3y ago
      Database client libraries typically don’t parse SQL.
      - chatmasta 3y ago
        Yeah, that's true, so that's one less feature they'd be able to share. Unless you're creating an ORM, there's not much left aside from connecting to the database (different for all of them), sending packets (different for all of them), and maybe parameterizing queries. So basically you can make a query builder. Then of course you can have "drivers" for each database, but I'd consider that philosophically different from using the same library "without switching code" (IMO separate drivers implies "switching code" since each driver needs to be maintained separately and depends on a different upstream dependency).
anonymoushn 3y ago
In Go if you'd like to make an interface-compatible database driver, you have to construct structs with non-exported fields from another package using unsafe.
- impulser_ 3y ago
  database/sql provides a generic interface for SQL which drivers use to build their libraries. You can switch from one postgres driver like pq to pgx easily because they both support database/sql.
  - ibraheemdev 3y ago
    Except pgx recommends using their native interface, not database/sql, for performance and extra features [0], so it's not that simple in practice. [0]: https://github.com/jackc/pgx#choosing-between-the-pgx-and-databasesql-interfaces https://github.com/jackc/pgx#choosing-between-the-pgx-and-da...
lmm 3y ago
> I wish more programming languages provided interfaces for building libraries around the std library like what Go does. It makes using libraries a lot better because you aren't dependent on that library as long as it uses the std library interface. > This is huge for things like database drivers which might become outdated or not support certain features. In Go switching database drivers in as simple as importing the new library. You dont have to change your code. The effect is that every database driver becomes outdated and doesn't support certain features, instead of just a few. Python people have a saying that the standard library is where modules go to die. Java's database drivers massively lag behind (e.g. there's still no good async support for most of them), because JDBC is a lowest common denominator that every driver has to be dumbed down to, but is established enough that it sucks all the oxygen away from any efforts to write better drivers. Far better to keep the standard library small and allow modules to update on their own terms and their own schedule. If the library you're using does what you need, you can stick with it, but a better alternative (which always means a new interface in practice - the idea that you can make substantial improvement without changing the interface is mostly a myth, because the interface is the most important part of a library) can appear and compete on its merits, and if the improvements are worth migrating to then it will win out.
- alfiedotwtf 3y ago
  Exactly. Perl had BerkleyDB as part of Core, as well as CGI. How's that going for the Perl footprint!
- born-jre 3y ago
  one approcach with golang is make interface that can be leaked if you really want, you will be using standard interface 99% but if you need sth not provided by abstraction you can ask for underlying impl `db.Driver()` and cast to appropriate type.
- lenkite 3y ago
  > Java's database drivers massively lag behind (e.g. there's still no good async support for most of them), Very Hard Disagree. JDBC is pretty amazing actually. Thats why you find so many Database tools and wizards written in Java as opposed to Rust. Regarding async - With Java 19 virtual threads , you have newer versions of JDBC drivers support async with none to minimal changes. Example: https://medium.com/oracledevs/introduction-to-oracle-jdbc-21c-driver-support-for-virtual-threads-189b918c56f4 https://medium.com/oracledevs/introduction-to-oracle-jdbc-21... I am very, very glad that human civilisation standardised on one system for gears instead of every manufacturer making their own special snowflake.
paulddraper 3y ago
> In Go switching database drivers in as simple as importing the new library. Neat! Kinda like Java. (JDBC) Kinda like C#. (IDb) Kinda like Python. (DB-API) Kinda like PHP. (PDO) Kinda like Perl. (DBI) Kinda like C/C++. (ODBC) Of course, you work as the lowest common denominator and have abstractions that don't quite match the implementation. And let's be honest, how often do you switch databases. But yeah this is very common. --- I'd argue in practice, Java follows your advice the most of any community: * JDBC * Servlets * SLF4J (not technically stdlib but very common)
fzeindl 3y ago
> I wish more programming languages provided interfaces for building libraries around the std library like what Go does. Java does, but apart from JDBC for databases, and the servlet-API, I haven't seen many cases where that really improved the world of programming. Java-EE relied heavily on such abstractions, but nowadays those would be replaced by simpler, less abstract constructs with less redirections. > This is huge for things like database drivers which might become outdated or not support certain features. In Go switching database drivers in as simple as importing the new library. You don't have to change your code. Database drivers are an abstraction that tends to leak it's underlying technology very fast. The idea of just being to swap your database out under the hood is neat, but generally holds only for simple projects. Also the abstraction that helps you here is SQL really, not the driver.
- pjmlp 3y ago
  Java EE isn't gone away, it is the foundation of all modern Java frameworks, via Jakarta EE renaming and Microprofile. Spring, Quarkus, Helidon, Liberty, Wildfly, TomEE, Payara all support it. It turns out such standards are quite valuable for the industry at scale, instead of playing tetris with third party library stuff of various quality.
dragonwriter 3y ago
> I wish more programming languages provided interfaces for building libraries around the std library like what Go does. It makes using libraries a lot better because you aren't dependent on that library as long as it uses the std library interface. So, standard interfaces, or dynamic or structural typing? Lots of languages have those (some all three.)

jtanza 3y ago

As someone who only has some minor experience with Go, can you maybe elaborate a bit on what you mean by the stdlib providing such interfaces? I don’t recall any such paradigm being called out when first learning the language and it sounds pretty interesting.

2h 3y ago
https://github.com/mattn/go-sqlite3/blob/master/_example/simple/simple.go https://github.com/mattn/go-sqlite3/blob/master/_example/sim... notice that the SQLite package isn't used directly, its only imported to handle the database behind the scenes. all the actual code is written using only the standard library

themerone 3y ago

Python, Java, and all of the .NET language have standardized database APIs.

xyproto 3y ago
Go also have standardized HTTP handlers, and a standardized io.Writer interface for writing to anything, like a file, buffer or a HTTP reply.
impulser_ 3y ago
Yeah, but Go provides this for almost everything in the STD. io, networking, http, sql, and so on.
- slimsag 3y ago
  If you are familiar with Go, you're gonna be at home with Zig's standard library in general. `std.io.writer`, `std.io.reader`, `std.io.multiWriter`, etc. are all there and pretty similar to Go's interfaces.
- pjmlp 3y ago
  It still fails short of GUIs and full blown Web frameworks, messaging, like the above.
  - themerone 3y ago
    A lot of people in the Go community consider web frameworks to be an anti-pattern. I haven't done any web stuff in Go, but it definitely looks like the standard library is much better suited than any other language.

andrewchambers 3y ago

While in general I agree, database libs are probably the worst example of this - in practice you can't just swap sqlite for postgres or mysql. I usually avoid the generic driver wherever possible and use one specific to my database.

impulser_ 3y ago
You actually can, you might have to update some of your queries but if you use basic SQL queries you can switch drivers without changing code.
- ilyt 3y ago
  SQLite to Postgres ? maybe Postgres to SQLite ? Maybe too Any of those to MySQL ? Yeah nah I got bitten way too many times by that. And massively surprised that SQLite had some features MySQL didn't...
- chatmasta 3y ago
  Parts of the library are interchangeable, but inevitably much of it is not. A Postgres and SQLite client might be able to share some query parsing logic between the two databases, but the wire protocol (or lack thereof for SQLite) is not the same, nor is the exact sub/super-set of the SQL standard implemented by each. Basically the only code you could reliably share is an AST parser for the most common subset of the SQL standard that's implemented by both.
  - riceart 3y ago
    Database client libraries typically don’t parse SQL.
    - chatmasta 3y ago
      Yeah, that's true, so that's one less feature they'd be able to share. Unless you're creating an ORM, there's not much left aside from connecting to the database (different for all of them), sending packets (different for all of them), and maybe parameterizing queries. So basically you can make a query builder. Then of course you can have "drivers" for each database, but I'd consider that philosophically different from using the same library "without switching code" (IMO separate drivers implies "switching code" since each driver needs to be maintained separately and depends on a different upstream dependency).

anonymoushn 3y ago

In Go if you'd like to make an interface-compatible database driver, you have to construct structs with non-exported fields from another package using unsafe.

impulser_ 3y ago
database/sql provides a generic interface for SQL which drivers use to build their libraries. You can switch from one postgres driver like pq to pgx easily because they both support database/sql.
- ibraheemdev 3y ago
  Except pgx recommends using their native interface, not database/sql, for performance and extra features [0], so it's not that simple in practice. [0]: https://github.com/jackc/pgx#choosing-between-the-pgx-and-databasesql-interfaces https://github.com/jackc/pgx#choosing-between-the-pgx-and-da...

lmm 3y ago

> I wish more programming languages provided interfaces for building libraries around the std library like what Go does. It makes using libraries a lot better because you aren't dependent on that library as long as it uses the std library interface. > This is huge for things like database drivers which might become outdated or not support certain features. In Go switching database drivers in as simple as importing the new library. You dont have to change your code. The effect is that every database driver becomes outdated and doesn't support certain features, instead of just a few. Python people have a saying that the standard library is where modules go to die. Java's database drivers massively lag behind (e.g. there's still no good async support for most of them), because JDBC is a lowest common denominator that every driver has to be dumbed down to, but is established enough that it sucks all the oxygen away from any efforts to write better drivers. Far better to keep the standard library small and allow modules to update on their own terms and their own schedule. If the library you're using does what you need, you can stick with it, but a better alternative (which always means a new interface in practice - the idea that you can make substantial improvement without changing the interface is mostly a myth, because the interface is the most important part of a library) can appear and compete on its merits, and if the improvements are worth migrating to then it will win out.

alfiedotwtf 3y ago
Exactly. Perl had BerkleyDB as part of Core, as well as CGI. How's that going for the Perl footprint!
born-jre 3y ago
one approcach with golang is make interface that can be leaked if you really want, you will be using standard interface 99% but if you need sth not provided by abstraction you can ask for underlying impl `db.Driver()` and cast to appropriate type.
lenkite 3y ago
> Java's database drivers massively lag behind (e.g. there's still no good async support for most of them), Very Hard Disagree. JDBC is pretty amazing actually. Thats why you find so many Database tools and wizards written in Java as opposed to Rust. Regarding async - With Java 19 virtual threads , you have newer versions of JDBC drivers support async with none to minimal changes. Example: https://medium.com/oracledevs/introduction-to-oracle-jdbc-21c-driver-support-for-virtual-threads-189b918c56f4 https://medium.com/oracledevs/introduction-to-oracle-jdbc-21... I am very, very glad that human civilisation standardised on one system for gears instead of every manufacturer making their own special snowflake.

paulddraper 3y ago

> In Go switching database drivers in as simple as importing the new library. Neat! Kinda like Java. (JDBC) Kinda like C#. (IDb) Kinda like Python. (DB-API) Kinda like PHP. (PDO) Kinda like Perl. (DBI) Kinda like C/C++. (ODBC) Of course, you work as the lowest common denominator and have abstractions that don't quite match the implementation. And let's be honest, how often do you switch databases. But yeah this is very common. --- I'd argue in practice, Java follows your advice the most of any community: * JDBC * Servlets * SLF4J (not technically stdlib but very common)

fzeindl 3y ago

> I wish more programming languages provided interfaces for building libraries around the std library like what Go does. Java does, but apart from JDBC for databases, and the servlet-API, I haven't seen many cases where that really improved the world of programming. Java-EE relied heavily on such abstractions, but nowadays those would be replaced by simpler, less abstract constructs with less redirections. > This is huge for things like database drivers which might become outdated or not support certain features. In Go switching database drivers in as simple as importing the new library. You don't have to change your code. Database drivers are an abstraction that tends to leak it's underlying technology very fast. The idea of just being to swap your database out under the hood is neat, but generally holds only for simple projects. Also the abstraction that helps you here is SQL really, not the driver.

pjmlp 3y ago
Java EE isn't gone away, it is the foundation of all modern Java frameworks, via Jakarta EE renaming and Microprofile. Spring, Quarkus, Helidon, Liberty, Wildfly, TomEE, Payara all support it. It turns out such standards are quite valuable for the industry at scale, instead of playing tetris with third party library stuff of various quality.

dragonwriter 3y ago

> I wish more programming languages provided interfaces for building libraries around the std library like what Go does. It makes using libraries a lot better because you aren't dependent on that library as long as it uses the std library interface. So, standard interfaces, or dynamic or structural typing? Lots of languages have those (some all three.)