ofseed

Yes. Even though 3.8 Flash outperforms 3.1 Pro in benchmarks, in my use cases, 3.8 Flash is completely inferior to 3.1 Pro.

Specifically, 3.8 Flash suffers from far more hallucinations than 3.1 Pro and frequently ignores the context between consecutive messages. These two issues are fatal to the chat experience.

Because of this experience, I believe that benchmarks are quite limited to evaluate a model's real-world performance, and most current benchmarks focus on coding performance rather than chatting. At the moment, I have almost no reason to use 3.8 Flash.

Can it surpass (or at least maintain) 3.1 Pro when it comes to chatting?

I've been using GPT since its 3.5 release, but starting from 5, its output always contains some meaningless nonsense or provides answers that are difficult to read just to avoid hallucinations. I find Gemini to be excellent for chatting. For example, when I'm pondering a mathematical theorem, it could provides answers that inspire me, even guiding me to think about the next question.

For me, this is the only reason to maintain multiple AI subscriptions. Gemini is irreplaceable in the realm of answering questions or chatting for learning purposes; I can leave the rest to GPT.

Spot on. It genuinely surprises me how many people don't realize that vim's persistent undo feature resets if the file is modified by anything outside of vim itself.

For example, a common scenario is rolling back a file via git, which triggers this reset. However, considering they treated it as a reliable version control system without actually reading the documentation, they probably aren't using git anyway.

The good news for them, however, is that they actually can bypass this limitation and treat their undo history like version control—by using nvim-fundo [1]. The catch is that they'll have to switch to nvim, as there isn't a direct equivalent for vim.

1. [nvim-fundo](https://github.com/kevinhwang91/nvim-fundo)

It is worth noting that before rewriting in Rust, Bun maintained a fork used to accelerate the compilation and informed those who asked that this fork could never be merged due to Zig's zero-LLM policy.

A few weeks later, Bun began the Rust rewrite. Although not explicitly stated, I suspect these two events may be related.

That's the main reason. TUI programs can be created quickly, and they're mostly developer-oriented, so they just need to be useful enough and don't need to be optimized as much as a GUI program.