People are sometimes unkind to the Division Bell, but it contains one of my personal favorites: "Wearing the inside out". Wright's lyrics and vocals (first time since The Dark Side of the Moon), Gilmore's guitar, it all comes together.
Valkey, the Redis fork, is currently sponsored by Ampere, AlmaLinux OS Foundation, Broadcom, DigitalOcean, Memurai, NetApp, Aiven, Alibaba Cloud, AWS, Canonical, Chainguard, Ericsson, Heroku, Huawei, Google Cloud, Oracle, Percona, Snap Inc and Verizon[0].
There is enough interest in sponsoring the development of infrastructure software. But if you want to build a "commercial arm", get VC funding[1][2] and earn millions, then it will never be enough. And I can't say it's unreasonable to want to do that, it just ultimately ends up being against the long-term interests of the project as a whole.
What I dislike about the license change is that by trying to extract an extra dollar from Amazon&Google, the entire community gets hurt in the process.
Can I "dnf/apt install redis" on my Fedora or Debian install? I cannot, it's no longer packaged because it's no longer open source.
Can I go buy a shared hosting plan and get Redis? Or a small PaaS that sits on top of AWS? I cannot, because we have decided that every hoster is now as exploitative as Amazon, regardless of their margin.
For decades we lived in a world where someone could sell you an Apache server and a MySQL instance without having to pay money to Apache or MySQL. We can change that social contract, but like all tariffs, this one will be paid by the end users, not by the companies providing the service.
They did a reprint of the original magazine from January 1984, to mark its 40 year anniversary. It can still be purchased online at https://prodavnica.pcpress.rs/issue/339/1, and they ship internationally.
I got my copy a few months ago, wanting to own a small piece of history.
You can buy the actual computer kit as well at https://pcpress.rs/galaksija/, but that one ships only within Serbia.
I like the support for custom currencies, as that is an edge case that often pops up.
On the other hand, be careful about tying the symbol to the currency, as symbols are locale specific. For example, the symbol for USD is $ in eu-US but US$ in en-CA and en-AU (Canada and Australia), and then $US in French locales.
https://cldr.unicode.org/ is the magical dataset behind most good implementations that deal with currency display. Updated twice a year, available in JSON, providing currency symbols and formatting rules for all locales, as well as country => currency mappings and other useful information.
There is a middle ground and some common patterns that can help.
The address field names are fairly standardized[0] and Google has an open dataset (used by Chrome and Android) describing which countries need which fields[1].
I have an older PHP library[2] and a newer Go library[3] that build upon this, while crowdsourcing fixes (since Google hasn't updated their dataset in a while). The Go library allows me to serve all address formats and state lists in a single HTTP request, which can then power a very fast JS widget.
[0] Initially by the OASIS eXtensible Address Language (xAL) which trickled down into everything from maps to HTML5 autocomplete.
In retrospective, I think it's obvious that Go's decision to have package and variable names be in the same namespace was a mistake. It is the main reason why people overuse single letter variable names, and have debates such as the one in the linked post.
I am guessing that using a different operator (e.g. rate::NewLimiter()) was deemed inelegant, but it would have avoided a whole set of problems.
I am going to be controversial for a hot second, and say that in many ways MySQL is a more advanced and better implemented database at its core. Disclaimer: as a developer I love and prefer Postgres. But I've been on many projects where MySQL won for ops-related reasons.
Postgres has a MVCC implementation that is recognized as inferior[0] to what MySQL and Oracle do, and requires dealing with vacuuming and all of its related problems.
Postgres has a process-based connection model that is recognized as less optimal than the thread-based one that MySQL has. There are ongoing efforts[1] to move Postgres to a thread-based model but it's recognized as a large and uncertain undertaking.
Other commenters have also explained the still very noticeable difference in replication support, the lack of query planner hints, the less intuitive local tooling.
One thing to keep in mind is that both databases keep evolving, and old prejudices won't take us far. Postgres is improving its performance and replication support with each release. MySQL 8.0 added atomic DDL and a new query planner (MariaDB did their own query planner rework in 11.0, widening their differences). Both are improving their observability. So the race is far from over. But I definitely wouldn't count MySQL out.
This looks like a great effort and I am looking forward to trying it out.
I am a bit confused by the choice of the LGPL 3.0 license. It requires one to dynamically link the library to avoid GPL's virality, but in a language like Go that statically links everything, it becomes impossible to satisfy the requirements of the license, unless we ignore what it says and focus just on its spirit. I see that was discussed previously by the community in posts such as these [1][2][3]
I am assuming that bgentry and brandur have strong thoughts on the topic since they avoided the default Go license choice of BSD/MIT, so I'd love to hear more.
It doesn't have the performance or the features of something like Chi/Gin/Echo, so while it will improve the lives of people who prefer to stick to the stdlib, it probably won't convince many others.
Socket activation via systemd[0] is an option, assuming you are fine with certain requests taking a longer time to complete (if they arrive while the service is being restarted). Otherwise using a proxy in front of your app is your best bet (which has other benefits too, as you can offload TLS and request logging/instrumentation).