Hacker News new | comments | show | ask | jobs | submit login

You're totally missing my point(s). Of course web programming is tied to the browser, but why does that mean debugging via logs has to be tied to whatever particular console is attached to where a program is running? Why can't I have a console.table() equivalent in Python, and Ruby, and C, and Go, and Java that all can render via a common protocol to any viewer that can handle it?

By printf I didn't _literally_ mean printf -- I meant any logging type equivalent whether that IS printf or a built-in logging system. The point is there's no inter-op between them with any rich detail, which prohibits universal log viewers.

When I say travel over the network, I don't mean scp. I mean allow my iOS/Raspberry Pi/local Erlang server device to stream in real-time it's logs to any viewer that I want, whether that's on the same device or somewhere else in the world. That's the kind of portability required when you can't guarantee that complex display can be part of the same system that generated it -- that's a unique quality of web browsers. IT'S ABOUT THE PROTOCOL, NOT THE MECHANISM.

Text is great, and most logs will be in text. But I also sometimes want to inspect data, or expand JSON, or view an image, etc etc. But let's even stick with text -- a good viewer would let me set up filters on a host of structured qualities -- filenames, lines, log levels, keywords, etc. It would output in a way that allows me to easily view such info in a UI that supports infinite scroll back, easy copy/paste, elegantly formats so different log instances are clearly separate from each other, adds color to enhance readability, allows me to hide/collapse sections or duplicate entries, provides columns for the structured logging fields like timestamps, allow interactive sorting on these columns like Excel, etc etc all without losing my data.

Apple's Console.app is an elementary example of what I'm suggesting I'd like to see. Except I don't want it tied to the syslogs of an Apple device. I want every language/platform to be able to output to it in real-time. And for it's capabilities to be as rich or richer than what we have in the browser. We already have universal text editors like VIM/Emacs -- why can't we have universal log viewers?




> Text is great, and most logs will be in text. But I also sometimes want to inspect data, or expand JSON, or view an image, etc etc. But let's even stick with text -- a good viewer would let me set up filters on a host of structured qualities -- filenames, lines, log levels, keywords, etc.

So, it sounds like you want a debugging library you can include in the language you are using to output structured debug lines and a client side that goes along with it to represent the usefully (or just use text+JSON and a JSON aware client), and to just stick it on top of syslog. I think that pretty much covers what you're asking for.


>So, it sounds like you want a debugging library you can include in the language you are using to output structured debug lines and a client side that goes along with it to represent the usefully (or just use text+JSON and a JSON aware client), and to just stick it on top of syslog. I think that pretty much covers what you're asking for

Except the most important thing: that ability to be included as standard, readily available, and well supported in languages.


Well, that's why I specified it as a library. A C compatible Lin is likely easiest for most languages to trivially support through an FFI, and it all it's doing is outputting structured text based on the input, that's trivial to hook up. It's not like it can be too language specific because if it's supposed to work in a bunch of languages, it has to be generic enough to handle them.

Although in the end you probably aren't getting much out of it, as a dynamic language is fairly easy to just pump stuff through a JSON converter, and static/strongly typed ones probably require enough boilerplate that the added benefit is slight.


"printf" will always have it's place, because when things are hosed, there's a good chance you can't push stuff to network, but things have to be really hosed to stop you pushing some chars to a UART.

> I mean allow my iOS/Raspberry Pi/local Erlang server device to stream in real-time it's logs to any viewer that I want, whether that's on the same device or somewhere else in the world.

e.g. syslog (RFC5424)? -e- You can even add some extra fields of your choosing if you so desire: https://tools.ietf.org/html/rfc5424#section-6.3

> But let's even stick with text -- a good viewer would let me set up filters on a host of structured qualities -- filenames, lines, log levels, keywords, etc. It would output in a way that allows me to easily view such info in a UI that supports infinite scroll back, easy copy/paste, elegantly formats so different log instances are clearly separate from each other, adds color to enhance readability, allows me to hide/collapse sections or duplicate entries, provides columns for the structured logging fields like timestamps, allow interactive sorting on these columns like Excel, etc etc all without losing my data.

e.g. ELK, Graylog etc?


lnav + mitmdump!


lnav looks really neat. Thanks!


"Why can't I have a console.table() equivalent in Python"

I get a console.table() equivalent in Python by using Jupyter Notebook, which is a web-based REPL shell, and pandas, which is a library for working with tabular data. Pandas displays HTML tables when used with Jupyter.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: