Fast, and ‘in-typescript’ seem to be mutually exclusive. At least for something as compute intensive as a full-text search engine.

That's condescending. There is, obviously, a use case for in-core text search. E.g., mine is that it's better to waste a few CPU cycles in the browser than on the server. And Javascript runs pretty fast, and has been doing so for years now. And while a Javascript implementation won't beat a well-programmed C/Rust/Go version, the fact that it's in core helps it speed undoubtedly. So, if you ever need a web user to search some moderately sized set of texts, this might be really helpful.

As a matter of fact, I have a similar module in my applications, e.g. for typo resistant searching through help docs and hierarchical menus.

y4mi

> C/Rust/Go version

Minor nitpick: JS/V8 beats Go in most benchmarks that are relevant for search.

JS is the outlier here however, because of the insane amount of optimizations that made it perform so unreasonably well, despite being an interpreted language.

tgv

I've never seen such a benchmark. Which one is it?

y4mi

It obviously depends on how you've implemented the feature, but there are a lot of cpmparitive benchmarks if you bother to put "go vs JS Performance benchmark" into the search bar and press enter. The language itself doesn't make code performance however, so you'll have good and bad implementations in any language you go with.

I.e. specifically regex, which is highly relevant in searching through strings: https://github.com/mariomka/regex-benchmark

And the always interesting techempower Project, which leaves the implementation to participants of each round. https://www.techempower.com/benchmarks/#section=data-r21&tes...

Choose whatever category you wish there, js is faster then go in almost all categories there.

Even though I said it before, I'm going to repeat myself as I expect you to ignore my previous message: the language doesn't make any implementation fast or slow. You can have a well performing search engine in go and JS. The performance difference will most likely not be caused by the language with these two choices. And the same will apply with C/Rust. The language won't make the engine performant and creating a maximally performant search engine is hard. But a theoretically perfect implementation would likely be fastest in C/Rust, followed by the usual suspects such as Go/Java/C#/JS and finally ending with all other interpreted languages such as ruby and python