Regexp: Go's regex is even slower than Python

>regexp
>using something that requires not only parsing of a random jumbled string but using that parsed information to parse yet another string to get what you want, instead of DIRECTLY FUCKING PARSING A STRING USING STRING FUNCTIONS
regexp is fucking dumb and so are the neckbeards that use it.

stop embarrassing yourself, NEET

lolz what the fuck is wrong with C#?

Been a programmer for years, many of them professionally for actual money. Never used that cancer and never will.

>hey user, validate the input for this format, please
>o-okay

Attached: 1535596927632.png (645x729, 63K)

And you couldn't? You might want to learn programming a bit better, then.

It's pathetic that we rely on this fucking line noise bullshit for something as important as text processing.

try doing this without regex and tell me if its easier to understand and less noisy
boolean isPhoneNumber(String str) {
return str.matches("[\\d]{3}-[\\d]{3}-[\\d]{4}");
}

TypeScript is unsound, though.

Really? You can't parse a fucking phone number without that fucking random barf?

That one line takes up much more computational power and time than just doing it manually. No wonder we need quad core ultrafast CPUs with 8GB of fucking RAM to run simple goddamn programs these days.

write your implementation and benchmarks and prove him brainlet, this kind of pointless talk proves you're the retarded one here

you can't beat decades of research in regex even though his example is very trivial, but in most harder real world situation, you can't beat regex, it's like you say I have a more secure algorithm than AES, stop making fun of yourself

not everything needs to be fast retard

You only have to compile the regex once and can run it extremely efficiently millions of time, and some languages can even do the regex code generation at compile-time.

>computers don't need to be fast
Jesus fuck, kids.

You want me to waste my time proving that two sets of text parsing operations for a single use is slower than one?

You might want to learn a little more about how programming works, kid. Jesus fucking shit. Can we raise the minimum age of Jow Forums to 35 to get rid of this bullshit?

>You want me to waste my time proving that two sets of text parsing operations for a single use is slower than one?

like expected, you don't understand what you are talking about and can't prove anything because you're a retarded NEET

>he values performance over correctness and readability
>when there is absolutely no need for performance
is this how the average C boomer thinks?

Prove it. I bet for any phone number parser more complicated than fixed-number-of-digits-in-fixed-positions regex will be dramatically simpler, faster, and more robust (w/r/t handling corner cases like full unicode, optional country and area code, varying types of delimiters, etc) than any hand-written parser you waste your time writing. State machines for regular languages are one of the most well-studied and understood topics in computer science, and regex compilers can produce extremely efficient code.

In fact, I'd go so far as to say people should err on the side of "even more robust than regex" and use parser generators, which can provide much better error reporting on matching failures than basic regex (not for phone numbers, but for simple file formats and things like that, where you might be tempted to hand-code a parser). It's easier to document, maintain, and validate a formal grammar than a hand-code parser.

>You want me to waste my time proving that two sets of text parsing operations for a single use is slower than one?
Is this bait? You compile a regex once and use it for the entire duration of a program, or sometimes codegen a parser at compile-time.

don't even waste your time arguing with this retard

TypeScript is sound in strict mode.

it is more sound that Golang itself

>over second slower than PHP
Holy shit go is bad

>C# cucks right now

Attached: i648gmqsk74y.png (645x1260, 440K)

possibly just code written by someone who doesn't know c#
c#'s Regex class even allows you to compile a regex to native code for more performance

Namaste

did that person pull these numbers out of their ass? where is the code so I can reproduce this

Looking at the code they call the regex function only once and also measure that single call. Since C# is a JIT'ed language, the first call to the regex lib causes the C# runtime to compile all the regex-code from bytecode to x86 before it can be executed. This of course is slower than calling an already compiled method. The person who wrote this is just retarded and doesn't have any idea about how the individual languages work.
I mean, who benchmarks something by running the code in question exactly ONCE? What if a random interrupt happened in that moment?
You're supposed to run it a couple thousand times and use statistics (confidence intervals etc) to interpret your measurements

