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)
anonu 1 days ago [-]
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.
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.