
Why We’re Building Flux, a New Data Scripting and Query Language - pauldix
https://www.influxdata.com/blog/why-were-building-flux-a-new-data-scripting-and-query-language/
======
tylerl
> I don't want to live in a world where the language I speak evolved slowly
> over the past 1600 years.

Also, this? This is the illustrative example you chose for your amazing new
query language?

    
    
        square = (table=<-) => {
          table |> map(fn: (r) => r._value = r._value * r._value)
        }
    

So you're saying you're combining the expressiveness of SQL with the
readability of, what, perl?

~~~
jarym
Agreed. The reason SQL rules is that nothing has really come into existence
that is as or more powerful AND easier.

I used to hate writing SQL (I still do somewhat) but I took the time some
years ago to really learn the language and once you do that you appreciate a
few things:

1\. Yes it requires a high mental load to craft something sophisticated

2\. I can’t think of a ‘better’ alternative to SQL that isn’t a compromise.

3\. You can do a crap load of stuff with joins, procedures and CTEs once you
understand it.

~~~
blablabla123
> 3\. You can do a crap load of stuff with joins, procedures and CTEs once you
> understand it.

Yes, or you can skip that part and do the tricky part in an actual programming
language ;) For instance in Haskell or JavaScript. There is then even a chance
that the code is both fast and actually works. :D

I mean in the end this is just a cheap marketing trick to literally buy people
into the platform. People can write it into their CVs. The whole Influx
ecosystem looks great. Although the UI (Grafana) is slow as hell once there
are enough Graphs in and if you need fail-over or scaling, you need to buy an
expensive license.

Also already the existing query language is obscure and counter-intuitive.

~~~
okket
> Yes, or you can skip that part and do the tricky part in an actual
> programming language

But then

\- you miss out the power of the query optimiser

\- you have to transfer a lot of unnecessary data

\- have a harder time to enforce consistency

\- have a harder time to enforce access rules / security

There are good reasons to do as much as possible in the database and not in a
programming language in the backend or even worse, the frontend/browser.

~~~
srean
I don't think that follows.

Many of the optimizations you mention (for example the first two) may in fact
be removing baggage that probably would not have been there in the first
place.

------
georgewfraser
SQL definitely has weaknesses, but I wish people wouldn't use "straw man"
examples to crap all over it. The flux example from his blog post would look
something like this:

    
    
        select 
            lag(value, 0) over recent * 1 + 
            lag(value, 1) over recent * 0.5 + 
            lag(value, 2) over recent * 0.25 + 
            ... as exp_moving_avg
        from telegraph
        where time > datetime_sub(current_datetime(), interval 1 hour)
        and measurement = 'foo'
        window recent as (order by time rows 10 preceding)
    

Here, the main difference between flux is that flux has a built-in exponential
moving average function, whereas in SQL we have to actually write out the
formula.

~~~
techno_modus
> Here, the main difference between flux is that flux has a built-in
> exponential moving average function, whereas in SQL we have to actually
> write out the formula.

The possibility to provide arbitrary data processing functions is one of the
core features of contemporary query languages. In SQL it has always been a
huge problem (and your example is a good demonstration). In the example
provided by they also rely on a built-in (exponential smoothing) function and
therefore it is not clear whether I can really perform arbitrary ad-hoc
computations within the query itself (without built-in or externally defined
functions).

~~~
Twisell
> The possibility to provide arbitrary data processing functions is one of the
> core features of contemporary query languages.

Yes and this is actually a big selling point of PostgreSQL based solutions.
It's important that peoples don't confuse Modern SQL solutions with the ones
they may have encountered decades earlier or comparison with NoSQL will indeed
be unfair.

------
rs86
SQL has a very solid ground in research - a lot of - in relational algebra. If
you try to make a query language that is a dsl for anything without a really
different data model underneath, you will accomplish nothing great.

~~~
repsilat
In the world of "theory meets engineering" SQL is pretty embarrassing too.
Read this: [https://www.dcs.warwick.ac.uk/~hugh/TTM/HAVING-A-
Blunderful-...](https://www.dcs.warwick.ac.uk/~hugh/TTM/HAVING-A-Blunderful-
Time.html)

Just being built on the relational model is a tiny part of what makes SQL what
it is (which is largely catastrophic, as languages go.) It says little about
how queries are executed, indexes, syntax, data types, yada yada...

