Hacker News Reader

Comment by impulser_ | Hacker News Reader

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.

View on HN

> 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.

Exactly. Perl had BerkleyDB as part of Core, as well as CGI. How's that going for the Perl footprint!

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.

> 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-21...

I am very, very glad that human civilisation standardised on one system for gears instead of every manufacturer making their own special snowflake.

> 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.

Java is much older and bigger than Rust. I don't think its level of database tooling is noticeably better than other big languages with less of a standard database API (e.g. Python).

> Regarding async - With Java 19 virtual threads , you have newer versions of JDBC drivers support async with none to minimal changes.

So it's only taken what, 15 years, and even then it's only been done because they found a way to make it happen without having to actually change the API (which it remains to be seen how well that actually works in practice - I'm pretty skeptical because other platforms have tried and failed with that approach).

> I don't think its level of database tooling is noticeably better than other big languages with less of a standard database API (e.g., Python)

DB-API 2.0 (PEP 249) is very much a standard database API.

Go doesn't provide standard library implementations of database drivers, only standard library interfaces for driver implementations to adhere to.

I addressed this in my last paragraph.

> Python people have a saying that the standard library is where modules go to die.

That's just a quote from a 10 years old talk by Kenneth Reitz, and it's quite an overstatement.

Java has something called R2DBC as well, the async jdbc driver equivalent. Most major db have such a driver nowadays.

Right, but it's very hard to overcome the inertia of an established standard.

(JDBC isn't actually in the standard library IIRC but it's a JSR, so it's an "official" part of the platform and that creates a lot of pressure to follow that)

All those complains always forget that the standard library happens to be available everywhere the language has a full implementation available, while third party libraries are hit and miss.

I rather have outdated code that works, than not having anything at all.

> All those complains always forget that the standard library happens to be available everywhere the language has a full implementation available, while third party libraries are hit and miss.

Only if your dependency management is bad.

And if you're stuck running on e.g. an old install of the language, there's at least a chance that the third party library will support it, whereas if you want a new standard library feature you're SOL.

All dependency managements are bad when they assume UNIX only workloads with C compilers pre-installed.

And on top of that download half of the Internet for doing an hello world with error handling or asynchronous code.

> Only if your dependency management is bad.

Please give an example of good dependency management in any language. It seems to be one of these subjects draining constant displeasure.

I'm not advocating against third party libraries, I just think a reasonably rich standard library sets a good foundation for them.

Maven has worked well for over a decade. I understand cargo is similar.

If your dependency management is any good then there's nothing to lose and a lot to gain from splitting your libraries out and allowing them to have independent release cycles. You can always do "platform" releases that aggregate together a bunch of finer-grained libraries with versions that are known together if you have a use case for that; going the other direction is a lot harder.

As long as it is pure Java code.

Did maven help to split out Java's standard library ? Is Java's standard library small ?

> Did maven help to split out Java's standard library ?

I would say so, although splitting an existing standard library is still extremely painful and cumbersome thing to do (I don't think any other major language has seriously attempted it) - exactly why it's better to avoid having a large standard library to start with.

> Is Java's standard library small ?

I'd say no, but the parts of it that are used nowadays are. For example there is an HTTP client implementation in the standard library, but it's very rarely used by today's Java programs since its design is quite dated.

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.

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.

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...

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.

Database client libraries typically don’t parse SQL.

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).

I would highly recommend against this. For example, postgres and sqlite differ in what they accept as meaning 'true' or 'false'. Try this with both databases, 'create table foo (whatever bool not null)', then insert 't', 'true', 1, true, 'f', 'false', 0, false. Postgres will reject 0 and 1. Now query for true and false values, like 'select count(1) from foo where whatever=true'. Sqlite returns 2! Postgres returns 3. Do the same for false, same results. Now ask Sqlite the count of 'select count(1) from foo where whatever != true and whatever != false'. It returns 4.

You are in for a world of hurt if you think your SQL statement parsing means that your application is going to work. Changing database backends, in my mind, amounts to a full rewrite of the data layer. Whatever quirks you have built around are likely to subtly change.

Oh, and one unsolicited tip. If you're using Go, don't bother with database/sql. Just use pgx + pgxpool from the get go. You aren't going to be able to plug some other database implementation in and get a working app. So the abstraction layer is basically unnecessary.

For what its worth, I think it would be great if standards groups wrote up robust test suites to go along with their standards.

For example, commonmark has a test suite with hundreds of machine readable input / output examples. Each example has some input markdown text, and an expected parsing result. Any compliant commonmark implementation can use that as a test / conformance suite during development. As a user, result is you can be pretty sure every spec-conforming implementation will interpret the same markdown text the same way.

During Chrome's development they built something similar. They gathered the HTML from hundreds of real websites and made browser-independent data sets showing how that HTML must be parsed. That freed up the team to try out wild optimizations, with certainty that they wouldn't break compatibility. When Microsoft copied Javascript into IE, I assume they did something similar to make sure they parsed javascript in an identical way to how Netscape Navigator parsed JS.

It would be harder for a complex protocol like bluetooth, but it would be fantastic to have a "bluetooth tester" device which tried out a lot of the strange things real bluetooth devices do to make sure any implementation is compatible with any other implementation. You can tell a device like this doesn't exist (or its not very good) because of how abysmal cross-device bluetooth compatibility is in general. (Linux doesn't work properly with either my bluetooth keyboard or mouse because, while both devices apparently work on windows and macos, they don't properly adhere to the spec.)

If SQL were a better written spec, it wouldn't have random incompatibilities like that.

You've actually described what true TDD is, you test requirements which leaves you free to change your implementation without fear that you have broken anything. Also (as you have pointed out) makes writing a faster implementation much easier.

Another downside is you lose access to all your database specific functionality, or at best makes it more complicated to use as you need to unwrap the abstraction layer.

Yeah well, if you read the doc, you know that SQLite doesn't support the boolean type.

"SQLite does not have a separate Boolean storage class. Instead, Boolean values are stored as integers 0 (false) and 1 (true)."

If you choose the right SQL and right data-types, you can definitely have database independence. Our integration product (>10 years old) supports 4 diff databases for customers with a single, common code base. As long as you have the test-suites, its definitely doable. But you need to use a language which has a standard for interacting with databases.

Exactly. It's like a feature on a paper, but I don't think anyone would ever dare to make a database driver switch in production.

Agreed. Wrapping all db access in its own class or module is one of the easiest architectural decisions to be made in a project. Allows you to use specific drivers but isolates changes to a few easily found locations. Makes it dead simple to test too.

> 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)

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

Go also have standardized HTTP handlers, and a standardized io.Writer interface for writing to anything, like a file, buffer or a HTTP reply.

Yeah, but Go provides this for almost everything in the STD. io, networking, http, sql, and so on.

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.

It still fails short of GUIs and full blown Web frameworks, messaging, like the above.

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.

> 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.

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.

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.

So, standard interfaces, or dynamic or structural typing? Lots of languages have those (some all three.)

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.

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

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.

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.

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-da...

Reply on news.ycombinator.com