I really do love what kdb is doing but I think maybe they lost too much momentum (and confidence) when back flipping on previous agreements for the community editions. (Which I don't think they will again with the kdb-x releases as they have a good balance this time) It would have been nice to see torqx just work (tm)
I liked this framework when I used it years ago but I've become disillusioned with kdb.
I can ask Claude to write specialized rust based tick processing tools so quickly now. So the baseline use case for kdb is eroded away, at least for me.
I love kdb as a distributed services framework. But if I can write it with redis and python with Claude support in all the boilerplate I'm more likely to go that route.
If you're looking to use this with the community edition I would recommend reading through https://dataintellect.com/blog/running-torq-with-kdb-x-commu... as they outline some of the factors that need consideration.
I really do love what kdb is doing but I think maybe they lost too much momentum (and confidence) when back flipping on previous agreements for the community editions. (Which I don't think they will again with the kdb-x releases as they have a good balance this time) It would have been nice to see torqx just work (tm)
This used to be aquaq. What happened?
I liked this framework when I used it years ago but I've become disillusioned with kdb.
I can ask Claude to write specialized rust based tick processing tools so quickly now. So the baseline use case for kdb is eroded away, at least for me.
I love kdb as a distributed services framework. But if I can write it with redis and python with Claude support in all the boilerplate I'm more likely to go that route.
Relevant blog post: https://dataintellect.com/blog/april-relaunch/
Can we get an eli5?