RedisGears is a very functionality: for now we can use it with C and Python scripts… Other language will be supported such as Java. I wonder which other language will be, Ruby maybe (I am a Ruby enthusiast :smile)
@Michaut we are working these days on addding JVM support.
So once we have it, you should be easily be able to run Java, Groovy, JRuby, Scala…
1 Like
Can we get Rust before JVM? I think it will fit better.
Don’t forget Kotlin!
Hey @gkorland, can we do Rust already? It’s playing in more or less the same space a C. I know that you can write modules in C.
Technically you can write your gear in Rust instead of C.
Looking forward for examples using Gears in Rust, any starting points would be appreciated.
I honestly not sure if Rust will fit to be a Gear function. I mean we will send an .so file that need to be open using ‘ldopen’ and will contain the logic? Also this .so file need to be distributed to all the shards, we will need to consider symbols overlaps, compile it on the right OS and probably more issues that I yet thought about. I think Rust will better match with webassembly.
That said, if one wants, he can integrate Rust with Gears api using Gears C api. The way it will work is by writing a Redis module (in Rust off course) That will load the api published by RedisGears. The api is given in this file https://github.com/RedisGears/RedisGears/blob/master/src/redisgears.h (please notice that this api is not yet final and might change in future version, this PR already introduce couple of changes to the api https://github.com/RedisGears/RedisGears/pull/344). Using this api it is possible to create distributed executions and registrations. To see an example of how to do it, it is possible to look how to python interpreter does it (https://github.com/RedisGears/RedisGears/blob/35140e7cc49e16c116f868be616ec8fb09c0fb32/src/redisgears_python.c#L1601)
So I can see a use-case where one wants to write a Redis module that gives some general functionality like summarize a field value in all the hashes on Redis cluster, and it uses RedisGears to create such an execution and expose it with a new command (like ‘sumfield foo’), but I think that dynamically send a Rust code that will define a Gear function and runs it will better fit to run inside webassembly sandbox.
1 Like
Hi,
and what about languages such as Ruby or Kotlin ? Do they also unfit in Gears ?
Those are more suitable to be gear function as it can also run on the jvm (Kotlin). As @gkorland said we are currently working JVM implementation.
Hello @meirsh,
Thank you, you gave me really cool idea to think about - writing Redis modules in Rust.
Personally I think JVM support is a road to oblivion, the path Basho traveled with Riak:
- Architecturally when core product have memory requirements in 10+ MB but deployment requires 400+ MB due to add-on it stops being attractive option.
- Gears becomes part of the crowd with very established players and technology - what is the differentiation over running Scala/Kotlin jobs on Spark? Why then choose Redis?
- Deployment options - challenges you highlighted for Rust deployments will equally be applicable to java: I presume you are targeting OpenJDK, what about oracle JDK support etc.
Gears becomes part of the crowd with very established players and technology - what is the differentiation over running Scala/Kotlin jobs on Spark? Why then choose Redis?
Data locality, especially if your data is already in Redis for other reasons and now you want to extend your application usage.
Deployment options - challenges you highlighted for Rust deployments will equally be applicable to java: I presume you are targeting OpenJDK, what about oracle JDK support etc.
We might support Oracle JDK in the future if needed, but license wise we prefer to support free JDKs like OpenJ9