Is C++ Doomed?

> But here the name actually matters. They're called "panic"s, not exceptions.

But crucially that doesn't at all affect what they do, how they do it, or what it means for programmers needing to write code.

Even if you never write "panic", or never write "recover", your code still needs to be exception safe.

> When you panic, you signal a fatal error that should ideally terminate the program

The "should ideally" is the flaw in this plan. If your code could EVER be called within an HTTP handler, or from a String() function, then you NEED to write it exception safe.

This code is a time bomb:

    […]
    foo.Lock()
    something()
    foo.Unlock()
    […]

To function correctly it must be:

    […]
    func() {
      foo.Lock()
      defer foo.Unlock()
      something()
    }()
    […]

> You shouldn't care about closing files or freeing memory

But I do care about deleting tempfiles, unlocking mutexes, closing channels, etc…, because you do need to do that.

And this is the Go authors themselves showing off panics, saying "there's a bug" if the file isn't closed:

https://go.dev/blog/defer-panic-and-recover

Go authors explicitly say you should NOT count on finalizers for correct behaviour. So no, close your files.

> well-written Go does not panic

But sometimes it does. And if your code is not exception safe then you turn a safe problem into, essentially, undefined behaviour.

> and if it does, execution will end very soon.

Nope, not if panicing in an HTTP handler. If these two HUGE examples I've given you didn't exist then I would likely agree with you.

But I'm going to declare knorker's law: Every piece of code ever written will at some point be called from an HTTP handler.

> A panic in a String() method is just bad code, don't do it.

That's too much "just don't write bugs". Modern languages are supposed to be safe, no?

> in C++ you can reasonable expect an exception anywhere

Yes, just like in Go you never know in what context your code will run in the future. Which means that in both Go and C++ you need to write exception-safe code even if you never throw or catch exceptions.

> [C++ exception for] IO failures […in idiomatic C++]

Oh? The standard library doesn't do this, right? What makes you say that's idiomatic C++?

Idiomatic Java, sure, but Java is just crazy about exceptions for everything.

> [C++ exceptions for] invalid states [… in idiomatic C++]

Idiomatic Go also calls for panic for the "can't happen" case.

> other errors that should be expected in the execution of a program all throw exceptions in idiomatic C++.

What makes you say this is idiomatic C++?

I've seen Go code that does it too, but that doesn't make it idiomatic Go.

Does the C++ standard library do this? The closest thing I can think of is std::bad_alloc on OOM, but then again Go panics then too.

> But here the name actually matters.

no, what matters is the language semantics. It could call itself "bamboozle" or whatever, the only thing that is relevant is what the compiler and CPU will do when reaching that code.

> idiomatic C++.

idiomatic is I think a big anti-pattern, as it creates assumptions and religious wars where there should not be. You've got a tool, you can use it in any way that fits the situation you're in. Is using a hammer to put a screw in a wall an idiomatic way to use a hammer/screw ? most certainly not. That does not mean that when you just have a hammer and a screw available you should throw your hands up in the air and complain that the gods put you in un-idiomatic situations.

Sure, https://github.com/microsoft/windows-rs/issues/1285#issuecom...

Yes, as dead as COBOL.

Ada relied on colleges teaching it or Pascal, so then it became hard to hire. I understand the rationale behind this, but the language is surprisingly easy to learn because it's usually explicit and straightforward.

It suffered from two decades of bad press due to being forced by the DoD and then almost two decades of no press. Looking at Google ngrams, C (due to Unix) took big chunks out of it and then Java gave the death blow by becoming a major teaching language. Ada 2012 had the capability to do for Ada what C++11 did for C++, but it wasn't sold well.

I picked up Ada 2012 last year and made a tool I use everyday now for real work--it's not a bad language. It suffers from a lot of myths about it, but the tool modernization like getting a package manager makes it productive. It is "boring" in the sense that there's nothing flashy about it, and its surface verboseness which saves other code later, and lack of curly braces turns people off. The community is super small and nice, but it never learned to sell the benefits of the language.