Grep 3.7 Released To Fix "Extreme Performance Degradation"

[arQon]

Uh, exception handling is only "free" as long as you never catch the exception (ergo throwing is free). If you do catch the exception its actually incredibly expensive, which is why it should only be used for exceptional situations.

Dude, I used "overhead" for a reason! You're right that "free" would be an acceptable synonym in this case in standard spec use, in that the capability cost is basically non-existent these days (vs 15+ years ago, when making EH *available* to the code had its own independent and significant overhead just by existing) but you're going to give the non-developers a headache like that.

Even when EH *is* actively used though, it simply just *isn't* "incredibly expensive" any more. That's not even actually all that important, but it's worth correcting. You're still talking about the distant past. But for now, let's just agree that it's non-zero and leave it at that.

But to your main point: well, yeah. I don't think anybody's suggesting that we should start writing code like "if (a != b) throw compare_failed()" for integer types.
But I think you're misunderstanding the term "exceptional", based on - again - guidance from 20 years ago.

> Otherwise you should treat your error case as normal values and pass them along (and thats what Rust's Result/Option is for).

You're conflating two very different things here - and neither of them is even the point!
It's late, and I'm tired, and if you're seriously trying to understand then this deserves a much more detailed reply than I can give it tonight. I'll try to come back to it, but if I forget over the weekend feel free to PM me a reminder.

[mdedetrich]

Exception handling in C++ also began life as "for exceptional conditions only", but there are patterns that *require* EH to be viable, and since those patterns are critical to avoiding resource leaks, enforcing known state in objects, and so on, EH evolved to become part of the natural workflow of the language. (And as a result, the overhead of EH went from about 20% to ~0%, which in turn encouraged adoption of the safety patterns, so that's nice. )

Uh, exception handling is only "free" as long as you never catch the exception (ergo throwing is free). If you do catch the exception its actually incredibly expensive, which is why it should only be used for exceptional situations.

Otherwise you should treat your error case as normal values and pass them along (and thats what Rust's Result/Option is for). The same goes for Java/Scala and other languages that have exceptions.

[flashmozzg]

When Rust/Java developers try to tell me their language is so much better, in my mind, I'm picturing a kindergartener riding up to a first grader and saying, "My tricycle is SO much better than your bicycle! It's got THREE wheels instead of only TWO, and look, it can't fall over!"

C/C++ is like a Penny Farthing (old and easy and unsafe), Rust is like a regular bike and Java is a tricycle.

[arQon]

No, it's not as stupid at you make it sound. If you get a Result, or Option that's because the value might be missing. This requires handling one way, or another. If you don't, it's a segfault because you didn't check for NULL.

That doesn't mean you have to do verbose error checking like Go. There's the ? operator that extracts the value, or returns from the function, passing on that error value down the stack.

Thanks. But in that case, you're right: it's not as stupid as I "make it sound": it's even worse. I'm sorry, did I ASK you to bail from the function? No? Then why are you doing that instead of letting me handle the problem locally? ugh...

Exception handling in C++ also began life as "for exceptional conditions only", but there are patterns that *require* EH to be viable, and since those patterns are critical to avoiding resource leaks, enforcing known state in objects, and so on, EH evolved to become part of the natural workflow of the language. (And as a result, the overhead of EH went from about 20% to ~0%, which in turn encouraged adoption of the safety patterns, so that's nice. )

What you're describing is basically "error handling capabilities on par with K&R C". We moved on from that literally last century!

It's not that you "can't" write code that way, but having gone through this transition in the other direction, it's hard to imagine why anyone would WANT to have to only have shitty error handling that requires adding boilerplate to basically every function call. The fact that you don't have the option of just not bothering is "good" as far as ensuring that returns are checked etc, but it doesn't in any way reduce the amount of work you have to do (which is a pain in the ass if you're just throwing together a POC), and it doesn't lend itself to being able to handle errors without poisoning the code with an unreadable / maintainable mess.

TLDR: Rust is clearly still very immature in this area, and will need to improve substantially for it to be able to graduate from the "only really suited to toy programs" stage.

[lyamc]

In C/C++ something is correct when someone can use it correctly, but in Rust something is correct when someone can't use it incorrectly.

Uh... what? Why would you say the same thing twice but act like its different?

What you said: (A == True when C == True) =/= (B == True when C =/= False), therefore, A =/= B

But

B == True when C =/= False -->B == True when C == True

That means that you actually said: (A == True when C == True) =/= (B == True when C == True)

Therefore, A == B

[ed31337]

When Rust/Java developers try to tell me their language is so much better, in my mind, I'm picturing a kindergartener riding up to a first grader and saying, "My tricycle is SO much better than your bicycle! It's got THREE wheels instead of only TWO, and look, it can't fall over!"

[mdedetrich]

The problem with Rust is that even though it enforces checks, it does so in a bizarre way and the syntax is hell (as I mentioned before).

Syntax is subjective and there is nothing bizzare about how Rust is doing it, its just functional programming. i.e. Rust's Option is just a type checked null, so you are forced to either handle the empty (i.e. null) case or when there is a value there and as mentioned previously there is syntax sugar for this as well.

There is a difference between bizzare and unfamiliarity (which I suspect is what you are dealing with).

[tildearrow]

If you have trouble learning the concepts behind Rust then you shouldn't program in C because at that point you don't know how to write correct C code (or to more accurate, have some real assurance that the majority of your code are correct). Rust is basically a newer C with a compiler that checks you are writing memory safe code.

Too bad I already did. C is easy to learn, but hard to master. I can't miss a single check or the whole thing collapses in unexpected ways.

The problem with Rust is that even though it enforces checks, it does so in a bizarre way and the syntax is hell (as I mentioned before).

[mdedetrich]

And way worse than Java.
At least in Java/C++ there is try catch, which allows you to catch errors with little effort. Java even has the benefit of not requiring manual memory management, but then talk about verbosity and high memory usage with garbage collector....
But Rust? It's a mess of match Ok/Err, asterisks, ampersands, muts... I remember trying Rust out once, and it made my head explode.
It feels as if JavaScript programmers (JavaScript being the worst thing ever already) teamed up with C ones and attempted to create a new language.
Rust's popularity comes 95% from its fan base who praise the language like a deity and want everything rewritten in Rust...

On the corner, Haxe

If you have trouble learning the concepts behind Rust then you shouldn't program in C because at that point you don't know how to write correct C code (or to more accurate, have some real assurance that the majority of your code are correct). Rust is basically a newer C with a compiler that checks you are writing memory safe code.

Rust is like a really ugly native language with only one quite bad compiler supported and a npm clone if the rest was not already insane enough.
npm in native development, thats what we need, for sure.

Cargo is nothing like npm but nice try. The only thing they have in common is that they are package managers.

[Kemosabe]

Oh well. I am not sure if human civilization is able to handle the free exchange of information and the decline of journalism as a profession. Anti-vaccers, Q-Anon, Flat-earthers, Rust, ...