dd-trace-rb VS inner_performance

This action starts two Ruby on Rails APIs, one instrumented with ddtrace and another with OpenTelemetry SDK, both connecting to an OpenTelemetry Collector that sends data to Jaeger:

Thing is, once you have 1) and 2), the added complexity of bringing in, integrating, and writing for a different tool to achieve 3) begins to make little sense, when you can just go along and do it just as well in rspec anyway... It's a matter of balance and heavily depends on the project.

> if you're still at Datadog

As a matter of fact I am. Feel free to shoot me an email.

    curl -s https://github.com/DataDog/dd-trace-rb/commit/176c642ca73679cabc5fa1a113bc9b600aa04dcd.patch | grep '^From:'

> For myself, I'm fine with the typing being in a separate .rbs file

We type[0] by having one separate .rbs file per .rb file. Works really well with an editor's vertical splits: type outline on one side, code on the other. That, or use something like vim-projectionist[1].

[0]: (WIP: there's a huge codebase to type, but we're progressively getting there) https://github.com/DataDog/dd-trace-rb/tree/master/sig

[1]: https://github.com/tpope/vim-projectionist

Thanks! I'll pass it on to the team :D

I've got to say, the folks at Intercom made it particularly fun. They were sending us traces and graphs from their internal systems when we trying to figure out some issues with them (e.g. we ran into this datadog context problem: https://github.com/DataDog/dd-trace-rb/issues/1389)