
Redcon – Fast Redis-compatible server framework for Go - tidwall
https://github.com/tidwall/redcon
======
eknkc
Note that it's a redis serialization protocol and tcp server implementation.
It's up to you to define redis commands such as get, set etc.

This can be used coupled with a backend storage to provide custom redis
servers.

It's not a redis implementation by itself.

~~~
butabah
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?

~~~
tidwall
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.

~~~
otterley
Then please don't call it a "Redis server implementation." That is misleading,
at the very least. A "framework" would be an accurate description.

~~~
tidwall
Thanks a bunch for your feedback. I totally agree and changed the title to
"Fast Redis compatible server framework for Go".

~~~
dasil003
Doesn't seem to have taken...

~~~
omni
He meant he changed the project description on GitHub. You can't change HN
titles once they're posted afaik.

------
politician
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.

------
zzzcpan
This is a not a good way to do this kind of thing. Simple stateless redis
protocol parser and an example to use it would be a much better interface.

------
tidwall
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.

[https://github.com/tidwall/sider](https://github.com/tidwall/sider)

------
spullara
I reimplemented it in Java, including all the commands, with similar results.
Mostly useful as a mocking tool during unit tests.

~~~
rad_gruchalski
But why: [https://github.com/kstyrc/embedded-
redis](https://github.com/kstyrc/embedded-redis)

~~~
the_duke
Because reinventing the wheel is an immense amount of fun, if you get to do it
yourself. ;) A good learning experience too.

Everyone should at one point write their own compiler. And maybe their own OS.

(I'm only half kidding here)

~~~
rad_gruchalski
That's a good reason.

~~~
the_duke
Someone should tell the JS crowd though, that you shouldn't neccessarily
reinvent everything every 6 months and use it in production.

~~~
themihai
Sometimes it may worth it. FFI was never fun regardless the host language
except perhaps C++ -> C.

------
yepperino
It's not a server. You can't implement a redis-compatible server in 100 lines
of Go code. How did this make it to the front page of HN?

------
LeanderK
Do we really need one post a day on the frontpage where somebody reimplements
something in Go?

Just because the language is really hyped right now?

~~~
dominotw
i would say rust is the new kid on the block, go is old news.

~~~
the_duke
And Go is rather pointless to begin with. The only thing it get's right is the
excellent microthreads and CSP implementation.

The only reason it gained any traction is the big name of the mothership...

~~~
zzzcpan
> 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..

~~~
the_duke
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.

\---

What's are your gripes with Gos CSP?

~~~
themihai
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)

------
otterley
Editors: can you please change the title? It's not a "Redis server
implementation" at all.

