Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The future of kdb+?

timestored.com

Post reply on HN
Print view View original

61–70 of 72 posts

Re: The future of kdb+?

#61

Post by 7thaccount »

jcul wrote: post #55
gricardo99 wrote: post #7

Get a free version out there that can be used for many things… I think this has been the biggest impediment to kdb+ gaining recognition as a great technology/product and growing amongst the developer community. Having used kdb+ extensively in the finance world for years, I became a convert and a fan. There’s an elegance in its design and simplicity that seems very much rooted in the Unix philosophy. After I left fina…

Isn't there a free version or something? I had to write some C++ code in the past to send data into kdb and also a decoder for their wire protocol. For both I definitely had a kdb binary to test against. I just needed to test against it. Maybe Kx gave us a development license or something, it was a good few years ago.

They do have a free version for non-commercial work.

Re: The future of kdb+?

#62

Post by eru »

keithalewis wrote: post #58
socksy wrote: post #38

Earlier quoted context omitted.

I'm not sure that was ever a requirement in these industries

It is not a requirement. Just a way to weed out people who think they are special snowflakes.

I'm perfectly capable of learning obscure language _and_ thinking I'm a special snowflake. (In fact, I'm a special snowflake _because_ I am into weird languages.)

Re: The future of kdb+?

#63

Post by hysteria2024 »

Labo333 wrote: post #25

I actually quit a quant trading job after 2 weeks because they used kdb+. I could use it but the experience was so bad... People could complain about abysmal language design or debugging but what I found the most frustration in the coding conventions that they had (or had not), and I think the language and the community play a big role there. But also the company culture: I asked why the code was so poorly documented…

[dead]

Re: The future of kdb+?

#67

Post by qkdb1 »

nivertech wrote: post #45
Jorge1o1 wrote: post #30

Earlier quoted context omitted.

Their pykx integration is going a long way to fix some of the gaps in: - charting - machine learning/statsmodels - html processing/webscrapes Because for example you can just open a Jupyter Notebook and do: import pykx as kx df = kx.q(“select from foo where bar”) plt.plot(df[“x”], df[“y”]) It’s truly an incredibly seamless and powerful integration. You get the best of both worlds and it may be the saving feature of t…

I think this will only work with regular qSQL on a specific database node, i.e. RDB, IDB, HDB[1]. It will be much harder for a mortal Python developer to use Functional qSQL[2] which will join/merge/aggregate data from all these nodes. The join/merge/aggregation is usually application-specific and done on some kind of gateway node(s). Querying each of them is slightly different, with different keys and secondary indi…

Will be interesting to see what comes of some of the things that are being put on their roadmap https://code.kx.com/pykx/2.5/roadmap.html#upcoming-changes seems to be moving in a direction of an API similar to Polars

Re: The future of kdb+?

#68

Post by dotsch »

menthe wrote: post #15

Not 100% sure why it’s often idolized on HN. We’ve maintained a financial exchange w/ margining for 8 years with it, and I guarantee you that everyone was more than relieved - customers and employees alike, once we were able to lift and shift the whole thing to Java. The readability and scalability is abysmal as soon as you move on from a quant desk scenario (which everyone agrees, it is more than amazing at.. panda…

Well, I don't think the founders of that exchange complain about KDB that much. After all KDB allowed them to go to market quickly and make billions and than they changed the tech stack when demand justified it. So what? KDB was never meant to run a large exchange, but you just demonstrated that it can run a smaller one.

> ... and without any Java optimizations really ...

Come on, be honest! All of the core tech needs to be implemented in highly optimized GC-free Java. And you need to hire senior Java consultants who are highly specialized and do that for 10+ years and they also cost millions. I happen to know that BitMEX (located in Asia) has such consultants working from the EU. So, it's that easy to hire them!

Re: The future of kdb+?

#69

Post by thestgman1 »

KDB is an absolute nightmare, a barbaric piece of tech that should have never existed.

Here is a link on how you do queries: https://code.kx.com/q/basics/funsql/

TL;DR;

This is a select: q)t:([] c1:`a`b`a`c`a`b`c; c2:101+til 7; c3:1.11+til 7)

And this is another select: q)?[t; ((>;`c2;35);(in;`c1;enlist[`b`c])); 0b; ()]

Mind that these are the basic queries :)))))

The future of kdb+ is in the toilet.

Re: The future of kdb+?

#70

Post by robinzfc »

thestgman1 wrote: post #69

KDB is an absolute nightmare, a barbaric piece of tech that should have never existed. Here is a link on how you do queries: https://code.kx.com/q/basics/funsql/ TL;DR; This is a select: q)t:([] c1:`a`b`a`c`a`b`c; c2:10 1+til 7; c3:1.1 1+til 7) And this is another select: q)?[t; ((>;`c2;35);(in;`c1;enlist[`b`c])); 0b; ()] Mind that these are the basic queries :))))) The future of kdb+ is in the toilet.

The first one is not a select but syntax for defining a small in-memory table named t. You can then do a select on this table. The second is a "functional form" of select i.e. an alternative syntax for select with extended capabilities. It is an advanced feature that is rarely used, but it's there when you need it "for programmatically-generated queries, such as when column names are dynamically produced". Written in the usual syntax this particular expression is the same as "select from t where c2>35,c1 in `b`c".
Post reply on HN