HN user
This is standard but it requires more scrutiny. Contracts are intended to be a two-way agreement, not a way to manipulate you into giving up your IP rights for the sake of employment.
I'd say push back and bring up the fact that you have existing side projects. You could feasibly get an exception if Amazon is a decent company.
The Itanium ABI is basically the reference ABI for all platforms, it doesn't only apply to Itanium.
Rust's error checking overhead is not unanimously irrelevant, it's not uncommon for functions to be called in tight loops.
I won't address your other comments since they are subjective and/or dependent on circumstances.
Good point. Some responses:
Function calls themselves can force something like "x = 1" if x is observable from the callee.
In the case where "x = 1" is not observable from the catch block, then there is no effect. In cases where you would use "try!" in Rust, in the equivalent C++ cases the catch block wouldn't be able see local variables since it would be in a parent function call.
I think LTO largely eliminates this issue altogether since function bodies are visible to the optimizer in that case.
With this method, do you have to implement the From trait for every pair of errors that can be propagated up the stack?
Hmm no. Rust always issues a compare instruction after a function call to verify if it was successful or not. In a function that can fail depending on runtime conditions, the compiler is unable to elide such a check.
Also I don't think my error handling method is nonsense as it seems to work for all the code I write. If I don't handle an error at local function scope, my intent is to handle it higher up the stack.
No they aren't, you must issue a compare instruction to verify the result was successful.
Not every platform has a branch predictor, like low-cost embedded platforms, where bare metal languages like C++ are commonly used.
Error-case performance is negligible as it's much more rare (cf. Amdahl's law). If errors are common in a specific section of code, in C++ you have the option of using simple error-checking. You have no such counter-option in Rust.
Exception handling in C++ is absolutely zero-cost when no exception occurs. Look up the Itanium ABI. In Rust, even if no error occurs, the return value must still be checked.
Additionally, Move semantics were borrowed from C++, not the other way around.
I understand exactly what "?" does, I just don't want to have to type it every time I call a function that can fail. Additionally I don't want to have to distinguish between which functions fail and which don't, I'd rather assume all functions fail and make sure my code is robust enough to handle failure at any point. This is my preference.
C++ is more efficient at error handling than Rust. In the common case of no error happening, Rust must check a return code, but C++ doesn't have to because of how exceptions are implemented in the Itanium ABI "zero-cost exceptions".
In C++ with the Itanium ABI, exceptions only add overhead when thrown, not on every function call. In Rust, the result of every function call is checked.
Just to clarify, In this specific case, I think we're talking about interface, not implementation.
Your preference is fair, since interface is a subjective issue. Personally, I find it more convenient to simply assume all code can encounter a error. Given that assumption, I find it redundant to add extra syntax to fail on unhandled errors.
Yes I would. In modern C++ we use exceptions and RAII for automatic cleanup.
A language's error-handling story is a central part of the experience of using that language. Especially if that language is a systems language.
Rust's error handling still seems unnecessarily verbose to me. A specific error type is only necessary if the program can handle the error in question. Rust has acknowledged this but I still don't want every function call in my code to be prefixed with "try!" or suffixed with "?!"
Rust error handling is also inefficient: in C++, if no error happens, then no code is run, whereas in Rust, even if no error happens a return code must be checked.
I will sadly continue to happily use C++ until Rust improves its error-handling story.
I think the similarity to de Morgan's law falls out naturally as a consequence of Boolean algebra having many similar properties to real number algebra, both for the multiplication operation and addition operation. Have you studied abstract algebra? Category theory?
d^2/dx^2 sin(x) = -sin(x)
This little fact makes numerically solving second-order differential equations using a sin(x) basis really cheap, just need to pay the upfront FFT cost... (O(n log n))
Just to clarify, mass-energy equivalence implies nothing about mass-energy conversion. We've never witnessed such a conversion nor do we know if it's possible. The implication is that mass difference of an atom after energy absorption is directly proportional to the energy absorbed. Energy is still energy in that case, no conversion has taken place.