I don't see how it's useful then. Maybe someone can give me a good use case?
redis is already very bare-bones and dead simple to set up and maintain, what more does one want? Wouldn't adding more logic into a redis-like environment be a little cumbersome from an architecture perspective?
Could be used for proxying redis connections, be it for clustering or I don't know, add sophisticated access control or something.
You could expose a memcached cluster as a redis server using this. (Not sure why would you want to do that.. Maybe if you have an existing memcached cluster and have redis client code?)
Or you could go crazy and implement the entire set of redis commands on top of sqlite and call it a "strongly persistent redis" or something like that.
It's just a nice building block, I'm sure people would find ways to abuse it :)
I'm not sure, either. By the time you've implemented all the actual Redis functions, there's no telling whether the server will be more or less performant than Redis itself. (Most likely less, since Redis is written in optimized C.)
Of course the existing benchmark shows that the example Go implementation is faster. For one, the Go implementation provided avoids a lot of functionality that the Redis server implements, such as TTL checking.
This is not for recreating Redis, but for custom server implementations such as the Tile38 project, proxying services, and microservices that might need to use the RESP protocol.
You have a more complicated data storage, or an established one that you don't wanna change, or a mandate from on high that all data must be put in X due to auditing or whatever - and a program that wants to talk to Redis.
The use case would be implementing the redis protocol for client server communication in your own software. There is a specification for using the redis protocol [1]. The fact that redis is widely used and there are a number of client libraries in many languages may make it an attractive option compared to creating your own protocol from scratch.
I believe disque, the distributed message broker [2] uses the redis protocol for client server communication.
Go 1.0 is 4 years old now, after 5 years working on developing what is essentially and was always "C with garbage collection and threading". Rust is a year old, after 6 years of research building something novel outside of academic languages, with the final shape of the language heavily changing in the last year. Rust also doesn't ship with an extensive standard library including nearly all the things you'd want to make a basic web app.
Basically - Go had a very strong focus on web servers from the start, making it easy to pick up and develop web servers with. Web developers make good early adopters - they'll pick up new tools faster than almost any other group of developers. Rust was released without any of those tools, and they're still changing as the ecosystem develops (especially around async frameworks). And even with that, there's a fair few companies using it for all sorts of cool things: https://www.rust-lang.org/en-US/friends.html
> The only thing it get's write is the excellent microthreads and CSP implementation.
No at all. It's very far from even remotely decent implementation, the interface is too inconsistent and full of implicit behaviors and the performance is an order of magnitude slower than anything acceptable. But anyone actually using it already knows..
I admit we dropped Go before getting to production, with any kind of performance requirements.
I liked the goroutine related apis though.
What I remember being PAINFULLY slow is reflection. Which is very inconvenient for certain tasks (building objects from db queries, (json) serializing,...). Macros could help here, but alas, code generation is the only alternative available. Which I'm not a fan of.
The reflection is slow indeed but most of the time you can use caching to improve it(at least that was my case). I like Go a lot but I must admit that some features would make my life easier and perhaps the language more expressive too(i.e. variant types). If that is not good enough you can use code generation(last resort)
I initially really liked it. But the languages designers just skipped over countless years of achievements in language design and implemented a C with garbage collection, with interfaces and a baked in CSP runtime.
If you read a bit in the groups / release notes, they were just too lazy to implement generics. Or it was too hard.
Go's ecosystem is really weak (for example, barely any library does proper versioning or any release procedure at all).
I think that is at least part due to the difficulty of writing clean, generic code. And the lack of proper packaging.
The lack of features is not a selling point, even if they try.
The Go bitch threads are becoming so predictable that they can be autogenerated. Can HN implement a labor-saving device that deletes comments like this and just links to some canonical repository of gripes?
Actually I'm a little more annoyed by the Rust and Elixir people. At least the Go stuff is "Hey I did something in Go". The Rust and Elixir stuff is almost always as a response to something someone did in Go, C, C++, Java or some other language, and almost always in the form of: "You might like Rust", "You should check out Elixir".
At least Go can generate it's own hype, and doesn't need to piggyback on others.
Everyone should at least try writing their own OS. Not necessarily their own kernel, or even the lowest-level utilities - things like Fiasco.OC with Genode are decent enough if you're not interested in register fiddling - but their own model for how things could work if they got to design a system for programmers and users to use from scratch.
Capability systems? Network transparent message passing? Dynamic load-balancing of running processes across machines? What if you tried to let users script their workflows in a less ad-hoc way than they can now? How about trying to replace the concept of a filesystem, at the same time as trying to encourage applications to share data with each other?
OS development research died a couple of decades ago, and now we have an entire generation of developers who believe the Linux/POSIX model to be the one true system. But IMHO, that's just a quirk of fate, and a local maxima, and it keeps people in the dark about alternative solutions to their problems. For example, capability system advocates will point out that their system almost implements Docker/containerization by default. There have been tons of experiments with efficient message-passing under microkernels which would likely benefit anyone attempting to design Yet Another IPC Framework in the Linux kernel. And so on and so forth.
> Mostly useful as a mocking tool during unit tests.
AFAIK redis has tests, you don't need to rewrite tests for redis in Java. Mocking implies test assertions in the Mock. I'm sure redis driver for Java has tests too. That's what you should mock.
Of course I simplified things by only implementing keys and sets, rather than all the operations such as hashes, etc. But allowing pluggable storage back-ends made it useful for my use-case(s).
Note that this is not a full reimplementation of Redis in Go, but rather a framework for implementing a Redis-like server in Go.
If what you are looking for is a Redis implementation, I did create a Redis v1 clone in Go a while back. It's is only a proof-of-concept and lead to the development of Redcon.
If you need an easy to write, debug, and operate RPC tech for building networked components with minimal dependencies/effort, writing Go servers with RESP (iirc, REdis Serialization Protocol) is surely the way to go. I've built several of these things (although, with a custom RESP parser), and, from my experience, the ROI is pretty high -- it's up there with bash scripts for getting stuff done.
54 comments
[ 1.9 ms ] story [ 114 ms ] threadThis can be used coupled with a backend storage to provide custom redis servers.
It's not a redis implementation by itself.
redis is already very bare-bones and dead simple to set up and maintain, what more does one want? Wouldn't adding more logic into a redis-like environment be a little cumbersome from an architecture perspective?
You could expose a memcached cluster as a redis server using this. (Not sure why would you want to do that.. Maybe if you have an existing memcached cluster and have redis client code?)
Or you could go crazy and implement the entire set of redis commands on top of sqlite and call it a "strongly persistent redis" or something like that.
It's just a nice building block, I'm sure people would find ways to abuse it :)
Of course the existing benchmark shows that the example Go implementation is faster. For one, the Go implementation provided avoids a lot of functionality that the Redis server implements, such as TTL checking.
I believe disque, the distributed message broker [2] uses the redis protocol for client server communication.
[1] http://redis.io/topics/protocol [2] https://github.com/antirez/disque
Just because the language is really hyped right now?
https://news.ycombinator.com/item?id=9741625
Basically - Go had a very strong focus on web servers from the start, making it easy to pick up and develop web servers with. Web developers make good early adopters - they'll pick up new tools faster than almost any other group of developers. Rust was released without any of those tools, and they're still changing as the ecosystem develops (especially around async frameworks). And even with that, there's a fair few companies using it for all sorts of cool things: https://www.rust-lang.org/en-US/friends.html
The only reason it gained any traction is the big name of the mothership...
No at all. It's very far from even remotely decent implementation, the interface is too inconsistent and full of implicit behaviors and the performance is an order of magnitude slower than anything acceptable. But anyone actually using it already knows..
I liked the goroutine related apis though.
What I remember being PAINFULLY slow is reflection. Which is very inconvenient for certain tasks (building objects from db queries, (json) serializing,...). Macros could help here, but alas, code generation is the only alternative available. Which I'm not a fan of.
---
What's are your gripes with Gos CSP?
I initially really liked it. But the languages designers just skipped over countless years of achievements in language design and implemented a C with garbage collection, with interfaces and a baked in CSP runtime.
If you read a bit in the groups / release notes, they were just too lazy to implement generics. Or it was too hard.
Go's ecosystem is really weak (for example, barely any library does proper versioning or any release procedure at all).
I think that is at least part due to the difficulty of writing clean, generic code. And the lack of proper packaging.
The lack of features is not a selling point, even if they try.
At least Go can generate it's own hype, and doesn't need to piggyback on others.
Everyone should at one point write their own compiler. And maybe their own OS.
(I'm only half kidding here)
Capability systems? Network transparent message passing? Dynamic load-balancing of running processes across machines? What if you tried to let users script their workflows in a less ad-hoc way than they can now? How about trying to replace the concept of a filesystem, at the same time as trying to encourage applications to share data with each other?
OS development research died a couple of decades ago, and now we have an entire generation of developers who believe the Linux/POSIX model to be the one true system. But IMHO, that's just a quirk of fate, and a local maxima, and it keeps people in the dark about alternative solutions to their problems. For example, capability system advocates will point out that their system almost implements Docker/containerization by default. There have been tons of experiments with efficient message-passing under microkernels which would likely benefit anyone attempting to design Yet Another IPC Framework in the Linux kernel. And so on and so forth.
AFAIK redis has tests, you don't need to rewrite tests for redis in Java. Mocking implies test assertions in the Mock. I'm sure redis driver for Java has tests too. That's what you should mock.
https://github.com/skx/predis
Of course I simplified things by only implementing keys and sets, rather than all the operations such as hashes, etc. But allowing pluggable storage back-ends made it useful for my use-case(s).
If what you are looking for is a Redis implementation, I did create a Redis v1 clone in Go a while back. It's is only a proof-of-concept and lead to the development of Redcon.
https://github.com/tidwall/sider