Automates a tedious, time-consuming task. Easy to catch and correct failures. Love it. My only concern is (other than maybe verbosity) is of my log writing moments are opportunities to briefly reflect on what I have written, and maybe catch problems early.
The thing I like here is that it runs locally. I use Vim keyword completion[1] a lot for next-word completion. It does a broadly similar sort of "look at surrounding code to offer good suggestions" thing (no LLM stuff, of course). It's wrong often, but it's useful enough that it saves me time overall, I feel.
So, this sounds to me like an expanded version of that, more or less.
I think I'd prefer an AI future with lots of little focused models running locally like this rather than the "über models in the cloud" approach. Or at least having such options is nice.
> The amount of cognitive overhead in this deceptively simple log is several levels deep: you have to first stop to type logger.info (or is it logging.info? I use both loguru and logger depending on the codebase and end up always getting the two confused.) Then, the parentheses, the f-string itself, and then the variables in brackets. Now, was it your_variable or your_variable_with_edits from five lines up? And what’s the syntax for accessing a subset of df.head again?
What you're describing is called: programming. This can't be serious. What about the cognitive overhead of writing a for loop? You have to remember what's in the array you're iterating over, how that array interacts with maybe other parts of the code base, and oh man, what about those pesky indices! Does it start at 0 or 1? I can't take it! AI save me!
And once you have enough experience, you realize that maintaining your focus and managing your cognitive workload are the key levers that affect productivity.
But, it looks like you are still caught up with iterating over arrays, so this realization might still be a few years away for you.
Abstraction has always been a part of programming. Are you going to deride someone for not remembering how to write a sorting algorithm from scratch when .sort() is available? This is just another instance of that, trivial as it may be. The next abstraction level for programming is just natural language, if you want to try to gate keep that, have fun.
The section you refer to is a justification for code completion and possible providing (visual) feedback for whether a various constructs are spelled or used correctly. It is fairly established that sort of thing increases programmer productivity (as in writing a Java program using notepad vs. writing it using IntelliJ).
In the old days, we used to do this by using static type inference. This is harder to do in dynamic languages (such as Python), so now we try to do it with LLMs.
It is not obvious to me that LLMs are a better solution; you may be able to do more but you loose the predictability of the classic approach.
> What you're describing is called: programming. This can't be serious
What that statement is telling me is that the author at one point didn't consider logging to be a fully fledged formal non-functional requirement, more of an optional and/or informal side chore.
I used to work at a company that built software for mobile networks; their entire C codebase was full of logging statements, pretty much every step made in processing a signal was logged. Probably as a form of tracing, and automated instrumentation would possibly have been a better solution, but they were a bit old fashioned.
I relate to this. The cognitive overhead of a for loop is, honestly, way less for me writing a log. There's something about writing logs that's a PITA.
What you’re describing is useless noise that shouldn’t even be a blip on my radar.
Programming is solving a problem, not learning 20 different ways to say Log, logger, lumber, timber, and whatever else “creative” name writer of logger library chose to use.
> What about the cognitive overhead of writing a for loop? You have to remember what's in the array you're iterating over, how that array interacts with maybe other parts of the code base, and oh man, what about those pesky indices! Does it start at 0 or 1?
I am old enough to remember people complaining about having to write a semicolon at the end of each line. Or declare a variable...
I'd like to consult the HN hive mind on an tangential point.
Does anyone else here dislike loguru on appearance? I don't have a well-articulated argument for why I don't like it, but it subconsciously feels like a tool that is not sharp enough.
Was looking for evidence, either way, honestly. The author is using loguru here and I've run into it for a number of production deployments.
It looks great out of the box, has fancy colors (if you want them).
It is easier to configure than logging and you don't need a lot go get_logger stuff. It does log rotation, and you has lazy formatted {} comments `logger.info("x={x:.2f}", x)`. It is better for threading/multiproc, handles exceptions better. And it is fast. I like it on appearance.
Loguru sucks very badly!
I would advise you not to use it. It is like trying to not do like everyone else, but still doing in a terribly wrong way ...
For example the backtrace try to be cooler for display but are awful, and totally not appropriate to pipe in monitoring systems like Sentry.
In the same way, as you can see in the article, that is the only logging library that doesn't accept the standard %-string syntax to use instead its own shitty syntax based on format.
The {} syntax is better, and more similar to f-strings. And you don't have to use that backtrace. I use it to send json for some batch jobs, or have it write to google cloud logger for gcp jobs. Are you holding it wrong?
I appreciate how the author highlighted the python domain-specific tricks like dropping imports and rewriting tabs/spaces. It's good to be reminded that even with "large" language models you can get better results with quality over quantity.
An aside, but it’s quite unfortunate that logger.info and logging.info are automatically linkified because of the .info TLD in this case. I don’t recommend clicking on those links.
I know, it's not as nice looking. But the advantage is that the logging system knows that regardless of what values var takes that it's the same log. This is used by Sentry to aggregate the same logs together. Also if the variable being logged also happens to contain a %s then the f-string version will throw an exception. It doesn't matter because f-strings are so fast but the % method is also lazy and doesn't interpolate/format if it's not going to be logged. Maybe in the future we'll get to use template strings for this.
Well if you use loguru (and really you should, it is awesome) you would use, `logger.info("Super log {var}", var=var)` (possibly without the keys). It is also lazy and works better for structured logs.
This tracks with how I've been doing my debug logs.
I ask the model to create tons of logs for a specific function and make sure there's an emoji in the beginning to make it unique (I know HN hates emojis).
Best thing of all, I can just say delete all logs with emojis and my patch is ready. Magical usage of LLMs
The use of AI for this seems somewhat overkill, one could just use a language and environment that is aware of whether `logger` or `logging` is available, and what variables are in scope. We have tools that allow us to treat programming as more than guessing the next character at random. Rather they allow you to offload tracking this context to the machine in a reliable way, typed languages and auto complete.
I do wonder if this is part of the divide in how useful one finds LLMs currently. If you're already using languages which can tell you what expressions are syntactically valid while you type rather than blowing up at runtime the idea a computer can take some of the cognitive overhead is less novel.
I once wrote a simple python program that logged all execution, self inspected code and printed code and variables as output.
Then I learned why programs don't do that by default.
Not to be snarky, but when you become more experienced you will figure out that logging is just writing to permanent storage, one of the most basic blocks of programming, you don't need a dependency for that, writing to disk should be as natural as breathing air, you can do print("var",var). That's it.
If you are really anal you can force writing to a file with a print argument or just a posix open and write call. No magic, no remembering, no blogpost. Just done, and next.
On the one hand writing logs can be tedious. Essentially logs are breadcrumbs signifying when significant state changes have logically taken place. From what I've seen, logs are added after every few lines and I always fantasized about creating a language where logging is "automatic".
On the other hand, writing logs is a skill worth mastering. Wrote too many and when a service crashes you have to shift through lots of noise and potentially miss the signal. I once went down a rabbit hole trying to root cause an issue in a Gunicorn application that had custom health check logic in it. An admin worker would read health check state from a file that worker threads wrote to. Sometimes a race condition would occur, in which an error log would be emitted. The thing was, this error wasn't fatal and was a red herring for why the service actually crashed. Of instead it would have been logged at the debug level a lot of time would have been saved.
Fine let LLMs write code but take logging seriously!!!
Tab autocomplete in Cursor is surprisingly good at guessing what I want to log when I type slog.Info. I’m enjoying that time save.
I agree with K&R about debuggers: when writing services that you need to debug in prod, you live and die by your logs. That said, sometimes an interactive debugger is faster than adding logs, like when you’re not sure about the precise call stack that leads to a given point, or there’s a bunch of stuff you need to keep track of and adding logs for all of it is tedious. But pretty quickly you can hit a point where you’re wasting more time in the debugger than it would’ve taken to add those logs…
Usually, people use AI for reading logs, looking for interesting events or patterns. That goes way back. Microsoft was using it to classify and group similar crash dumps back in the 1990s.
Rust lets you write a default debug print for each struct, and will generate one if asked. So you don't have to write out all the fields yourself. That's enough to do the annoying part of the job.
I thought this was going to be about an AI which actually writes useful logs for your program. Eg if it crashes, it explains in normal language what happened.
Visual studio added the single line autocomplete thing a while back and it lasted about 2 days before i turned it off because it was frequently wrong and just got in the way. I often use the double tab template insert feature, but that would often accept the incorrect autocomplete instead, so i had to delete it and try again
49 comments
[ 5.9 ms ] story [ 125 ms ] threadI can throw up a basic sketch, focusing on the code, and get it to add the quality stuff after.
So, this sounds to me like an expanded version of that, more or less.
I think I'd prefer an AI future with lots of little focused models running locally like this rather than the "über models in the cloud" approach. Or at least having such options is nice.
[1] https://vim.fandom.com/wiki/Any_word_completion
There's also omni-completion, a bit more advanced: https://vim.fandom.com/wiki/Omni_completion
What you're describing is called: programming. This can't be serious. What about the cognitive overhead of writing a for loop? You have to remember what's in the array you're iterating over, how that array interacts with maybe other parts of the code base, and oh man, what about those pesky indices! Does it start at 0 or 1? I can't take it! AI save me!
And once you have enough experience, you realize that maintaining your focus and managing your cognitive workload are the key levers that affect productivity.
But, it looks like you are still caught up with iterating over arrays, so this realization might still be a few years away for you.
In the old days, we used to do this by using static type inference. This is harder to do in dynamic languages (such as Python), so now we try to do it with LLMs.
It is not obvious to me that LLMs are a better solution; you may be able to do more but you loose the predictability of the classic approach.
What that statement is telling me is that the author at one point didn't consider logging to be a fully fledged formal non-functional requirement, more of an optional and/or informal side chore.
I used to work at a company that built software for mobile networks; their entire C codebase was full of logging statements, pretty much every step made in processing a signal was logged. Probably as a form of tracing, and automated instrumentation would possibly have been a better solution, but they were a bit old fashioned.
If you feel copying and pasting documentation is programming, you’re gonna have a really rough time.
Programming is solving a problem, not learning 20 different ways to say Log, logger, lumber, timber, and whatever else “creative” name writer of logger library chose to use.
I am old enough to remember people complaining about having to write a semicolon at the end of each line. Or declare a variable...
Does anyone else here dislike loguru on appearance? I don't have a well-articulated argument for why I don't like it, but it subconsciously feels like a tool that is not sharp enough.
Was looking for evidence, either way, honestly. The author is using loguru here and I've run into it for a number of production deployments.
Anyone have experiences to share?
For example the backtrace try to be cooler for display but are awful, and totally not appropriate to pipe in monitoring systems like Sentry.
In the same way, as you can see in the article, that is the only logging library that doesn't accept the standard %-string syntax to use instead its own shitty syntax based on format.
I ask the model to create tons of logs for a specific function and make sure there's an emoji in the beginning to make it unique (I know HN hates emojis).
Best thing of all, I can just say delete all logs with emojis and my patch is ready. Magical usage of LLMs
I do wonder if this is part of the divide in how useful one finds LLMs currently. If you're already using languages which can tell you what expressions are syntactically valid while you type rather than blowing up at runtime the idea a computer can take some of the cognitive overhead is less novel.
Typing "log" and tab to accept the auto complete is faster than writing the whole log yourself.
When you need to add a bunch of log statement, this tool makes the activity faster and less tedious.
Is it a technological breakthrough? No
Does it save hours of developer time each day? No
Is it nice to have? Hell yeah
Then I learned why programs don't do that by default.
Not to be snarky, but when you become more experienced you will figure out that logging is just writing to permanent storage, one of the most basic blocks of programming, you don't need a dependency for that, writing to disk should be as natural as breathing air, you can do print("var",var). That's it.
If you are really anal you can force writing to a file with a print argument or just a posix open and write call. No magic, no remembering, no blogpost. Just done, and next.
You mean like this?
...or something more like this?Do you know if there's a similar solution for vscode?
On the other hand, writing logs is a skill worth mastering. Wrote too many and when a service crashes you have to shift through lots of noise and potentially miss the signal. I once went down a rabbit hole trying to root cause an issue in a Gunicorn application that had custom health check logic in it. An admin worker would read health check state from a file that worker threads wrote to. Sometimes a race condition would occur, in which an error log would be emitted. The thing was, this error wasn't fatal and was a red herring for why the service actually crashed. Of instead it would have been logged at the debug level a lot of time would have been saved.
Fine let LLMs write code but take logging seriously!!!
I agree with K&R about debuggers: when writing services that you need to debug in prod, you live and die by your logs. That said, sometimes an interactive debugger is faster than adding logs, like when you’re not sure about the precise call stack that leads to a given point, or there’s a bunch of stuff you need to keep track of and adding logs for all of it is tedious. But pretty quickly you can hit a point where you’re wasting more time in the debugger than it would’ve taken to add those logs…
Rust lets you write a default debug print for each struct, and will generate one if asked. So you don't have to write out all the fields yourself. That's enough to do the annoying part of the job.
The Goland and Pycharm experience must be radically different from the Java experience then.