regex-benchmark VS v

Before we start comparing the aforementioned solutions, it is worth to show how bad things are with the standard regex library in Go. I found the project where the author compares the performance of standard regex engines of various languages. The point of this benchmark is to repeatedly run 3 regular expressions over a predefined text. Go came in 3rd place in this benchmark! From the end....

* Let you clone a map without rehashing every key to a new seed. I generally measure at least 15x speedup from this alone, unlocking very useful design patterns like "clone a map and apply a few temporary updates for a one-off operation like validation or simulation" with no extra code complexity. Go gives you no better option than slowly rehashing the entire map.

And that's just hash maps. How about Go's regex engine being one of the slowest in the world while Rust's regex crate being one of the fastest:

https://github.com/mariomka/regex-benchmark#optimized

Languages Regex Benchmark

Java is still pretty bad compared to C# (not to mention Rust or Nim)

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 in 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 creating a maximally performant search engine is hard

Also, regex engines are not created equally, at all. One of the best writeups I've ever read is from the ripgrep blog. Burntsushi knows regex. There's also this benchmark site which illustrates how general language performance is an entirely different metric than regex performance. Don't assume those benchmarks will cover your particular use case, though--different regex engines might handle your particular situation differently.

Interesting. Looking at this repo, they have

Rust -> Ruby -> Java -> Golang

https://github.com/mariomka/regex-benchmark

Though it appears the numbers are two years old or so, and only for 3 specific regexes.

id also be careful in claiming C++ std regex is faster than python, unless you actually have proof. there's a ton of information that in many cases its actually slower. https://github.com/mariomka/regex-benchmark. have you actually benchmarked your code? or was it just a naive assumption that because its C++ its just fast?

It is a matter of personal preference.

I find that regular expressions and text-wrangling tasks are faster and easier in Perl than in other programming languages due to its accessible syntax and regular expression engine speed.

This article shows the regular expression syntax in several popular programming languages: https://cs.lmu.edu/~ray/notes/regex/

This GitHub repo gives some regex performance test benchmarks: https://github.com/mariomka/regex-benchmark Perl is pretty fast among the scripting languages that were benchmarked.

If you are familiar with C / C++, then learning Perl is relatively fast and easy: https://perldoc.perl.org/perlintro

Their site is clearly showing the language is in beta. The V documentation also states that autofree is WIP, and to use the GC instead. This isn't a corporate created language, but looks to be a true volunteer open source effort from people around the world.

Their community, in comparison to others, even has their discussions open and open threads for criticism[1]. These

[1]https://github.com/vlang/v/discussions/7610

V also has this https://github.com/vlang/v/blob/master/doc/docs.md#embed_fil...

Goroutines was the selling point for me until they decided to introduce telemetry in their toolchain; that was what forced me to stop using Golang as a whole.

About GC, I would say: if you implement C++'s RAII mechanism to replace garbage collection, then I believe this project will have a bright future.

My final question is the following: how `pcz` compares to V language, from a syntax's perspective [1]?

[1] https://github.com/vlang/v

V has the right to exist, have its supporters, and do things its own way. The creator and developers of V, from what I have seen, has always responded well to constructive criticism. Their language has discussions opened at their GitHub, unlike those for various other languages. They even have a thread for what people don't like and want improved about the language[1], again, something many other languages don't have.

A lot of what was going on initially, was coming from obvious competitors, to include being uncivil, inflammatory, and insulting. The initial "criticism" was not so much that, but false accusations of the language being a scam, vaporware, fraud, or didn't really exist. To include attacks and jealousy about its funding and having supporters. This was not any kind of "valid" criticism, that the creator or contributors of the language could reason about.

The "criticism" never died down, but rather after V was open-sourced and established itself on GitHub. The initial series of false accusations could not stand nor could the support it was getting be stopped. So, the rhetoric and targets shifted to whatever could be found to go after on the newly released alpha version of the language and its new website. In that new mix of what was being thrown at it, there were indeed some very valid criticisms, as can be found with any new language.

Constructive and valid criticism, is not the same as insults, trolling, misinformation, rivalry, or false accusations. There is clearly a difference. It's disingenuous to pretend something from one group is the same as the other, or that the intent behind what is being done is not different.

[1] https://github.com/vlang/v/discussions/7610