Kind of a strange thing to call out.
Can't blame him for being proactive about nipping them in the bud.
Fundamentally men and women have similar brain physiology, so an equal amount of compute and memory. Which would imply there are no differences when it comes to programming ability. It's just a matter of experience.
I'm glad HN doesn't have profile pictures and things.
https://www.mentalfloss.com/article/56865/why-does-terrible-...
this usage is definitely uncommon/archaic
You can be confident that you won't need that definition in your own usage unless you decide to write an 18th century character or something.
To add to the etymology links (I was also intrigued):
https://www.grammarphobia.com/blog/2013/08/terror-terrific.h...
but like you say, these aren't nobodies. However, I am curious to see how the pace will change (if at all), with you no longer doing the lion share of work.
It seems like, for one reason or another (Redis Labs because they want to sell their “core plus proprietary modules” service; the clouds because they want to push you to use their other products for use-cases that fit them better), all the new leadership has reason to want to not add any more developer-facing features to Redis Core. I expect the Redis Core you see right now, is the same Redis Core we’ll have 10 years from now, client-API wise. Redis, as a USP, is “done.”
Unless, that is, some third-party comes in with their own polished feature PR, and pushes really hard for it. In other words, Redis is kind of moving to the Linux kernel model, where “new use-case out of nowhere” features come in mostly not from internal development, but rather from external contributors petitioning the core-maintainership priesthood with reasons their patch should be upstreamed.
Either way, there’ll certainly continue to be plenty of ops-staff-facing innovations, bug-fixes and polish. That’s what gets this new core team up in the morning. I’m sure people running Redis in production are happy about that.
I sympathize with the main points you were making, but surely ‘people running Redis in production’ are the core use case for Redis, so ultimately this move seems good for the project’s overall direction.
1. the kind that devops people directly see a need (usually a scaling need) to integrate it into a stack of existing production software; where this integration may or may not require additional development-time work (i.e. connector glue code in the business layer), but is either way an ops use-case. Examples: any caching layer, any message queue.
2. the kind that developers integrate with in order to get the semantic guarantees that particular kind of software offers; and then ops people are left "holding the bag", needing to deploy that same software (or something compatible with its wire protocol) in production because that's what the business logic was written to depend on. Examples: most databases; object storage; map-reduce workload engines.
Usually, it's pretty clear which bucket a piece of infra software falls into—either it's developers or ops people that suggest it as a solution, but rarely is a piece of software equally loved by both.
But Redis straddles the line between these usually-clear clusters of software. It can be a metrics-reactive "patch" to a running system to get it to scale better; but it can also be a development-time foundation for business logic, or a dependency of a library where it was a dev-time foundation for its business logic (e.g. any "background worker" library.)
In other words, Redis Core as a project, serves two masters: it must both be
1. a stable, scale-multiplying, worry-free daemon you can easily toss into your existing legacy infra;
2. a feature-rich "durable data-structure server", allowing developers to obviate the keeping of durable state in the app layer itself.
The new leadership certainly will care a lot about use-case 1.
I'm pretty sure, though, that the previous leadership (i.e. Antirez) cared almost exclusively about use-case 2—making developers' lives easier by taking durable-in-memory-state-management code they were writing, and replacing it with calls to Redis. That's why we didn't see TLS support and so forth for so long. Redis wasn't being built for ops people; it was being built for developers. Code that went into complex deploy-time use-cases, was only ever added by Antirez as a consequence of systems developed for Redis now depending on running it in production. (E.g. you don't scale Redis into a cluster; you develop for the sharding semantics of Redis Cluster, and so therefore you must deploy Redis Cluster. You can "upgrade to" Redis Cluster after-the-fact, but it's far harder than just writing your code to be "cluster-safe" at the start. It's idiomatically a development-time choice you're supposed to be making, knowing the eventual "scaling goal" of your system.)
Yes, the rest of the core team—mostly ops-focused engineers—gradually accrued around Antirez. That's why many of these ops-time use-cases did start getting addressed.
I'm mostly worried that now, with Antrirez out of the picture, the team is unbalanced in the other direction: there's no one on the core team pushing the "developer productivity" side of the story.
To me, that laser focus on developer productivity was what made Redis consistently the infrastructure component I would most want to integrate to solve a problem, if it offered a solution to that problem. I knew that "the Redis approach" would always involve just a library import, a connection URL instantiation, and one or two atomic Redis command calls; whereas other libraries might require me to write delegate modules, serializers, attach to special listener modes, etc. And I always knew I could just open redis-cli and prototype out those same commands against my local zero-initial-config-required Redis server; where other infra might require me to fiddle with everything from setting my own compile-time flags, to JVM memory-management, to Docker image volume mounting, etc.
I really just hope that the new leadership retains enough of the spirit Antirez has been injecting into Redis, that they'll reject PRs that solve ops use-cases but come at the expense of developer productivity (e.g. moving to entirely-async command execution, and then deprecating the text-based Redis wire protocol because it's hard to integrate its parsing into a Jepsen-correct threaded execution engine, or something like that.) Such features wouldn't hurt cloud deployments for existing Redis users at all, but they'd sure scare away new developers from finding new ways to replace business logic with Redis.
1. Those orgs succeed when redis succeeds. So they want to see it used more which means more features.
2. Developers think for themselves and aren't always "double agents".
3. The redis community still exists and open source communities are often very vocal about directing products
I don't think the situation is quite as binary as this suggests. Even assuming that developers are consistently doing what they believe is in the best interest of the project, their employers may benefit from being able to encourage them to consider the items which are the employer's priorities. Developers don't have unlimited time, and if they have to choose between two worthwhile projects and one of them is of interest to their employer, it's likely that's the one they'll spend time on.
He was the heart and soul of the project.
It also makes me think, what would Linux be when Linus decides to step away? I kind of don't want to think about it.
Thank you to Antirez for all your hard work on Redis.
In just the last 90 days, he accounted for 50% of the code that is being changed in redis. I'm currently indexing the Git repository, as I'm curious to see the impact Linus had before he left, but I don't think Linus leaving, is anything like antirez leaving.
Sorry if this post comes of confrontational, as that is not its intention. I just don't understand what comparison you are trying to make.
Antirez, on the other hand, has had a large part in the continued development of Redis since it's inception, so like, 11 years or so (2009).
AFAIK, apart from UI improvements over the years, Git has _largely_ been the same since inception, in that you can watch a video as far back as e.g https://youtu.be/4XpnKHJAok8 and not much has really changed since those days (by the time Linus gave that prez, Junio already started running the project).
