tstack

> If I recall correctly, it was developed as an alternative (Go port) of a popular log analyzer

Hmm, I think you might be mixing things up, goaccess is written in C and probably not written as an alternative to lnav.

Let the healing begin!

> That is not necessarily true. simdjson exists.

I am speaking exactly of simdjson. If you look closely, you'll see that the high performance is really only achieved by skipping over large chunks of the input data. Which is great, if your use case is operating on a subset of data. But, if the application really needs to process every piece of the entire input, there's no performance win.

Think about it, JSON structure is almost entirely made up of single bytes ({ } [ ] , : "). If you're not skipping over stuff, you're not going to get away from having to examine those bytes and branch on them. For something like `{"a":1,"b":2}`, the SIMD scan has a bunch of overhead to find the interesting parts and then you go back and practically have to reprocess every single byte.

> what can be fast

I think this doesn't get talked about enough. If your input is a big run of data that is being checked/transformed in one shot, it works well. But, if you're likely to have to make a decision on several bytes of the input, SIMD will be the same or slower than the scalar method. It's not a magic "go fast" button.

> Looks like Mr. Kelly agrees with you. From the zen of zig:

... what? No one is going to argue against those vague statements. He obviously does not agree with people that put more weight on making things compile errors instead of runtime errors. Which is fine, but saying he is in agreement is nonsense.

> Considering every memory safe language that I’m aware of panics on index out of bounds, there’s spectrum here.

Many of those languages go to great lengths to avoid raw indexing: rich iterators, arenas with branded indexes, checked gets, and so on... But, sure, if you ignore all that and do `get(i).unwrap()`. Then, yes, things are exactly the "same".

I have no problem with people choosing the set of tradeoffs that works for their context. I have a problem with people acting like those tradeoffs don't exist.

You are leaving out other trade-offs, like the program crashing when something memory-unsafe is done. It is not simply a performance trade-off. Many folks would rather have the language catch this at compile-time instead of hoping that the test suite exercises all the code in just the right way to tickle the bug.

> Another key pro to capabilities is that you can actually have a memory safe interface without having to leak lifetime and other info across boundaries.

One of the benefits of having lifetimes in the type system is thread-safety. Again, there is a lot of focus here on just memory-management: use-after-free, double-free, etc... But, being confident in the code running in a threaded environment is important as well.

> With the first and only commit 2 hours ago, the author of this project didn't let it "bake". They didn't exercise it locally to see what issues it might have, and I have a hard time believing the very first iteration of this software is perfect.

You have no idea whatsoever how many iterations were done before the initial commit. The VCS log is not representative of anything that happened before the first public release. Even before LLMs, people would grind away on stuff until they were happy and then put it in a VCS for public consumption.

> You just got a tiny taste of what Rust enthusiasts have been doing to every C++ related submission

Which is what C++ enthusiasts have done to C enthusiasts and C enthusiasts have done to assembly enthusiasts.

> there were still people chiding the project for not using Rust

Please provide a link to this comment.

Someone asked an honest question and got reasonable responses that were informative. At no point did anyone chide the project for not using Rust.

> Rust might be a fine language but it has the most toxic evangelist culture, bar none.

Nah, people complaining about the supposed toxic community are noisier than the supposed toxic community.

re: man page - It looks like there is no support for man pages from the snap infrastructure. So, there's not much I can do.

The "stable" version of the snap is really old (circa 2023) at this point because I have been shy about bumping it. The candidate and edge versions are more recent and should be more usable.

Thanks for your time.

> Kinda neat but I had trouble using it. Not sure what it is doing or what it is even showing me.

Can you elaborate a little more? lnav behaves like a pager with the conventional hotkeys for basic stuff. I'm not sure what else you are expecting.

> Also a nitpick but the colors are quite garish

I enjoy colors, so there's a lot going on by default. There are several themes builtin. You can configure the "grayscale" theme by running:

    :config /ui/theme grayscale

> At that time lnav basically just kept everything in memory.

lnav has never really kept the contents of files in memory. It does build an index of every line in a file. One exception is that it will decompress small gzip files and keep them in memory as a tradeoff from decompressing on the fly.

The memory consumption has never been a problem for me. So, it's not something I've ever focused on.