In my part of Europe it’s all in private WhatsApp groups (one for inner family, one for friends, etc)
HN user
bojanz
Director of Engineering @ Upsun
https://bsky.app/profile/bojan-zivanovic.bsky.social
https://github.com/bojanz
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.
[0] https://www.linuxfoundation.org/press/valkey-welcomes-new-pa...
[1] https://redis.io/press/redis-labs-raises-100-million-series-...
[2] https://redis.io/press/redis-labs-110-million-series-g-led-b...
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.
Disclaimer: I work for a PaaS.
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.
Right, indeed!
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.
Disclaimer: I maintain a Go solution in this problem space: https://github.com/bojanz/currency
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.
[1] https://chromium-i18n.appspot.com/ssl-address
You'll find many case studies about using Clickhouse for this purpose.
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.
Couldn't agree more. There's a great decade-old blog post by Mathias Verraes which illustrates this well, I keep coming back to it: https://verraes.net/2014/08/dry-is-about-knowledge/
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.
[0] https://ottertune.com/blog/the-part-of-postgresql-we-hate-th... [1] https://www.postgresql.org/message-id/flat/31cc6df9-53fe-3cd...
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.
[1] https://www.makeworld.space/2021/01/lgpl_go.html [2] https://golang-nuts.narkive.com/41XkIlzJ/go-lgpl-and-static-... [3] https://softwareengineering.stackexchange.com/questions/1790...
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.
Out of the box multi-master replication is a pretty big one.
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).
Go isn't perfect either. The author isn't dealing with assets (images anyone?).
Go supports embedding assets since 1.16, the author mentions embedfs in the post.
Optional function parameters also deserve a mention. Their absence results in semi-ugly workarounds even in the standard library[1].
Sputnik V is already in the EU approval pipeline: https://www.reuters.com/article/health-coronavirus-russia-va...
OpenBSD does distribute Apache 2 code (e.g. LLVM), but it's true they're not happy about it due to the patent clause.
Apple prefers Apache 2 for its own code (LLVM, CUPS, Swift).
What are the benefits of Snowflake compared to ULID, which already has Rust implementations[1][2]?
If you're a Laravel user you'll want to look into Inertia.js[1].
I'm personally more excited about this year's OAuth 2.1 draft[1], since it aims to reduce the number of RFCs one needs to review and understand in order to implement a best practices OAuth client.
To quote[1] Russ Cox: "C uses #pragma foo for this. Go simply spells #pragma as //go:."
https://www.reddit.com/r/golang/comments/hv96ny/qa_goembed_d...
I am sure many developers don't remember just how much crappier the "crappier APIs" were. Back when Stripe became popular the alternative was XML and SOAP, documented in an outdated PDF that would get emailed to you, or if you're lucky, hosted behind 3 login walls. Then, once you start integrating, you realize that their dev environment is offline every other request, and doesn't match the production environment. So you just do the work blindly and hope for the best.
Having a decent publicly documented API was revolutionary.
GoatCounter[1] was featured on HN at some point. Open source, written in Go. It has a "subsite" feature which I haven't played with.
Assuming that the JWT only stores the user_id, and you then load the full user (protecting against stale data), a counter or a timestamp on the user object can be used to control logout.
There's a good Go library detailing this approach, along with a blog post: https://github.com/endiangroup/compandauth https://endian.io/articles/compandauth/
I've gone deep into Go, finding it a fun change from daily work. The project I'm working on isn't ready yet, but I've managed to extract and share my first package[1], for handling and formatting currency amounts.
Communicating expectations / setting boundaries feels key to avoiding negativity on both sides.
I recently read an article titled "Healthy Open Source Maintenance"[1], which proposed the introduction of a MAINTENANCE_MANIFESTO.md, meant to communicate expectations.
Quoting the fun part:
"Even though this idea is still in early stages, for the sake of clarity, this is what a selection of manifestos could look like:
- The sponsor me to get priority on your bug fix manifesto.
- The this is free goods and service, so you get what you get manifesto.
- The micro-donations to keep the project alive, but I decide what to work on manifesto.
- The hire the agency I work for to sponsor features manifesto.
…
The presence of the Healthy Maintainer Manifesto will be a tool to deflect social pressure. This will help maintainers that suffer from avoidance anxiety because they are not obligated to pay the maintenance taxes. Their manifesto says so! If any demanding user wants to pressure them into doing anything in particular, they can point them to the manifesto. The manifesto replaces complicated social interactions with a discharge form. The goal of this is to protect the maintainer, because, after all, maintainers are the cornerstone of open source—and thus all the software industry. And because we all prefer a community where maintainers are happy, and not at the brink of burnout."
[1] https://www.lullabot.com/articles/healthy-open-source-mainte...
FreeBSD tends to have the latest KDE while OpenBSD tends to have the latest GNOME. AFAIK no BSD has both (which is understandable, considering how complex it is to package software of this size).