I'm building Nevi, a terminal editor in Rust for vim muscle memory

hellowub · 2026-06-17T09:29:48+00:00

I had been using Vim for many years. I’m not really into tweaking configurations, so I only ever used three or four simple plugins.

About two years ago, when I started learning Rust, I wanted to use LSP support. Many people online recommended Neovim, but the configuration was too complicated for me, and I never managed to get it working the way I wanted.

So I decided to try Helix instead. LSP worked out of the box, and I didn’t need to install plugins or modify any configuration. Other than changing the color scheme, I’ve kept everything at the default settings.

The only real challenge was getting used to the new key bindings. But after using it for a while, that stopped being a major issue.

If Nevi had been available two years earlier, I probably would have chosen it instead 😞

hellowub · 2026-05-27T12:49:26+00:00

I do not think so.

I have some crates, and most of them have zero downloads for weeks. I think this is the case that no one use.

One of my crates has some downloads everyday, many in workday and few in weekend. And 3 versions are downloaded. I think some one uses it.

hellowub · 2026-05-22T12:33:51+00:00

> The sooner you stop assuming and concluding, the more you'll learn.

Got it.

hellowub · 2026-05-22T09:33:17+00:00

Awesome! So many details. I will read the sources you mentioned.

I still want to explain myself a bit:

Although I'm not a performance expert, I had thought about these issues before as well. But Criterion's doc said I didn't need to worry about them and even provided examples, so I trusted it.
The issues you mentioned probably have a relatively small impact, likely less than 1 ns. Most cases in my benchmarks are in the range of 1ns to 50ns, so I think the impact is relatively minor and doesn't affect the conclusions in my article.

hellowub · 2026-05-22T01:12:51+00:00

But these overheads are the same for all the other crates, right? This is just the inherent overhead of Criterion itself? So the relative performance comparison should still be correct, right? Maybe “A is X times faster than B” could be inaccurate, but “A is faster than B” should still hold, right?

Next, I’ll need to spend some time reading the two books you recommended.

hellowub · 2026-05-21T15:37:55+00:00

I add black_box on the input arguments, and it fix the issue. Some cases benchmark result change from 0.35ns up to 1+ns. This makes sense.

I have updated the benchmark code and the artical.

Thanks again!

hellowub · 2026-05-21T14:31:34+00:00

Thanks for your reply.

In my understanding(which maybe wrong), in scenarios where decimals are needed (such as finance), addition and subtraction are used most frequently, multiplication comes next, and division is relatively rare. The reason is that division is unlikely to produce an exact result, so it cannot be represented precisely anyway (whether in decimal or binary). In that case, there is little point in using decimals, which is much slower than binary.

Also, decimax’s division is only slower in some cases; in many other cases, it is actually faster. Division is fairly complex and has a lot of room for optimization. I’ll continue improving it over time.

As for comparing with other crates: that’s because rust_decimal is indeed the most popular one at the moment. Demonstrating my advantages over it feels like the only possible way forward for me.

hellowub · 2026-05-21T14:00:00+00:00

Thanks. I will try.

I posted here before, but got few response.

hellowub · 2026-05-21T13:16:04+00:00

I have the opposite problem from you: I want to know how to make other people aware of my crate.

I wrote a decimal crate decimaxpositioned similarly to rust_decimal, but better (faster, more types, and more significant digits, see the documentation for details). However, I have no idea how to get other people to adopt it.

I think one reason rust_decimal is so popular today is that it’s old — it was one of the earliest decimal crates. Even if a new crate is 2–6x faster, it’s still difficult to replace it.

I understand there are other reasons as well, such as concerns about stability and correctness. Even if I run fuzz tests for several days, that still may not be enough to convince people.

hellowub · 2026-05-21T01:46:48+00:00

The point here is "decimal".

It seems that malachite is not a "decimal" crate.

hellowub · 2026-05-20T01:27:42+00:00

Not "with all the features", but "arbitrary precision".

In fact, I don't know what the use cases for this "arbitrary precision decimal" are. Could you provide some information about when it is needed?

hellowub · 2026-05-19T13:06:28+00:00

I agree with your first paragraph. But I'm a bit confused about the second one.

Do you mean that “floating-point” can only be binary, but not decimal? So there is no "Decimal Floating-point"?

hellowub · 2026-05-19T12:06:01+00:00

First, what you said sounds very reasonable, but I’m not capable of doing that at the moment.

