> utilizing a resource to it’s fullest at all times is not a given
Typos like this (it's instead of possessive its) used to be bother me but now it's a hint that it might be human-authored, which is quaint, so it's stopped bothering me as much.
That won't be a good heuristic much longer. A few weeks back I saw Gemini write "Redundant Abstraciton Overhead" (-citon instead of -ction). It was the first time I saw a model make a "typo", so I made a note of it.
When my girlfriend was conversing with an LLM in Czech, it often made grammatical mistakes or even switched into a different Slavic language (including ones that use the Cyrillic alphabet!).
For most of my life I thought no apostrophe was always wrong, since that's how you do both contractions and possessives in general with a name or noun. For some reason all throughout school people would say "it's" as a possessive was wrong without trying to explain "its" was a parallel to the separate words "his" and "hers", rather than "bradfitz's" or "that person's" like it looked like. Only someone in my 20s did I realize the connection and "its" stopped looking wrong.
Seriously, that's all it was. Just Ian alone proposed and rejected a half dozen of his own different approaches to generics. Finally a language + implementation plan came together that people all liked.
The implementation is coming along nicely, and I'm already thinking of ways of using generic bound functions. I'm not bad that it's not like Java 1.4 despite having the lessons of Java 1.4, but being class-based is a very different way of working from go. Getting the unbound functions right before the bound ones was a struggle, but I do think the approach makes sense, in the long run.
I can't wait to see the Container stuff in the next iteration, too.
However, if pooling isn’t used, there’s always an overhead (tens of milliseconds or more) when creating a new connection because Postgres needs to fork a process. And yes, applications can be written without pooling, which isn’t ideal, but happens quite a lot.
Application frameworks have also changed. Serverless architectures can generate tens of thousands of connections, which is where Postgres starts to run into issues. I’m personally not a big fan of using more than a few hundred connections, but it is very realistic in this era.
Why Postgres should be doing this?
Not every client creates a lot of connections and spinning up PgBouncer is easy.
On the other hand, debugging async multithreaded complex code is hard.
Postres project also once lacked replication, calling it unnecessary to the core effort. Now it has two means of replication in core and I'd argue is better for it, especially after suffering through both Pgpool and Slony.
I hope they do develop a native, threaded pooling, even if it were incompatible with some libraries or extensions.
You were coming into the field just as companies were fielding their first reasonable answers to the Threading Model that Java put forward, which was sort of Windows' but with extra features. Even Solaris choked on Java. HP UX did worse and I can't recall if SGI was worse or better than HP. But getting compatible with Java shook a lot of companies up, in how they handled concurrency.
Postgres and SQLite were being designed at that same time but by industry veterans. People who had been deploying high load systems before any of this threading nonsense was around. And they were supporting people running on old hardware.
Yeah, I remember writing epoll libraries for Perl (https://metacpan.org/pod/Sys::Syscall, first out 2005-08-01) doing raw system calls because libc on the distros of the time (at least Debian) didn't have epoll support yet.
So in 2005 I didn't expect Postgres to do super well here, but it's 21 years later and we're still pgbouncin'. It's just kinda sad.
It's in Chrome, Firefox, Safari, Windows 10, macOS because it efficiently solves a huge number of use cases while giving plenty of headroom for flexible querying.
If you have data more complicated than a single CSV or tab-separated text file that you will only ever process in sequential order, and you don't need inter-process interaction, you should be asking why not use SQLite.
sqlite is useful everywhere CSV files are useful but you'd like them to have more data integrity and faster updates. sqlite can replace some uses of MySQL, but more commonly it replaces fopen. https://sqlite.org/whentouse.html
"Welcome to the "Roku-tech" mailing list" ... "Tue, Dec 2, 2003, 10:48 AM"
Not sure how I ended up on the mailing list a month before their product was released. There must've been buzz about it for a few months before release.
Well, color me impressed -- my understanding was that Roku was formed as a spinoff from Netflix around the release of their first streaming player. This is sort of confirmed by the Roku wikipedia article, which does not, for example, mention the HD1000 at all!
I guess Wood founded Roku but it was basically semi-defunct when we went to work for Netflix, and then the "spinoff" was basically letting Wood poach his team from Netflix over to his existing company to staff up and sell the first streaming device.
Indeed… That evolution makes perfect sense. A lot of Go developers independently arrived at similar request coalescing patterns around that time, especially in caching, RPC, and high concurrency systems. I have an older implementation from personal 2013-era Go projects that follows almost the same approach.
What is nice about open source is not necessarily the novelty of every individual idea, but having a well-tested, shared implementation the community can converge on. Your work on singleflight clearly became that reference point for the Go ecosystem, and it is cool to see the lineage from dl.google.com to groupcache, x/net, the standard library, and now all the downstream variants.
reply