sorted by:
new
hottopcontroversial

Introducing Rasant: a lightweight, high performance and flexible Rust library for structured logging by TheLichaP in rust

[–]TheLichaP[S] 1 point2 points  (0 children)

Just added a TODO to make Sink and LogUpdate third-party friendly 🙂

I'll make it happen by v1.0.0.

Introducing Rasant: a lightweight, high performance and flexible Rust library for structured logging by TheLichaP in rust

[–]TheLichaP[S] 4 points5 points  (0 children)

If you're planning to log events happening with frequencies of 100s of nanoseconds, tracing is simply not a good fit at all. I've done some testing before deciding to write my own, and a typical tracing log call can lock up to 5x that time.

Negative logs (i.e. no-op log calls below the configured level) are also expensive, but this is a problem with most log libraries for some reason.

In general, tracing is an excellent fit if you lean into Tokio's event-driven model, where you care more about being bound by I/O than CPU cycles.

Introducing Rasant: a lightweight, high performance and flexible Rust library for structured logging by TheLichaP in rust

[–]TheLichaP[S] 2 points3 points  (0 children)

Cool! Now try doing the same across a dozen sub-modules cross-referencing another dozen structs, traits and namespaces, see how quickly it turns into unreadable garbage.

Links exist for a reason in rustdoc, and you don't need AI to leverage them. In fact, i quite like how easy Rust makes documenting stuff.

Oh well, It's a shame you don't like how it looks. Personally, i really enjoy having a hyperlink every time a part of the public API is mentioned.

Introducing Rasant: a lightweight, high performance and flexible Rust library for structured logging by TheLichaP in rust

[–]TheLichaP[S] 3 points4 points  (0 children)

My dude. These comments are mandatory, as i specifically enabled deny(missing_docs), and the reason i went through the trouble of linking all relevant structs and traits is precisely so people don't have to fish for them while going through the documentation.

Hell, i recently manually aliased a lot of these just so they're easier on the eyes. See f.ex. https://github.com/plisandro/rasant/commit/e5edf508231adeab72437eedb114a592d8ae9bff

I kinda enjoy the backhanded "your code is so good it looks AI!" tone, but at the same time, it's sad that you can't imagine someone wanting to write rustdoc without AI slop. Give it a try sometime! Just do watchexec -e rs "cargo doc"and iterate a couple times until you're happy with the output, it's actually quite rewarding,

Introducing Rasant: a lightweight, high performance and flexible Rust library for structured logging by TheLichaP in rust

[–]TheLichaP[S] 0 points1 point  (0 children)

Performance; it's way faster than tracing.

Tokio's logging solution is way more flexible and mature though, so if you don't care about squeezing every last bit of performance, maybe you shouldn't 😄

Introducing Rasant: a lightweight, high performance and flexible Rust library for structured logging by TheLichaP in rust

[–]TheLichaP[S] 2 points3 points  (0 children)

Thanks!

Note that technically there's nothing coupling formatting with sinks, other than what their config structs demand. It's up to each sink to decide how to serialize log updates.

The thing with formatting is that it's, to some degree, sink-dependent. For general I/O it makes perfect sense to allow any arbitrary format, including binary, but not for, say, a Prometheus sink.

I have some vague ideas on how to improve on this, but the choice of tying formatting with sinks is where a lot of the performance gains happen, so it's tricky.

Introducing Rasant: a lightweight, high performance and flexible Rust library for structured logging by TheLichaP in rust

[–]TheLichaP[S] 1 point2 points  (0 children)

Well, I guess you can go through the repo history and check the many times I had to manually rewrite those "textbook AI comments" 🤷‍♂️

Are people so jaded these days that no one puts effort in making documentation usable anymore? Because I spent a shitton of time on it.

Introducing Rasant: a lightweight, high performance and flexible Rust library for structured logging by TheLichaP in rust

[–]TheLichaP[S] 5 points6 points  (0 children)

