Whilst it’s gotten a lot better in the -17 and -20 iterations, the fact that there was recently a doorstop book published solely on the subject of C++ initialisation semantics is pretty telling.
I really like what Herb Sutter’s doing around cppfront; I still wouldn’t use C++ unless I absolutely had to.
To add something to this: linux has avoided internal SPIs for a long time. It’s often lauded as one of the reasons it hasn’t ossified.
However, some subsystems have a huge amount of complexity and hidden constraint in how you correctly use them. Some of that may be inherent, but more of it will be accidental.
Wrapping type-erased shims around this that attempt to capture (some of) those semantics shines a light onto the problem. The effort raises good technical questions around whether the C layer can be improved. Where maintainers have approached that with an open mind, the results are positive for both C and Rust consumers. Difficult interfaces are a source of bugs; it’s always worth asking whether that difficulty is inherent or accidental.
You’re wrong, but it’s possible the article gave you that impression. Read the mailing-list thread.
It’s particularly worth reading Ted T’so’s contribution, which (considering his rude behaviour at the recent con led to a previous round of this nonsense) seems much more positive.
What’s in your mind does not coincide with the professional experience of Greg KH. You shoyld read what he had to say on the subject.
Ivan’s Childhood; although all of Tarkovsky’s oeuvre is worth it.
That’s Alan Turing the traitor as played by Sherlock Holmes?
It is a film with a great list of cheap tropes to avoid.
I’m a mathematician too. They’re probably speaking from an intuitive grasp of utility.
“I love life on Earth… but I love capitalism more.”
And 51 feels prime. Someone sgould write a letter.
It’s “revelation,” singular. Like trivial pursuit.
I’m coming around to it.
That’s a cracking article.
My own use of jvm errors tends to follow the same kinds of patterns: I think the major fault with that model is having RuntimeException as a subclass of Exception, because it’s really intended for abandonment-style errors. (The problem is that lots of people use it instead as an exception system in order to cut down on boilerplate.)
I find it eye-opening that the author prefers callsite annotation with try (although I’m not going to argue with their experience at the time). I can see this being either “no big deal” or even “a good thing” to Rust users in particular - mutability and borrowing annotations at both callsite and definition aren’t required to make the language work afaict (your ide will instantly carp if you miss 'em out) but the increased programmer visibility is typically seen as a good thing. (Perhaps this is down to people largely reviewing PRs in a browser, I dunno.) Certainly there’s tons of good food for thought there.
Have you seen pictures of the sub? What makes you think the wiring was all hidden?
You joke, but watch this:
https://archive.org/details/take-me-to-titanic
from 29 minutes in. A last-minute adjustment before launch plugged in a thruster backwards; no protocol to check the behaviour prelaunch. They doscovered it when they got to the bottom.
I’m not sure why it’s “obviously” good to move from one mechanism to two: as a user I now have to categorise every path to work out which is appropriate.
What I said was less about adding to a function signature than it was about adding to a facade - that is, a system boundary, although the implementation may be the same depending on language. People typically use exceptions pretty badly - a function signature with a baggage-train of internal exceptions that might be thrown by implementation guts is another antipattern that gives the approach a bad rep. Errors have types too (or they should have), and the typical exception constructor has a wrapper capability for good reason.
That’s fine, and for that there are sum types. My own opinion differs - it’s a question of taste. Being able to bundle the handling of exceptional situations aside from the straight-line logic (or use RAIi-style cleanup) is notationally convenient.
Yes, you can do the same with monads; use the tools available to you.
Checked exceptions are powerful but misunderstood. Exception types are a useful part of the facade to a module - they express to a caller how it can go wrong even if used correctly.
Runtime exceptions are typically there to express contract-breaking by callers; although as an alternative return mechanism I’ve seen them used to simplify the inner workings of some frameworks.
I think they get a bad rep because there aren’t a ton of good examples of how to use them - even the java classpath had some egregious misuse initially that helped turn people off the key ideas.
Not just domain logic. The implementation logic is often weird too. Cobol systems have crash/restart behaviour and other obscure semantics that often end up being used in anger; it’s like using exceptions for control flow, but exceedingly obscure and unfortunately (from what I’ve seen of production cobol) a “common trick” in lots of real-world deployments.