bloom VS tracing

Static linking is remarkably easy: Creating small Docker images is a delight.

As a data point, I've served millions of HTTP requests using it, without problems.

For larger projects, I think that actix-web is the incontestable winner. That's why it's my choice for Bloom.

For me the worst part was not the job itself (I did ML related stuff) but the environment (commuting, artificial light all day long...).

Since I moved to the entrepreneurship track I'm way more happy. At first it doesn't pay so you need to have savings, but after some time (depends of the person) you start making a living and you can decide on what to work on.

Today, half of my time is dedicated to writing software that I genuinely believe have a positive impact on the world (https://github.com/skerkour/bloom), and half of my time is dedicated to writing and sharing (I'm writing a book).

The best thing that I've understood is that even if my primary skills are programming and architecture related stuff, it doesn't mean I have to code for a living. There are a lot of jobs related to programming that you can switch to.

Hi, I'm not a video game programmer, I mostly do network and web programming, but I do exactly this in Rust and it works very well. Here is an example for a mailer driver, which is a trait and then implemented for multiple "backends" such as AWS SES or SMTP https://github.com/skerkour/bloom/blob/main/bloom/kernel/src/drivers/mailer/mod.rs.

What do you think about degoogle project open source => https://bloom.sh/ " The simplest way to de-Google your life and business: Inbox, Calendar, Files, Contacts & much more ".

What do you think about degoogle project open source => bloom.sh " The simplest way to de-Google your life and business: Inbox, Calendar, Files, Contacts & much more ".

The video description is as follows:

In this stream, we peel back the crust on the tracing crate — https://github.com/tokio-rs/tracing/ — and explore its interface, structure, and mechanisms. We talk about spans, events, their attributes and fields, and how to think about them in async code. We also dig into what subscribers are, how they pick up events, and how you can construct your own subscribers through the layer abstraction. For more details about tracing, see https://docs.rs/tracing/latest/tracing/.

> What's been your biggest issues around ergonomics/amenities for OpenTelemetry?

I can't speak generally, but in the Rust ecosystem the various crates don't play well together. Here's one example: <https://github.com/tokio-rs/tracing/issues/2648> There are four crates involved (tracing-attributes, tracing-opentelemetry, opentelemetry, and opentelemetry-datadog) and none of them fit properly into any of the others.

The tracing (logging) mechanism in an asynchronous codebase (tracing).

Tracing is Tokio's alternative for async code.

At a technical level, in Rust, both [tracing]https://crates.io/crates/tracing) and log are entire ecosystems (though for the latter at least there's also third party logging frameworks), and there's at least a bridge from log to tracing.

I am using https://github.com/tokio-rs/tracing for logging purposes in my application. I would like to develop a feature wherein logs should be saved to a database table (via sea-orm). Something similar is this, but it does not solve my needs fully.

I've used the tracing infrastructure with tracing_flame to profile some hot paths in async code: https://github.com/tokio-rs/tracing/tree/master/tracing-flame

Oh nice! IIRC when I checked, it was the Unicode tables that smashed the code size. I recently hit the same issue with the tracing crate, where a crate feature (for env var filtering) pulled in regex and my binary was suddenly 1MB bigger.

I know about tools such as tracing, jaeger or tracy. While having a complete tracing could be a potential solution, these tools don't work with no_std.

tracing by itself only outputs log data, you need to consume them in a subscriber, the tracing-subscriber crate exists for this. (example)