> I don't think this is true either - a large part of the Rust community seem to think that it's as complicated as it needs to be. As a beginner/outsider, I found it kind of cumbersome to get started with, but that's certainly not everyone's opinion.
Personally I feel it's not complicated enough. Where is my function overloading, variadic templates and usable compile time reflection? (Sure you can sometimes use macros but ew macros)
If you care very much about not ever ending up in a bad state (which it seems that you do). Then just functional programming with immutable state is not going to cut it. In this realm you should look into methods of formal verification to prove that your code does what you want it to do.
That being said, functional verification is a huge time sink and is really only economical if it's very important for the code to always be correct. That is, people die if your software has a bug. A few examples would be pacemakers, aircraft autopilots or your car brakes.
If your not working one of these domains then maybe immutable and pure functional code can save you a few bugs? I have not read any peer reviewed study that shows this is the case. But if you have any such paper i would be happy to read it.
Immagine a world where every framework / API / database had its own incompatible UUID format. Without a standard specification that's where we would end up. Do you want to live in such a world?
Well I mean in many countries, blocking the surveillance agency from listening in on your calls/texts/chats is illegal. So making an app that interferes with the agencies ability to "listen in" is infact a criminal enterprise.
I dunno, upper management normally move onto greener pastures long before reality comes crashing down. That does not happen until two managers over. But that's okay the new plan will fix everything.
I have heard this before but never really understood it.
Take this:
```
int bar(int arg); // May throw
int foo(int arg) {
int b = bar(arg);
return b * 5;
}
```
VS:
```
Error<int> bar(int arg); // Uses error type
Error<int> foo(int arg) {
auto b = bar(arg);
if(b.ok()) { // Happy Path
return b.unwrap() * 5;
}
return e; // Exceptional Path
}
```
In the happy case (no exception) how can the first version be harder to optimize than the second one? In the exceptional case exceptions will probably be slower. You trade fast common case for slow exceptional case so it makes sense to me. Is the slower one the one that is hard to optimize? Is this what we are talking about when optimizations are harder to reason about? Or are there some other things that become harder because of exception? Things like RAII, defer, goto stuff?
Personally I feel it's not complicated enough. Where is my function overloading, variadic templates and usable compile time reflection? (Sure you can sometimes use macros but ew macros)