And the relational calculus itself isn't super lovely as a base... Turing
completeness is a nice thing to have, after all.

~~~
siscia
> It says little about how queries are executed, indexes, syntax, data types,
> yada yada...

I believe that this is the whole idea of SQL or any declarative language.

You want to express your query without saying anything about indexes, how data
are retrieved, how joins are executed and so on.

That is (suppose to be) a feature.

~~~
repsilat
Sure, those things aren't specified in SQL, but again -- that's a feature of
SQL, not the relational model. You could just as easily have an imperative
relational language as a declarative one, so those theoretical foundations can
be used to justify very little of the query language.

------
fake-name
Holy shit. The language name alone is a really, really stupid idea.

Protip: If you're inventing a new esoteric programming language (and until you
have _other_ people implementing non-trivial projects in/using your language,
it _is_ an esoteric programming language), google the fucking name first.

If googling your intended <thing's> name results in more then 1000 hits,
CHANGE YOUR <thing's> FUCKING NAME.

If you don't trying to find any resources about the <thing> on the internet
will be a huge pain in the ass. Name your project something unique.

Googling "flux" results in "About 197,000,000 results". If you just make it a
_little_ more specific as "fluxql", you get ~142 results.

People looking for language resources will actually find the shit they're
looking for, and the name actually tells you something about what it does,
which is nice.

~~~
pauldix
fluxlang is what people should be searching for and we'll continue to point
that out in future blog posts, documentation, #fluxlang on Twitter and SO and
everywhere else. People got there with Go, so I assume people will get there
with Flux if the language is successful.

~~~
fake-name
People got there with Go because google is _huge_.

If you're going with fluxlang, don't call it anything but "fluxlang".
Referring to the same thing multiple ways is even worse.

------
jwdunne
I'd be interested in seeing a language that can take full advantage of the
architecture in Out of the Tarpit.

It's always touted as a must read paper but I haven't seen many inroads
towards something truly Functional-Relational.

I don't think a new query language is the solution to the problem. SQL isn't
that bad. Sure, for sanity, every language has a reimplementation of SQL
syntax using whatever abstractions available. But even if you don't go SQL,
you've got datalog.

A language being 40 to 50 years old doesn't make it a problem. I'm speaking
English - that's been through 2000 years of iteration. I don't think that
makes it a good candidate for a ground up rethink when so much thought by
great thinkers has already gone into it.

~~~
dnomad
SQL is a bad solution to the wrong problem.

After 50 years it remains non-intuitive and confusing and extracts a tax
penalty far greater than its value add. Worse, the problem it claims to solve,
"I have all my data in one database now let me transact over it", isn't viable
and was never actually viable at scale.

Unfortunately this proposal doesn't understand the real problems with SQL
(lack of types, lack of distribution, and no separation between the data write
model and the data read model). It actually doesn't seem to introduce anything
really new that can't be done using CEP Engines already.

~~~
jwdunne
Do you have any recommendations on where to read about the problems of SQL?
When you put it this way, clearly my assertion that "SQL isn't bad" needs a
review.

~~~
techno_modus
There have been many critiques of SQL for example:
[https://sigmodrecord.org/publications/sigmodRecord/1306/pdfs...](https://sigmodrecord.org/publications/sigmodRecord/1306/pdfs/11.reports.atzeni.pdf)

~~~
jwdunne
Thanks for this :)

I ask for recommendations because I don't know what I don't know. I've read a
few criticisms of SQL where some conclude "just use mongodb". A good
recommendation from an expert helps avoid faulty understanding.

------
fnordsensei
I've been writing Datalog for the last week or so. It took me a bit to adapt
to the syntax (also, [1] helped), but now I find myself enjoying the
combination of terseness and expressiveness.

It's probably a matter of familiarity, but looking at Flux, it seems both
noisier than Datalog and less readable than SQL.

Given that readability is a goal for Flux, I guess it's a matter of
subjectivity: readable for whom? What background do you have in order for Flux
to look readable?