>C# mono & .net core are the slowest
where's the benchmark code?
i want to see how he did the test.

see here's the retarded code github.com/mariomka/regex-benchmark/blob/master/csharp/Benchmark.cs

thanks. i've seen it. it's pretty retarded.

Reading the C# implementation makes me question the entire benchmark. It's just completely moronic. Might as well test the speed of writing a line to the console.

the thread is not about C# at all even though you're right, Go is a compiled language and still much worse than Node

That is weird. Since that is bundled with the language, you'd think they would have some ridiculously optimized version.

Yeah, the other language benchmarks are similarily retarded. The results in that table are completely meaningless as the person has no understanding of how benchmarks and statistics work.

explain why, retards

Node compiles JS to x86

Y I K E S
That came out pretty salty.

Attached: 2018-developer-job-listings-for-most-popular-programming-languages1.jpg (601x550, 51K)

>explain why, retards
what is there to explain? Have you ever seen a benchmark where they do whatever they want to measure exactly one time and base their interpretation on this one measurement? That's like judging how well a GPU performs by measuring the time it took to render just one frame of, say, a video game. Or judging how fast a CPU is by measuring how long it takes to compute "1337+42". It's completely meaningless.

nothing wrong with the benchmarks, retard, Golang is just very slow because it has extremely slow FFI, but that's one of a million cons of this garbage language

there is everything wrong with these benchmarks. Come back when you have representative numbers, for example the min, max, average, median number of regex matches per second when running the code in a loop for 10 seconds or so. Until then, none of these numbers can be used to judge how well a language really performs because any number of random events (another process stealing CPU time, an interrupt, page fault, ...) might have slowed down that single stupid call to the regex library.

For what it's worth, this is a much better benchmark which does exactly what says, i.e. running the respective code in a loop for a longer time: benchmarksgame-team.pages.debian.net/benchmarksgame/performance/regexredux.html

>Not compiled (yes, 2.1 core does compile if you give it the flag)
>Running the test once
There's even a commit "remove compile option". Why. It doesn't cause an error on unsupported runtimes, your regex is simply not compiled. Why remove it? Why only test the execution once?
Doing it right would be:
>Start a stopwatch
>Create your regex object with the compile flag set
>Run the regex like 1k times
>Stop the stopwatch and return elapsed / iterations for an average time.
This should be how all the langs are tested.

If you want to see an actually good series of benchmark scores then look at:
benchmarksgame-team.pages.debian.net/benchmarksgame/

Attached: Screenshot_20180928-110603__01.jpg (1584x860, 221K)

and it's the same result, Go is one of the worst performing languages at regex

Tried it using compiled regex. Only becomes 500 ms faster in each iteration. Use 100 loops.

modified code with compiled regex
static void Measure(string data, string pattern)
{
Regex regex = new Regex(pattern, RegexOptions.Compiled);
for (var i = 0; i < 100; i++)
{
Stopwatch stopwatch = Stopwatch.StartNew();

//MatchCollection matches = Regex.Matches(data, pattern);
MatchCollection matches = regex.Matches(data);
int count = matches.Count;

stopwatch.Stop();
Console.WriteLine(stopwatch.Elapsed.TotalMilliseconds.ToString("G", System.Globalization.CultureInfo.InvariantCulture) + " - " + count);
}
}

Are there any 3rd party regex lib for C#? M$ regex is too slow.

Is this a joke?
Anyone who can't write such a function in a couple of minutes have no business calling themselves a programmer.

But if you want to validate a textual input you almost certainly want to parse it at the same time. Using regexp in this case (or any other automaton) is just wasted effort.

list your couple-of-minutes implementation in Go or STFU

>"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." – Rob Pike, co-creator of Go
I'm kinda surprised the language even has regexes.

I did a similar thing except I made the stopwatch outside the loop and divided by the iterations.

Dotnet core 2.1
i7 4790 @ 3.6 GHz
Compile flag set
>Email: 1186.284ms
>URI: 956.369ms
>IP: 74.713ms

Compile flag not set
>Email: 1692.172ms
>URI: 1474.255ms
>IP: 95.408ms