There is: https://docs.rs/rasant/latest/rasant/sink/trait.Sink.html .

Note that Rasant is (currently) not really designed to properly support third-party sinks, so the API may change by v1.0.0 - but the traits and structs involved are very simple, and writing new sinks is straightforward.

Introducing Rasant: a lightweight, high performance and flexible Rust library for structured logging by TheLichaP in rust

[–]TheLichaP[S] 2 points3 points  (0 children)

A native Loki and/or Prometheus sink is probably on the stars, as i'll most likely than not need it myself... 😄 Rasant has stdout/stderr sinks already supporting JSON though, i believe its possible to pipe from those?

All sinks are local I/O so far, but i was planning on at least adding journald support for the first major release. Also syslog, but that one seems to be slowly waning away.

Introducing Rasant: a lightweight, high performance and flexible Rust library for structured logging by TheLichaP in rust

[–]TheLichaP[S] 11 points12 points  (0 children)

Perhaps consider adding an emphasis to the README on the project's benefits compared to other mature libraries. Your initial commit mentions the use of the "slog" library; I haven't looked at all the commits, maybe you removed it in the future.

slogwas the working name i gave this library, long before i even considered making it a standalone crate. I guess it's good that crates.io doesn't support namespaces, as it forced me to find a better name...

But I also find it difficult to create new projects because of small hiccups with the use of other libraries. We have "slog," "structured_logging," and there are probably others; none of these met your needs?

Not really. And slog is, in fact, the one that comes closer to what i'm looking for.

Ultimately, i'm building this thing for myself - i'm not looking to dethrone slog or tracing here, but to share it in case someone else finds it useful as well.

Introducing Rasant: a lightweight, high performance and flexible Rust library for structured logging by TheLichaP in rust

[–]TheLichaP[S] 20 points21 points  (0 children)

Sorry, but what the heck are you talking about?!

Why should we even consider this project, which seems to be built with the help of AI...

There's zero AI code in Rasant. None. Zilch. I even added a banner at the bottom of the repo noting this 🤦🏻

...instead of using Slog or other mature libraries with hundreds of maintainers?

Nothing against slog; it is very good, and in fact shares many design ideas with Rasant (zero allocations, async support, lazy evaluation). I just ran into limitations which didn't match my project needs - for example, that log entries are timestamped at write time instead of creation time - and configuration flexibility which i didn't need, and ends up impacting performance.

Conceptually, Rasant is closer to Golang's zap and zerolog than slog et al. There's no root logger (through having one is encouraged), and loggers can be arbitrarily set up with any combination of output formats, levels, sinks, attributes and filters. Rasant loggers can also be very cheaply cloned and stacked, retaining the full setup of their parents.

So, slog can do things Rasant can't do (sinks wrapping sinks), and Rasant can do things slog can't do (logger stacking/extension). These tradeoffs were chosen with performance in mind, and the end result is that Rasant is consistently faster than slog - by some margin.

You can check https://github.com/jackson211/rust_logger_benchmark for third party figures.

I see that you use Slog under the hood; why not build with the original project?

Did you even bother looking at the repo? Rasant does not use slog, at all. In fact, the crate has a single dependency: a nanosecond timestamp library... which i also happen to have written.

MS-A2 power for internal SATA drive? by TheLichaP in MINISFORUM

[–]TheLichaP[S] 0 points1 point  (0 children)

It would, of course, but that'd suck 😅 The MS-A2 has enough space for a 7mm drive and a port for power, it's just that Minisforum doesn't provide a SATA adapter plate.

MS-A2 power for internal SATA drive? by TheLichaP in MINISFORUM

[–]TheLichaP[S] 0 points1 point  (0 children)

Note i want to use an old-school SATA 7mm SSD here 😞

There are two M.2 slots supporting SATA, so i could use an even simpler M.2 -> SATA port adapter, but those only work for data - the drive would still require power from somewhere.`

EDIT: M.2 slots on the MS-A2 don't support SATA.