RFC: Roadmap 1.0

[andylokandy]

Objectives

Stabilize the core instrumentation API while preparing for long-term maintenance and ecosystem growth.

Proposed Changes

1. Extract Statics to Core Crate

• Create fastrace-core with shared static state and minimal types
• Allow any facade version to connect to any collector version
• Enables independent evolution: libraries can upgrade facades without breaking applications' collector setup
• Prevents version conflicts in dependency trees

2. OpenTelemetry 1.0 Dependency (Optional)

• Wait for opentelemetry-rust to stabilize .

3. Property Value Type Decision

• Current: Cow<'static, str> (maximum performance)
• Alternative: Variant values like OTel (more flexible, potential complexity)
• Need to decide: Stick with current approach for simplicity/performance, or adopt OTel-style variants for ecosystem compatibility?

Questions for Community

• Are there API pain points that need addressing before 1.0?
• Preference on property values: performance-first vs ecosystem compatibility?
• Any concerns about the core crate separation approach?

[andylokandy]

cc @Xuanwo @zhongzc @tisonkun @MrCroxx @breezewish @ranger-ross @kutal10 @izissise @fiadliel @ivanrg99 @bkane-msft @EAimTY @shehabgamin @qRoC @ethercflow

[tisonkun]

OpenTelemetry 1.0 Dependency (Optional)

Since we use a dedicated fastrace-opentelemetry for catching up otel-rust usage, we can first stabilize the core libs, especially, fastrace. And then evolving fastrace-opentelemetry on its own. This should not be a blocker for fastrace's 1.0.

[breezewish]

IMHO people who reaches to this library has a clear expectation: maximum performance. OTel variants are performance destroyers. So if someone want better OTel compatibility instead of better performance than he/she should looking at other libraries I think.

[andylokandy]

OTel variants are performance destroyers.

With the current implementation, the facade is completely separated from the background reporting. So no matter how slow otel is, fastrace will stay fast. Therefore, it's unnecessary to concern about the otel integration.

[EAimTY]

IMHO people who reaches to this library has a clear expectation: maximum performance. OTel variants are performance destroyers. So if someone want better OTel compatibility instead of better performance than he/she should looking at other libraries I think.

Just out of curious, is there any benchmark backing this?

[ArniDagur]

OTel variants are performance destroyers. So if someone want better OTel compatibility instead of better performance than he/she should looking at other libraries I think.

What is the suggested alternative to OpenTelemetry if you care about performance?

[dgrr]

@ArniDagur you can develop your own collector and therefore your own protocol

[andylokandy]

What is the suggested alternative to OpenTelemetry if you care about performance?

No need for alternative AFAICS. otel is not slow, instead, it has high latency and high throughput. And fastrace has optimized for multiple backends including otel with this problem addressed.

So if someone want better OTel compatibility instead of better performance than he/she should looking at other libraries I think.

So this statement is not true (was true when before v0.4).

[lpj145]

IMHO people who reaches to this library has a clear expectation: maximum performance. OTel variants are performance destroyers. So if someone want better OTel compatibility instead of better performance than he/she should looking at other libraries I think.

I disagree about the point of choosing this crate only for performance reason, I was for entire year trying to build something great with tracing + log facing every day difficult times to understand all the logic that they choosed: adapters, bridges, adapters, if you want to make tracing work's with all things that Otel + all the stack of observability stay prepared to have your own trace library on your project this is the truth, I know tracing has a lot of possibilities but this flexibility cost a huge price: it's August 2025 and we are not observable yet, not smooth 😄

[KodrAus]

Property Value Type Decision

I would personally advocate for some way to capture at least numeric types as values. You could forgo support for complex types like sequences and maps, although everyone eventually ends up there, but not being able to attach numeric values to spans is a limitation people will hit.

You could keep your options open by creating a Value newtype around the Cow<str> and implementing From conversions for str, Cow<str>, String, etc. I'd also consider doing that for the key type too, since there are optimizations you can consider for keys that aren't possible when you don't control the layout of the type.