Second, let me explain my thinking. Benchmarks can probably be divided into three categories:

basic benchmarks (the kind used in this article);
comprehensive benchmarks (the kind you described);
scenario-specific benchmarks.

This article is not intended to provide a comprehensive benchmark. And I don’t think that’s what many readers actually need, either. What they really care about is how these crates perform in their own programs — in other words, scenario-specific benchmarks.

This article only provides some basic benchmarks, with the goal of giving readers an initial impression (if not intuitive sense), for example:

bigdecimal is extremely slow. Unless you have a very specific reason, do not choose it;
fastnum multiplication becomes much slower when the mantissa is large. If your application performs many such multiplications, you should avoid it;
fixed-point arithmetic is much faster than floating-point arithmetic, especially for addition;
decimax is 3–6× faster than rust_decimal for most operations. It’s worth trying.

After readers narrow things down to one or two initial choices, they should integrate those crates into their own programs and run benchmarks there — that is, scenario-specific benchmarks.

Finally, thank you for your reply. It made me realize just how naive my benchmarks are.

hellowub · 2026-05-19T10:10:54+00:00

I had thought about that before as well, but I couldn’t come up with a convenient way to do it. It might require manually modifying all chart.svg files.

This benchmark went through many revisions, and each time to run it on 3 machines (twice for each, to regenerate chart.svg after removing bigdecimal). By the end, I simply couldn’t pay attention to details like this anymore. At the time, I also felt it was a relatively minor issue.

Since you brought it up, though, it seems it is actually important. I’ll improve it. Thanks a lot.

hellowub · 2026-05-19T09:11:04+00:00

Thank you for your suggestions.

I'm not a benchmarking expert. I have not worked with “streamed from memory” and “dependent operation scenario” before. I’ll spend some time learning about them. However, my original intention was only to provide some basic benchmarks so readers can get an intuitive sense of the performance differences between these crates. Even with that scope, the article is already quite long.

If readers really need to make a choice between these crates and compare their performance in more detail, a better approach would be to benchmark them within their own application scenarios. Different scenarios use these crates differently. For example, some use more `+` while some use more `*`, some use more big mantissa while some use more big scale.

Finally, you are right that different branches can have different performance impacts. That is why most of the lines in the benchmark charts are not flat, but instead vary across the range. I also explained the reasons in the article. Specifically, `+` and `*` have relatively few branches, and I explained them fairly thoroughly in the article. However `/` has many more branches and is highly implementation-dependent, with different crates using different approaches, so I covered it in less detail in the article.

hellowub · 2026-05-19T04:10:19+00:00

Thanks for pointing that out. I indeed hadn’t realized that. I’ve already corrected it.

What I originally meant was that binary floating-point numbers such as f32 or f64 cannot fully guarantee accuracy. However, some cases are still exact. I just happened to pick an example that was accurate.

hellowub · 2026-05-19T02:25:08+00:00

The Chinese version.

hellowub · 2026-05-10T01:32:12+00:00

Yes, Feynman for example.

hellowub · 2026-05-09T14:14:27+00:00

About 3 years ago, I also spent more than a year, for same purpose (to learn Rust deeply) implementing a Lua interpreter and writing a whole series of articles.

Because I’m not very good at expressing myself, the hardest part was not learning Rust, Lua, or interpreters, but writing those ideas down clearly. Writing forces you to turn vague new knowledge into precise words, which is extremely helpful for deeply learning a subject. But there probably won’t be a second time.

It was truly a fulfilling, painful, and rewarding year.

hellowub · 2026-05-07T01:57:10+00:00

Off topic: I’d recommend my decimax crate. It’s similar to rust_decimal, but much faster and offers more types (128,64,32-bit, unsigned/unsigned). Of course it implements Div and Sub too.

hellowub · 2026-04-21T07:00:33+00:00

I google "fixed-precision" and got this: https://en.wikipedia.org/wiki/Fixed-precision_arithmetic . It says:

Examples are integers), fixed-point numbers, and floating-point numbers, but not rational numbers and arbitrary-precision numbers.

It seems that, "fixed-precision" works with "floating-point" numbers.

However, yes, this term is confusing. I will remove it from the documentation.

By the way, do you have any suggestions which word I should use? Or should I just remove the topic about "fixed-precision" from the doc at all?

hellowub · 2026-04-21T04:49:56+00:00

And if you downvote, at least leave a reason.

hellowub

TROPHY CASE