1: [http://www.learndatalogtoday.org/](http://www.learndatalogtoday.org/)

~~~
pauldix
On some level, readability is a subjective thing. So is expressiveness and
general feel for a language. It's about aesthetics and reasonable people can
disagree about language and API design choices. We're making our choices and
we hope that a good number of people come to agree with them. However, part of
the engine design is to decouple the language from the actual execution. The
engine takes a DAG represented as a JSON object. We'll have parsers that
create that DAG from Flux or from other languages like PromQL or anything that
people might think of.

------
meritt
> Writing a SQL equivalent example of that query is, at this point, beyond my
> SQL capabilities.

Let me get this straight, someone who doesn't know SQL is going to solve all
of the deficiencies of SQL by inventing something new?

InfluxDB is awesome and the syntax looks great, but please spare me the
"problems" you're solving when you can't write a simple moving-average query.

~~~
tanilama
They are just building a subset of semantics which SQL supports, and no join.
Nothing to see here.

~~~
rbetts
I'm the dir. of eng. for the team building flux. Before that, I built a
transactional SQL system (during peak NoSQL hype). I like SQL.

After a year+ of watching people use InfluxQL and thinking about the types of
user experiences that timeseries specific platforms can offer - I'm eager to
see flux enter the world.

People like exploratory and notebook like environments. Building a language
that integrates with those workflows and even supports a REPL for writing
queries is a nice fit to this space.

InfluxDB chooses a non-relational data model. Timeseries queries almost all
filter on terms, partition, window, group - and then apply a sequence of
functions to those groups. Most queries end up using SQL analytic functions
that many users aren't experienced using... while mapping a only vaguely-
relational (and very non-normalized) data model to boot.

The timeseries space is visual - visual tooling really matters. SQL isn't an
easy fit there, either. It is hard to write SQL incrementally or to interpret
just part of a SQL query to show intermediate results. Additionally, users
expect a large set of non-standard SQL functions to be builtin.

There are competing systems betting explicitly on SQL and others choosing a
functional approach, a strong competition of ideas and practices which should
be a win for end-users.

(And to correct the above comment, flux expresses select, project, and join
operators.)

~~~
nwmcsween
when making a new project I honestly believe the best way of doing it is
documenting other projects, in this case SQL, datalog, etc and why the choices
they made were not what you wanted and the alternatives and why $x was chosen,
this way if people disagree with your design you can refer to the research you
did.

------
pauldix
Author here, I just noticed that this got picked up so I'm late to the party.
I suppose I'll take the bait and aim to clarify one thing that I think is
funny people are getting hung up on. My line: "I don’t want to live in a world
where the best language humans could think of for working with data was
invented in the 70’s"

Read in context, the meaning of that sentence isn't that things invented
decades (or centuries or millennia) ago are all bad. I even state that SQL is
a great and powerful tool. If you took from the post that I think SQL is shit
and needs to be replaced, you weren't paying attention.

The point of that line (and really the point of us creating Flux) is that we
think there can be a more elegant and understandable language (read: API) for
working with time series data. But that we won't get there by trying to
improve SQL. You don't build an automobile by creating better wheels for your
horse and buggy.

Also, SQL isn't a language like English. SQL is an API and APIs change all the
time. Yes, code is communication, but its form evolves much more quickly than
spoken and written language between humans.

~~~
MechanicalTwerk
>> If you took from the post that I think SQL is shit and needs to be
replaced, you weren't paying attention.

Why, why, why, why, why???? I didn't even have to look it up and I could
already tell from your attitude in your blog post and this comment that your
company is based in SF and backed by a bunch of VC money. And why is it that
the systems software startups always have the worst attitudes to boot?
Usually, when a bunch of people take something from an article that wasn't
intended by the author it's because the author did a poor job not because a
whole bunch of people don't get it or aren't paying attention. The arrogance
is unbelievable.

------
nishantvyas
"I don’t want to live in a world where the best language humans could think of
for working with data was invented in the 70’s. I refuse to let that be my
reality."

\---- re-play the same sentence for c/SQL/ENGLISH ---

I don’t want to live in a world where the best language humans could think of
for "communicating" was invented in the (c. 550–1066 CE). I refuse to let that
be my reality.

So, I'm starting new language...

sdflakfj lsjkfaldfj sdfkjaslf dflkasjdfk sldfkjaslf laskfdas....

\------ P.S.: Any technology is built over time with sedimentary layers...
every layer has played key role in where we are today.. I'd not discount
any...

------
justinmk
The post doesn't mention datalog, but Dedalus/Bloom[1] makes a good case for
why datalog is a good starting point for a data query language.

1\.
[https://www2.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-...](https://www2.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-173.html)

2\.
[https://www.youtube.com/watch?v=R2Aa4PivG0g&t=2295s](https://www.youtube.com/watch?v=R2Aa4PivG0g&t=2295s)

------
fiiv
All the words in the english language (not to mention place names, words in
other languages/transliterations), possible acronyms, etc, and they choose one
that already has a Facebook-promoted architectural pattern using it.

Not sure if arrogance or ignorance, perhaps just apathy?

------
andyfleming
It seems more complicated than necessary. Why not a syntax like...

    
    
        from("telegraf")
          .range(-1h)
          .where(_measurement, "foo")
          .exponentialMovingAverage(-10s)

~~~
dsego
What's wrong with a pipeline operator? JS is getting one as well.

[https://github.com/tc39/proposal-pipeline-
operator](https://github.com/tc39/proposal-pipeline-operator)

Chaining calls in JS means that a function returns the original object, piping
is actually passing over the result as an argument, so it's semantically
different.

~~~
dragonwriter
> What's wrong with a pipeline operator?

Honestly, for the use case, the same thing that's wrong with a (mandatory)
visible function application operator in Haskell.

> Chaining calls in JS means that a function returns the original object,
> piping is actually passing over the result as an argument, so it's
> semantically different.

The syntax Flux uses for creating the result is the same as JS would use for
mutating an inbound object, so it actually would be consistent if pushing the
result used the same syntax as passing the (mutated) original object would in
JS.

Though I’d prefer whitespace for piping just like Haskell does for
application. If your are going to specialize a language for a domain, don't be
timid about it.

------
AlphaWeaver
>I don’t want to live in a world where the best language humans could think of
for working with data was invented in the 70’s

Maybe we just got it right relatively early!

------
Ycros
I've gone down a similar line of thinking when writing a lot of SQL over
timeseries or otherwise ordered datasets recently. Going in a more functional
and composable direction while keeping it limited so that hopefully the query
execution engine can still make good optimizations seems like the right idea.

Making it a separate and open language outside of Influx is also a great
approach - I'd love to see other databases try adopting this. I'll definitely
be keeping an eye on this project.

------
mrdoops
Looks like Ecto.

[https://hexdocs.pm/ecto/Ecto.Query.html](https://hexdocs.pm/ecto/Ecto.Query.html)

------
dragonwriter
There seems to be a lot of not understanding SQL in the SQL criticism, and the
design of the new language seems to have a lot of excess noise.

1\. If arity-1 functions are as dominant in use as the examples suggest,
mandatory named args are excessive noise.

2\. From the examples, the |> operator also looks like needless noise; code
would be cleaner and more readable if this operator was whitespace without any
other character (like function application in Haskell, but newlines should
also be acceptable) and there was a different punctuation for when that isn't
intended.

3\. This seems really noisy:

    
    
      square = (table=<-) => {
        table |> map(fn: (r) => r._value = r._value * r._value)
      }
    

Map is a transform applied to an input, so is square, so why can't it be:

    
    
      square = map(fn: (r) => r._value = r._value * r._value)
    

Or, better:

    
    
      square = map(_._value *= 2)

------
pwinnski
"We started with poorly-implemented SQL, which frustrated people, so we
decided to make something without any of the advantages of SQL instead."

------
bww
Based on all the reflexively negative comments I’ll assume that most the
participants in this thread write SQL for a living. Notwithstanding certain
ridiculous assertions on the part of the author attempting to correlate the
value of a technology with the year in which it was created this seems like a
pretty compelling idea. We use InfluxDB at my company to manage time series
data and it’s specialization for that use case has been a big benefit. I don’t
see any reason to be dismissive by default of a language designed for
interacting with data having these specific characteristics in a manner
explicitly suited to it.

~~~
fake-name
I don't write sql for a living, and the little I do in my free time is pretty
miserable.

I still think this is a really dumb idea.

SQL, as hard as it can be to do stuff with SQL, at least you can use google
for getting help. A obscure, single-database-specific with a completely un-
googleable name is going to be a complete clusterfuck to try to do anything
with it.

The name alone will make trying to get help with the language a disaster. The
fact that it will have such limited market penetration (it only works on _one
specific_ time series database) don't make the unsearchable name any better.

\------

If the author would come out and just admit they want to spend time
intellectually masturbating over query language design (I think about
inventing a "better" language in my free time too!), I'd have a lot more
respect for the project.

~~~
dsego
Isn't that the problem though? For even a mildly interesting problem you have
to google and google for a correct and usually non-obvious solution. And when
you find it, it usually works in only one dialect but not other (e.g. MS SQL
vs MySQL). It's elitism at its finest, people probably get good money too
writing obscure queries, no wonder they are so defensive. I think your comment
shows short-sightedness.

~~~
fake-name
.... _what_?

So your arguing that the solution to the annoyance of the platform-specific
nature of SQL is to create a platform-specific _language_?

Or do you think that this language won't heavily depend on the internal
implementation of InfluxDB? If you believe that, I want to know what you're
smoking. It's gotta be some good stuff.

~~~
dsego
I'm arguing that SQL is not the be-all and end-all just because it can be
googled.

~~~
fake-name
I'm not claiming SQL is great (it's not). I'm arguing that the alternative
presented is worse.

------
coldtea
> _I don’t want to live in a world where the best language humans could think
> of for working with data was invented in the 70’s_

Yeah, because languages go stale... especially those based on mathematical
abstractions like SQL.

------
lixtra
It was a bad idea to focus on Flux vs SQL.

It would be better compared to pig or pandas.

I like the approach. I find it annoying that in SQL I need more than select
privileges to write my own function or view (Aliases and WITH is all that you
can use to structure a big query). Also macros that work on all tables that
have certain columns are at best difficult to write in SQL, so there is room
for improvement.

OTOH in Flux you write something that looks a lot like the output of a
planner, so if things change in your dB you might have to modify your scripts
instead of adding an index.

------
xaduha
> I don’t want to live in a world where the best language humans could think
> of for working with data was invented in the 70’s

You don't, most popular one is. Best one is XQuery.

~~~
Latteland
xquery has a power and limitation with it's data model being xpath. sql and
relational has proven very capable of being optimized as well as being
extensible. the schema that relational systems impose at times has thought to
be too restrictive but it makes it possible to reason about the query and data
and that makes them powerful; it also helps the user to understand the shape
of their data. with systems like google's big query showing how you can have
schemaless non 1nf powerful and scalable systems still queried with sql there
needs to be a powerful and innovative system to justify moving on from sql.
having lambda like syntax for where clauses filters just looks like linq to
sql.

~~~
xaduha
> xquery has a power and limitation with it's data model being xpath.

You're conflating things, they share a data model.

[https://en.wikipedia.org/wiki/XQuery_and_XPath_Data_Model](https://en.wikipedia.org/wiki/XQuery_and_XPath_Data_Model)

------
ChrisRackauckas
They took the name of the popular Julia neual network package? That makes it
confusing.

~~~
seanmcdirmid
Flux has been used for many many many project and product names.

~~~
ChrisRackauckas
In ML? What other ML and data science software? I'm curious because I couldn't
find any. Of course a generic name is used many ways, but of course we're
talking about in context.

~~~
seanmcdirmid
Probably! A generic fictional software product name is something like “Acme
Flux,” which is analogous to John Smith for people. Given it’s common use as a
placeholder, there must be a few, here is one from 1984:
[https://www.sciencedirect.com/science/article/pii/0743731584...](https://www.sciencedirect.com/science/article/pii/0743731584900029).

It is difficult to search for though since it is such a widely used name,
probably one of the most widely used one.

~~~
ChrisRackauckas
What you link to isn't an ML software. If it's so easy to find, why not link
to one? [http://fluxml.ai/](http://fluxml.ai/) comes to mind without having to
search of course, but I am still not seeing any others.

------
wslh
Why We’re Building Flux, a New Data Scripting and Query Language? Who knows
why?

Before pedantically saying "I don’t want to live in a world where the best
language humans could think of for working with data was invented in the 70’s"
show us your breakthrough that makes us think you deserve reading across all
your article paragraphs.

~~~
illuminati1911
I don't know what "breakthroughs" you are talking about, but there are
examples and comparisons between Flux and SQL just below that sentence.

If you used the same amount of time to finish the article that you used to
write this rant, you wouldn't have to write that in the first place.

~~~
Twisell
I skimmed through the crap and was highly deceived by the example. So I think
he would still have ranted. They chose a very specific example that made their
product look good.

Beside the article start by stating that they rebranded their product influxQL
—> Flux precisely because power user found major lacking features as to
compare with SQL.

Very bad PR move.

------
tincholio
From TFA: ". This is kind of like the worst part of Lisp (nested function
calls), but even less readable. Not only was the Flux example more terse, it
was more readable and understandable."

It's kinda funny, because his forward pipe operator (suspiciously similar to
Elixir's) is the same as a threading macro, which you have in lisp (or can
trivially write if you don't)

------
yellowapple
"I don’t want to live in a world where the best language humans could think of
for working with data was invented in the 70’s"

I don't want to live in a world where the best language humans could think of
for communicating with other humans was invented in the
${CENTURY_WHEN_ENGLISH_WAS_INVENTED}70's.

------
wizardofmysore
Seems more like the XKCD comic on standards.

I really loved the tenets given, ie.. Useable Readable Composable Testable
Contributable Shareable

But post that the article really failed to connect how the new language is
going to do the above in a way no other language has done.

Also, I agree with the rest on the point against SQL, doesn't matter if SQL
was invented in the 70s, so was the many programming languages and paradigms
we use today.

PS. I don't make a living writing SQL.

------
blablablerg
these things are very easy to do and clear to write using R's tidyverse.

------
rixed
It looks indeed a lot like graphite, and since you explicitly mention in your
talk that your objective is to reimplement all the functions that are present
in graphite, why no instead present your work as a port of the graphite
language, with some extension to work on other data sources and sinks (and
dots replaced by the fat pipe)?

This is interesting to me as I'm currently working on something close: a
lightweight stream processor to allow system engineers to manipulate some
large streams of data while in flight to a database. And I've been wondering
(and still am) about the trade-offs between simple and expressive. Very early,
I decided not to be TS specific at all (since we were prevented to use an off-
the-shelf product for that reason that our data does not look enough like a TS
-- not a single time nor a single value fields). Eventually, after a few
detours, we ended up favoring a SQL like language for that reason that it's
field agnostic.

Regarding the language itself, the main differences I can see are that you
query over a time range while we process infinite streams, with the
consequence that we must explicitly tells each operation when it has to output
values (windowing); the other is that you have an implicit key and one TS by
"group" with the same key, which makes piping many operations easier (but
JOINing harder), while we have to be more specific about how to group.

So for instance, where you have:

    
    
      from(db:"foo") |> window(every:20s) |> sum()
    

we would have the more SQL-alike:

    
    
      select sum value from foo group by time // 20
    

("//" being the integer division).

Or, if you needed the start and stop additional columns added by window():

    
    
      select sum value, (time // 20)*20 AS start, start+20 AS stop group by start
    

But then, because fluxlang process a range of time while we stream "forever"
we would also have to tell when to output a tuple, for instance after 20s has
passed:

    
    
      select sum value, (time // 20)*20 AS start, start+20 AS stop group by start commit after in.time > group.stop
    

which gets verbose quickly.

But to us this constraint imposed by streaming (as opposed to querying a DB
for the data to process) is essential since our main use case is alerting from
a single box, so querying every minute the last 10 minutes of data for
thousands of defined alerts would just not work.

Another interesting difference is the type system. One thing I both like and
hate in SQL is the NULL. It's convenient for missing data but it's also the
SQL equivalent of the null pointer. So we have a type system that looks
closely on it: we support this special case of algebraic data type that a
"type?" is a NULLable "type", and that NULLs must be dealt with before they
reach a function that does not accept NULLs. For instance, there is no way to
compile a filter which condition can be NULL, and one would have to COALESCE
it first. What's your thoughts about missing data? Do you manage to avoid the
issue entirely, including after a JOIN operation?

The other difference I noticed is how nice your query editor is. For now our
query editor is $EDITOR, but my plan is to build a data source plugin for
Grafana. What do you think of this approach?

------
gaius
The ultimate fantasy of every programmer is to a) invent a new language and b)
force other people to use it. It’s OK, we all get it, it’s fine. But let’s be
honest about our motivations...

A previous employer had RQL, "relational query language". It was between
10,000 and a million times slower than SQL depending on what you were doing
(under the covers it was just generating _really bad_ SQL). But the engineer
who invented it was sufficiently well connected to get it declared the
corporate standard, so...

~~~
sudofail
I too lived the nightmare that was RQL... it was truly horrible.

~~~
tzahola
You two made me interested, but I couldn’t find anything about this RQL...

~~~
sudofail
If the OP is talking about the same RQL as I am, it was an in-house solution
that basically tried to be graphql, kafka and spark solution, all in one,
being built at the same time as the app meant to consume it. Horrible
experience.

