Not at all.

There is a world between every single string, array and numeric operation being a possible source of memory corruption and being forced to explicitly write unsafe code.

I have been using mostly safe languages since the 80's.

They only get in the way of cowboy programming, which is a very good thing for anyone that praises quality in software development.

C would no longer be around if companies got properly sued for each CVE exploit.

People have written and continue to write secure C code, and insecure code in “safe” languages.

I have written systems in memory safe languages. The languages that provide memory safety also incur GC pauses, which means they’re unsuitable for applications where latency matters at all. (I’ve also noticed that programs written by professionals in memory safe languages tend to have many more serious high-level bugs than those written in C/C++, but I don’t have data to back that up.)

> The languages that provide memory safety also incur GC pauses

This is incorrect, you can have memory safety without a gc. An example is Ada, and more recently Rust.

And Swift, which uses automatic reference counting instead of GC. This is not a “zero-overhead” design like what Rust aims for; sometimes it has quite a lot of overhead. But it is free from the phenomenon of GC pauses.

> But it is free from the phenomenon of GC pauses.

Not really. RC algorithms can lead to stop the world in cascade deletion of highly nested data structures, and even cause stack overflow due to destructors being called.

Well, in that regard, so is Python; the GC is only used to resolve cycles, and can be disabled.

IIRC memory safe Ada doesn't allow for deallocation.

Kinda sorta cheating. ;)

It does via memory pools, RAII (aka controlled types) and dynamic stack allocation.

It isn't truly safe like Rust, as Ada can still have dangling pointers laying around, the free function is called "Unchecked_Deallocation", not sure if newer Ada has any mechanisms for better ownership semantics.

> People have written and continue to write secure C code, and insecure code in “safe” languages.

No. It's the inverse. People who are very good with C continue to have vulnerabilities in their code. Why? Because C.

Yeah, but I do have data to back up the fallacy of the perfect C programmer that writes secure C code.

https://www.cvedetails.com/vulnerability-list/opmemc-1/memor...

Apparently reviewing code before merging into mainline isn't of much help, but lets keep this myth of secure C code alive.

Σ (Logic errors in safe language) < Σ(Logic errors in C + Memory Corruption in C)

The critical difference is that in swift your have to override safe behavior by using special syntax. This means you can search for it to fix it, you can have compiler/linters enforce certain rules, you can catch it easily in code reviews. No professional team I've worked on would allow forced unwrapped code except in special well documented cases.

The default code you write in swift is safe. You spend less time worrying about its correctness, which means you can focus on solving higher level problem and less time debugging.

When people call swift pedantic, for example, and I take time to ask for the specifics, I mostly get "not familiar to me", or "I'm used to shooting myself in the foot and unwilling to consider alternatives". So my patience has run out.

If only there was a way to catch array index out of bounds.

  extension Collection {
    subscript (safe index: Index) -> Element? {
      return indices.contains(index) ? self[index] : nil
    }
  }

And now you have the choice:

  array[i] // traps for invalid indices
  array[safe: i] // returns nil for invalid indices

I always have a choice if I'm the one writing the code.

But what I want is a way to catch all errors that others may have introduced in code I have no control over. That includes arithmetic overflow as well.

What would you do? If the ordinary array subscript produced an optional value, people would simply fall into the habit of force-unwrapping it, since the hassle of handling the spreading optionals would be too big. And throwing an unchecked exception would lead to empty catch blocks everywhere, just as in Java. And then the execution would continue in God only knows what state. I simply don’t think that the type system can solve the question of trusting your dependencies for you.

What I want to do is to wrap a piece of code running in its own thread in a catch block so I can respond gracefully to any errors without killing the entire process.

What gracefully means depends entirely on the application. Often it means to log the error or display a meaningful error message if it's an interactive app, then maybe do other kinds of cleanup and shut the thread down.

It can also mean to retry later. Array out of bounds errors are quite often just a result of not properly handling an earlier temporary error.

Whether or not errors leave the rest of the application in an inconsistent state depends entirely on the design of the application.

I'm not saying that letting an app crash on buggy code is never the right thing to do. I just want the option to handle it differently where appropriate and possible (it's not always possible anyway).

You might be interested in this:

https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9...

Speaking of reliable systems, introducing an actor model is a good opportunity and excuse to introduce a mechanism for handling and partially recovering from runtime failures (like failed force-unwrap operations, out-of-bounds array accesses, etc). We explore several options that are possible to implement and make a recommendation that we think will be a good for UI and server applications.

This looks like a more principled approach that we will eventually get in Swift.

Sounds pretty vague, but at least he acknowledges the issue.

There’s plenty of details:

https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9...

https://github.com/apple/swift/blob/master/docs/ErrorHandlin...

So essentially they plan to terminate the actor instead of the whole process. I think that would be a very good thing.

Lol, I put that code in my last project, a 150,000 line codebase built by lazy contractors, as just one of the tools to clean up the errors from their objective c like approach to software quality.

Interestingly put, "the Objective-C approach to software quality". There's something in the psychology of a large number of C, Objective-C and C++ programmers that makes them overappreciate execution speed and underappreciate memory safety in particular, but also validation and correctness in general.

One of my goals now is to outline safe ways of using C++ for various projects and I'm not too optimistic. In fact I'm unsure what we'll end up with.

Quite true, hence why I say that the problem is human and not technical.

Those of us that come from Wirth languages always put quality and delivering what the program is expected to do before going crazy with optimizations.

I always got the feel that many in the C communities write code as if they were micro-optimizing every single line, just because.

And those that care about type safe driven programming in C++ usually have background in safer languages.

I don't think Swift has a way to catch all runtime errors that others may have introduced in a reliable way.

Perhaps because it's not a huge problem in iOS apps, but for long running multi-threaded applications this is a problem.

I don’t know Swift, so I don’t know what you’re implying, but I only know of three ways to deal with an array out of bounds runtime issue....

1. Don’t check for it at runtime and the runtime writes to memory that it shouldn’t like C.

2. Throw an exception and prevent memory corruption.

3. Don’t ever work with indexes and just use iterators.

Is there a fourth way that it can be handled in other languages?

You could have the subscripting method check at runtime and return an Optional.

This isn’t what Swift means when it says it’s safe. “Safe” doesn’t mean your program doesn’t have bugs or can’t crasg; rather, it will never have to deal with things like memory corruption and related undefined behavior. In fact, Swift considers crashing rather than allowing such errors to propagate to be an explicit design goal.

Right; this is why integer operations trap on overflow by default, instead of silently wrapping, for example. Technically you’ll “crash” more but the crash occurs at the exact location of the problem and not much later in the form of corrupted data.

It’s the difference between a crash pointing exactly at the cause, and spending days or weeks isolating crashes that only occur minutes after the error that caused them, or only on certain devices, or in certain memory configurations, or only on every other Sunday, etc.

There is a world of difference between letting bugs easily happen a letting the programmer override error handling.

Up till Swift 2 that was mostly the case – getting "in the way" – but as it is now I'd say Swift forces you to think about being a better developer, while still letting you be a bad one if you really insist on it.

After working exclusively in it for a while now I can't help but cringe at the practices which I see encouraged in most other languages.