Drahflow

Zero to two, depending on how you count, exactly.

It's a side-project from our consultancy work. We're two deep technologists and so far entertaining the notion that we're very bad at (product) sales. But we're trying to learn that now.

> in cost and resource usage

Nah, it's fine. Storage of raw logs is pretty cheap (and I think this is widely assumed). For querying, two problems arise:

1. Query latency, i.e. we need enough CPUs to quickly return a result. This is solved by horizontal scaling. All the idle time can be amortized across customers in the SaaS setting (not everyone is looking at the same time).

2. Query cost, i.e. the total amount of CPU time (and other resources) spent per data scanned must be reasonable. This ultimately depends on the speed of the regex engine. We're currently at $0.05/TB scanned. And metric queries on multi-TB datasets can usually be sampled without impacting result quality much.

The point that the trinity of logs, metrics and traces wastes a lot of engineering effort to pre-select the right metrics (and labels) and storage (by having too many information triplicate), is a good one.

> We believe raw data based approach will transform how we use observability data and extract value from it. Yep. We have built quuxLogging on the same premise, but with more emphasis on "raw": Instead of parsing events (wide or not), we treat it fundamentally as a very large set of (usually text) lines and optimized hard on the querying-lots-of-text part. Basically a horizontally scaled (extremely fast) regex engine with data aggregation support.

Having a decent way to get metrics from logs ad-hoc completely solves the metric cardinality explosion.

I usually try leave work-time flexible in contracts. Would be cool to have "up to X hours/week" as availability option.

;) Yes. It works exactly as you envisioned it. You can do it with pretty much everything, actually:

  |dump =*clap
  [ "pa" |dump /tsch < > 0.0 ] ==slow slow clap
  # [
  #   "pa"
  #   <function: 00006000001CCD00>
  #   "tsch"
  #   <scope: 00006000004B3360>
  #   +0.0e0
  # ]

I think it's a good thing (tm) that { x sin } could be valid code with x pushing the value of x whereas sin is executing the value of sin.

Theoretically speaking, I need at least the deff and defq distinction, otherwise { } could not be invoked during "parse" time. The defv case could in principle be removed, but as * needs to execute (otherwise nothing ever will), execution would need to be the default or I would need to decide based on dynamic type. The first option would mean a lot of superfluous {} (or | actually) around normal data variables, the second one would destroy the nice similarities between arrays, strings and functions with integer domains.

There are semicolons :) They do sequential function composition:

{ /foo dump } /f defv { /bar dump } /g defv

f g ; /h deff

h # "foo" "bar"

The storage is exactly the same, the difference is only in what will happen if the name is encountered somewhere.

{ 2 } /putTwoOnStack deff

{ 2 } /putClosureOnStack defv

putTwoOnStack dump # 2

putClosureOnStack dump # <function 0006002514AE5>

putClosureOnStack * dump # 2

It is self targeted snark allright. Not just not doing it with LISP, but also ignoring pretty much everything I learned about compiler building in university.

Define "inspired". I became aware of Forth while implementing Elymas. But the decision to make it stack based was actually because I was too lazy (after some attempts) to implement a correct LALR-parser-generator.