That's... a lot better when compiled. Still, using C# for heavy regex work seems to be a bad idea right now. I hope some real optimization effort goes into it in the future.

PCRE is faster until you hit the pathological case where it's millions of times slower.

swtch.com/~rsc/regexp/regexp1.html

wait wasn't go supposed to be a fast "systems" language? I thought the reason it had like no language features was so it could be fast like close to C performance? but it's actually fucking slower than java, lisp, C#/F#, etc? holy shit how can gotards even defend this shit? the only way you can consider go fast is if you're switching from python or ruby lMFAO the absolute fucking state

This! While I don't prefer Go, I think it is an ok language with some quirks. That said, I think Go's Regex implementation is laughable bad. I'm surprised no one else had mentioned I'm this thread, but not only is Go's Regex implementation slow, it is also limited. Go can't do more advanced Regex patterns like look ahead or look behind. I don't know while Go did such a shitty job at implementing Regex.

>The only way you can consider go fast is if you're switching from python or ruby
And now you understand the target demographic for golang. It's for idiots who can't be trusted with a real language. It's the nerf of system languages. The designers have outright said so.

That said, it's generally fast enough. It is a really serious improvement over interpreted languages if that's where you're coming from. Working in it is just kinda a pain in the ass because lot's of things are missing. So if you're competent in any way, then you're better off choosing between Rust/Java/C# depending on use case. Most other languages are becoming redundant in comparison to these. I mean, there's js too, but you should only use it when absolutely forced i.e. webshit frontend.

Well, if Rob Pike was being serious (), I think that Go lacks features not so much in order to be fast as to be able to crank useable production out of novice programmers.

Continued... although that said, I'm pretty surprised that he thinks novice Google employees can't understand brilliant languages. Isn't Google supposedly hiring the cream of the crop?

time find ~ -type f -regex '.*[0-9][0-9][0-9][0-9][0-9][0-9]s\.jpg'
vs.
time find ~ -type f -name '*.jpg' | grep "[0-9]\{6,\}s\.jpg"

>he can't read regex
color me unimpressed

Google only hires crazy trans men and black women who can either do autistic puzzles or argue loudly about how oppressed they are.
This is pretty obvious if you compare Google products ten years ago to today. The difference is absolutely staggering.

>php growing

Attached: wyii.jpg (666x570, 64K)

This.

Wow didn't expect that.
I have both my dogs in this fight. PHP is my main source of income but I use Golang as a scripting language for its comfy concurrency, e.g. whenever I need to do large data migrations from one pajeet software to another.

not really lol google engineers are almost exclusively white/asian males from ivy league schools with 4.0 gpa engineering/cs degrees and often a phd. 99% of their revenue is from their ads business and the rest of the company is pretty much a poorly run incubator consisting of many different teams of engineers without much direction

> article written by rsc, golang's tech lead
kek

I really appreciate the little detail that the Amtrak logo is already inside the trash can. It makes the joke work on a whole new level. Well memed, amemego.

idk if I'm taking the bait rn but that's the haskell logo

this is Haskell's logo

Quite observant of you to notice this. The joke was about the superficial similarity between the Haskell logo and the old Amtrak logo. You're both incredibly sharp. Not many people would have realized that a Jow Forums meme image about Go would more likely compare it to Haskell than to Amtrak. Pat yourselves on the back!

I'm slightly disturbed JS and PHP are so far up there.

JS is extremely, I mean extremely fast thanks to V8 and libuv, V8 made this once a shit language amazingly beat many compiled languages

It depends on what you're doing. Step outside the expected use case (webshit) and suddenly you're interpreted-tier again.

This is the dumbest thing I have read all week

>i was only pretending

Surprised how Perl isn't higher. Always thought that was somewhat the benchmark of regex.

They're both languages specifically made for the web only, so it kinda makes sense to me.

no, JS on Node is far more better than any interpreted language when it comes to performance, the reason is that Google put a lot of money for implementing state of the art JIT to V8 since Javascript is very important since it runs the web