The main goal was to help security engineers / analysts, who _loathe_ sql (for better or worse).
I tend to think this is a little more user friendly, personally, and it's nice to give some open-source competition to the major languages that are used in security (SPL, Sumologic, KQL, and ES|QL).
We were surprised that there weren't syntactic competitiors (i.e. -- while prql has some similar goals, the syntax and audience in mind were very different)
How's perf for the compiled queries? The first thing I see in the examples is what appears to be a CTE-by-default approach that, in most (all?) engines, means the generated query ultimately runs over an unindexed (and maybe materialized!) intermediary resultset.
I hate to shill in this thread, but that's exactly what we built at runreveal, so I completely agree! We saw the power of clickhouse when we were at segment and cloudflare, so built a company around it.
And since clickhouse is open source, we hope that people will stop giving their security data to vendors who then charge you rent for it. I think the future is writing this data to clickhouse, but also our customer's clickhouses
The json parsing library that parses the config file allows either syntax. That was intentional since we get in the habit as go programmers of ending lines in structs/maps with commas, it's just for convenience.
Serious question though, why use "JSON" at all then? You can just admit it's JWCC, which is fine, at least that's a distinct term -- but even that's not a spec, it's just a blog post that very few people even know about. Even that same blog post endorses using TOML, the spec generally preferred for things that may need to be human-edited. It meets humans half-way a lot better than even JWCC, which is the kind of practicality I think even Grug would prefer.
I'm happy you fixed it. I would have nearly lost my mind too. Hopefully figuring out the issue and fixing it is as rewarding as the problem was maddening
There have been instances in chess where cheaters get caught and they receive light bans and many top players say the punishment is too weak. It's intuitive, if you've been caught cheating then you should be banned from competitive chess. I think that's more likely what Magnus thinks.
It should suffice that you can be proven not to be cheating right here and right now. Unlike doping, getting assistance helps you only exactly as long as you continue getting it.
I don't agree with the person you're replying to; it's unfair to permanently ban people from competitive play for online cheating they did when they were younger (although not that much younger in this case).
however, without overly expensive and invasive methods of detection, plus unpleasant rule changes, what you describe isn't feasible. there are too many ways to cheat, and people who are already smart enough to play at a grandmaster level are not only going to find these ways, but excel in them.
I don't have any evidence to back this up, but I would be extremely willing to believe that plenty of high-level OTB cheating has gone on over the years, especially with money on the line
Good sportsmanship is important in any competitive game or match. When you cheat you should be banned. Maybe not forever but for a significant amount of time. Say 2 years in chess would seem reasonable. Enough to sting but not enough to end a career.
Where's the lack of consistency? They do it once per year, but have the option to do it more and aren't limited to once per year.
One is clearly a policy, while the others are written not in legalese.
