39 ms·

I got confused by the usage of the term "log" (and the word gets used so much in many pages that I hit semantic satiation). > When you log data to the Rerun SD

I got confused by the usage of the term "log" (and the word gets used so much in many pages that I hit semantic satiation). > When you log data to the Rerun SDK, Rerun handles everything needed to visualize it. It handles live streams from multiple processes across the network, as well as simple playback from recordings. That means taking care of serialization, transport, synchronizing streams, out-of-order data, and automatically constructing visualizations with sane defaults. so is "record" / "recording" the right concept? When I think of logging I think of exactly lines in a text file (or maybe the "log" from a logging filesystem).

deleted 4y ago
[deleted]
nikonp 4y ago
One of the founders here. I totally see where you’re coming from. If you come from a world where log equals text, then using log for anything else seems strange. In robotics and autonomy, “log” is commonly used for e.g. sensor data or planning decisions as well. But even outside those fields it isn’t uncommon to talk about logging metrics for instance. Still, no metaphor is perfect and we have spent a lot of time discussing what word to use. “Record” gives me the sense that the main purpose is to save the data for later. Rerun is also about the live use case. There words like “stream” or “send” could work perhaps. In the end we decided on “log” because it is short, is already used in a similar way in some of the areas we hope Rerun will be used, and because data can either be stored on disk and/or be streamed/uploaded somewhere (like with regular text logs).
jeremyleibs 4y ago
Hello -- Rerun developer here. You are correct on both counts. The terminology used in some places is a bit inconsistent, and "recording" is very much the right concept to apply to the data that Rerun captures. However, one of the reasons we tend to think of our APIs as being "logging" like is that much like other console-logging libraries, the primary purpose is to get data out of your program and into a user-observable form. Also similar to other logging libraries, the APIs are intended to have no side affects on your program so they can actually be disabled with a function call or by setting an environment variable in situations where you don't need the additional context for debugging or inspection. I appreciate the feedback though and will make sure to take a pass on the docs to see if I can make the relationship and intent a bit more clear.

deleted 4y ago

[deleted]

nikonp 4y ago

One of the founders here. I totally see where you’re coming from. If you come from a world where log equals text, then using log for anything else seems strange. In robotics and autonomy, “log” is commonly used for e.g. sensor data or planning decisions as well. But even outside those fields it isn’t uncommon to talk about logging metrics for instance. Still, no metaphor is perfect and we have spent a lot of time discussing what word to use. “Record” gives me the sense that the main purpose is to save the data for later. Rerun is also about the live use case. There words like “stream” or “send” could work perhaps. In the end we decided on “log” because it is short, is already used in a similar way in some of the areas we hope Rerun will be used, and because data can either be stored on disk and/or be streamed/uploaded somewhere (like with regular text logs).

jeremyleibs 4y ago

Hello -- Rerun developer here. You are correct on both counts. The terminology used in some places is a bit inconsistent, and "recording" is very much the right concept to apply to the data that Rerun captures. However, one of the reasons we tend to think of our APIs as being "logging" like is that much like other console-logging libraries, the primary purpose is to get data out of your program and into a user-observable form. Also similar to other logging libraries, the APIs are intended to have no side affects on your program so they can actually be disabled with a function call or by setting an environment variable in situations where you don't need the additional context for debugging or inspection. I appreciate the feedback though and will make sure to take a pass on the docs to see if I can make the relationship and intent a bit more clear.