C# has a dictator with a budget: Microsoft integrated async into C# in a formal way, with 5.0, including standard libs, debugging, docs, samples, clear guidance going forward, etc. What holes there were were dealt with in an orderly and timely manner.
JavaScript actually had a pretty messy start with async, with divergent conventions and techniques. Ultimately this got smoothed out with language additions, but it wasn't all that wonderful in the early days. Also, JavaScript started from a simpler place (single-threaded event loop) that never had "fork" and threads and all that comes with those, so there was less legacy to accommodate and fewer problems to overcome.
Python had a vast base of existing non-async software chock full of blocking code, plus an incomplete and haphazard concurrency evolution. There are several legacy concurrency solutions in Python, most still in use today. Python async is still competing and conflicting with it all. Not unlike the Python 2->3 transition.
>Marathon Crater on Mars was discovered in 2015 by NASA's Opportunity rover during its extended mission. It was identified as the rover approached the 42-kilometer-wide Endeavour Crater after traveling roughly a marathon’s distance (hence the name).
>>is it a crater?
>>>Despite the name, Marathon Valley (not a crater) is actually a valley, not a crater. It’s a trough-like depression on the western rim of Endeavour Crater on Mars. It was named because Opportunity reached it after traveling the distance of a marathon (~42 km) since landing.
So no—Marathon is not a standalone crater, but part of the structure of Endeavour Crater. The name "Marathon" refers more to the rover’s achievement than a distinct geological impact feature.
That reaction is very different from the Marathon crater one though it uses the same pattern. I think OP's reasoning that there is a naive commitment bias doesn't hold. But to see almost all LLMs to fall into the ambiguity trap, is important for any real world use.
The other aspect is it can’t reliably tell whether it „knows” something or not. It’s conditioned to imitate the corpus, but the corpus in a way is its „universe” and it can’t see the boundaries. Everything must map to something _in_ the corpus.
This isn’t true — LLMs can generalize and synthesize information not in the corpus. You can ask one to create a new written language and get a grammar and vocabulary that is nowhere in the corpus.
How come there is not the equivalent of a stable diffusion "sampler * selection for LLMs? The restart sampler for stable diffusion is so good compared to most of the original samplers. I often try to get an answer from the LM studio people but I think I really should ask the llama.cpp people.
I love fzf but no need to invent the wheel here if you are using zsh. check out one of these zle plugins. (Demo https://asciinema.org/a/155704)
I prefer these two, you get good performance, search that is semi-shell syntax aware, ranking that takes age somewhat into account, and syntax hilighting.
Also one of fzf major yet non obvious feature is that you can use fzf in many places, which means that the fuzzy search algorithm and behaviour is exactly the same whether I search for shell history or project files in vim or commit messages or...
There's nothing more annoying than having two fuzzy search implementations that behave mostly the same except in this or that case which subtly breaks your implicit mental model of it.
Right, and fzf is usable across all major shells, which is a big plus. For example I use zsh at home, but at work I'm forced to use bash for everything, but it works there just the same. Plus you can bend it to other purposes than just a fancy history lookup
tv's file previewer is active per default, for fzf you have to hack it via --preview arg. subjectively tv is searching faster and previewer works faster than the fzf-preview.sh
It is obvious that tv is blocking on file preview. I can hold up key and zip up and down in fzf. In tv it causes obvious jank, I guess it waits for every file to render. Fzf doesn't make this mistake because preview is async. It's a clear winner when input lag is concerned.
Author here—thanks for trying out tv and for sharing your feedback, I really appreciate it.
The preview window in tv is designed to compute its content asynchronously. This approach ensures smooth input handling and maintains overall UI responsiveness. You can test this yourself by using a custom preview command that simulates a delay, like so:
tv --preview "sleep 1 && echo 'the preview'"
You'll notice that even with a delay, the UI remains responsive and doesn't block.
That said, I'm sure there's always room for improvement, and I'd be happy to hear your thoughts or suggestions if you're open to discussing it further.
I believe this is just a matter of framerate. You may increase it to make those jumps invisible to the human eye ('tv --frame-rate xx') but that inevitably comes with a cost in terms of cpu usage which tv tries to keep at a minimum.
This is primarily a matter of which tradeoff suits most users I guess :-)
I tried it with --frame-rate=60 but there was no change, still selection noticeably lags compared to fzf.
Maybe your preview is async but it feels like it is updated for almost every item while I scroll through the list. Fzf preview is debounced and updates after selection stops.
Also when I test it in a dir with a 100 MB text file fzf will become slightly less smooth when scrolling selection, kind of like tv. However in that dir "tv text" will completely fail and not find any string in that file.
