Hacker News Reader

Comment by montanalow | Hacker News Reader

As a fan of Rust, this seems like the perfect application domain for "fearless concurrency". Having gone through the bowels of a few different connection pool implementations in various languages (because they had bugs in production), I can tell you the concurrency management becomes extremely difficult to reason about as the feature complexity increases. I think you're making a good bet that offloading a good chunk of that to the compiler will improve your ability to iterate in the future.

GoLang seems like the language du jour, but I think this post [1] really illustrates how powerful it can be when you have a compiler that handles so much more for you. It's not just about performance. Deadlock detection and a robust compile time set of error checks are huge wins over looser languages.

1: https://fasterthanli.me/articles/some-mistakes-rust-doesnt-c...

View on HN

This is actually pretty amazing. I wouldn't normally trust a single author implemented project to sit between my application and my database, since that is a rather critical single point of failure. However, a grep that fails to find `unsafe` in a rust code base lets me know that this code is in fact pretty safe[1]. I don't need to trust the author, as much as I trust the Rust core team, and LLVM.

Since I can see basic functionality exercised in the test suites, and trust that Rust has validated its more general correctness, this gives me more confidence in your project than I would historically expect to be able to gather in such a short amount of time.

1: https://github.com/levkk/pgcat/search?q=unsafe

Being in Rust or not the code has 0 tests, write arbitrary bytes, hard code values etc ... looks like more a PoC project that something that going to replace pgbouncer any time soon.

Yep the readme is pretty clear it's a POC "Alpha: don't use in production just yet."

That said I've struggled with more than my fair share of pgbouncer misconfigurations and outright bugs. I personally would love a simpler (harder to misconfigure) and less buggy alternative.

It's definitely a PoC. I started it two weeks ago. Overall I've been super happy with Rust because it was a great safety harness and it gave me a fast concurrent program. PgBouncer implements this in about 30k lines of C, while I managed to get 80% of the way and then some in less than 1k.

As for tests, it's covered with pgbench, python (psycopg2), ruby (pg / active record gems), psql and a couple inline tests for trivial things like config.

As for bytes and hardcoded ints...give pgbouncer's and postgres' source code a look :).

> a grep that fails to find `unsafe` in a rust code base lets me know that this code is in fact pretty safe

This statement does not make any sense. That, or we have vastly different definitions of what “safe” means.

yeah maybe it safely deletes all your tables at midnight

The “unsafe” keyword in Rust is a source of perpetual oblivious overconfidence. It should’ve been called something that befits it’s actual narrow scope (`disableStongTypeChecks` or some such) but that ship has sailed.

"unsafe" is pretty clear: the block/function is not safe, that doesn't mean the rest is safe. I suppose it might have been better named as "asserted", "assumed_safe", or "manually_checked", but that's much more verbose and not necessarily clearer.

These blocks are supposed to be rare, so a more verbose keyword isn't a problem. It would be better to be precise here and avoid a concept so general as safety.

When you remove the context around statements (thread about rust concurrency), it's easy to make a statement into overblown nonsense. You may be interested in the broader analysis contained in the link from parent comment, about the type of safety being discussed in this thread, or you may not.

Reply on news.ycombinator.com