1. 13
  1.  

  2. 3

    Some of these “Make XX faster with Rust…” articles are really grasping at straws to make Rust look fast. If speed were a big issue here the code wouldn’t have been written in Python in the first place - it’s not exactly a fast language. Realistically, almost any native compiled language would’ve beaten Python.

    Calling Rust from Python through Vim is a neat idea on its own, why focus on performance if it’s not relevant?

    1. 10

      You should’ve read the article. It’s specifically mentioned that this was a performance (and async -> threaded) drop-in replacement for an existing part of the tool where the previous vimscript & python implementations failed. Furthermore it’s also said why, even today, the native & python variants are optional and this was written in scripts that, as you said, are known to be slow.

      1. 1

        100% agree. There is no longer a wow factor just because you used Rust. Unless it somehow drastically improves security or something then the fact you use rust is completely irrelevant. Otherwise, as you pointed out, you just replaced an interpreted language with a compiled one.

        1. 3

          This sounds like a “there’s already a song about love” criticism. It’s a good article that delivers what it promises.

          It shows yet another way to improve speed of Python code (and there are a few to choose from). It shows that it’s relatively easy to do it (FFI can be messy and not all languages work together well). It shows there already are Rust libraries to handle the hard parts (not everyone may be aware that the Rust ecosystem is big enough to have this). And it shows that it all works together and achieves the desired goal. Overall it’s a useful article even if it’s not groundbreaking.

          1. 1

            No one said the article wasn’t useful. And no one said it didn’t deliver what it promised. My gripe is that if you take “rust” out of the headline an article like this gets half the up votes and half the reads.

            There’s nothing here specific to rust. I’m sure common lisp has all the necessary plumbing to do the exact same thing. The only difference is less fan fare.

            I feel like a lot of the tech community is still riding that “rewrite everything in rust” wagon and I’m tired of it.

            1. 2

              My gripe is that if you take “rust” out of the headline an article like this gets half the up votes and half the reads.

              Definitely, but you’re justifying this with the wrong argument in my opinion. People will indeed click on the link because there’s Rust in it, but not because of the hype. They’ll click because they interested to see a concrete application of this with Rust (or at least that’s why I’ve clicked).

              1. 1

                People will indeed click on the link because there’s Rust in it, but not because of the hype.

                I’m afraid neither of us prove this one way or the other.

              2. 1

                So it’s a useful article that delivers what it promised, but you don’t like it talks about Rust…

                There’s nothing here specific to rust. I’m sure common lisp has all the necessary plumbing to do the exact same thing.

                There are lots of languages that can do similar things. I don’t see anyone complaining about the Python part, even though Lisp and JavaScript have necessary plumbing for writing editor plugins, too.

                Use of Rust in this article was technically justified. Someone can still write an article about doing the same with Lisp. I’d actually be interested to see how they compare.

                1. 1

                  but you don’t like it talks about Rust…

                  I’m disappointed that, again IMO, the hype around rust still revolves around the “rewrite the world in rust” trope. I have no problem with rust, and I appreciate the drive it’s given to other languages to increase safety-by-default (e.g. the current work in D).

        2. 2

          Nice achievement for sure. I wold caution against the general point though. IMO, adding a module in a second language to an open-source project is a last resort, as it will make it much harder for people to contribute. You should make very sure that there’s just no way to achieve your requirements through optimizations in the first language first, and then try to make the alternate-language bit a separate project, included through the usual package management systems.

          1. 2

            I’m curious how much speedup the author would gain by using Lua(jit), which is embedded in Neovim…