Swift does not provide memory safety for concurrent code. It has comparable pitfalls to Go. (You can use Thread Sanitizer to try and diagnose these issues, but that's best-effort and runtime-only; it does not make your code totally safe.)

Concurrent memory safety is definitely a goal. Try the new ‘-warn-concurrency’ flag to see what I mean, it is comparable to rust and quite different than thread sanitizer. There’s also a new runtime sanitizer this year with swift intrinsics, not best effort like tsan was.

That said. Swift is in the tough position of trying to be a lot of things at once to users with competing needs. Applications, systems, performance, education, prototyping, etc. While there’s broad agreement concurrency safety is important, not everybody thinks it is important enough to bury your working build under a thousand errors (though that view is represented)

Ultimately swift’s philosophy is that safety is practice and not theory. Some people do turn on ‘-warn-concurrency’ and fix their errors, others would want to ignore them and find some escape hatch to squash them which doesn’t appreciably improve safety, still others might not upgrade if that was required and maybe the ecosystem as a whole becomes less safe for it. Swift feels responsible for these kinds of outcomes.

It’s a tough problem but it does lead to interesting ideas that make safety more practical and productive. Remains to be seen how much of both worlds you can have, but swift/clang/llvm have a long history of doing stuff like that better than you expect.

That is true, but the great majority of memory safety issues are not concurrent ones. In practice Swift and Go are huge improvements over C, C++, and Objective-C in terms of memory safety.

I'd also say they are in a reasonable space in the state of the art of safety in general. While they do not make concurrency safe and Rust does, in Rust you need to use unsafe to write things like doubly-linked lists and graphs (or resort to things like indexes-in-an-array), which you can do safely in Swift and Go. So there are interesting tradeoffs all around - our industry has not found a perfect solution here yet.

In my experience post-ARC almost all memory safety issues are thread-safety related.

Except ARC only works for Cocoa like classes, everything else is traditional C like memory management.

Yes, but most of the time you’re not using that in your Objective-C code.

If I had Go's build speed in Swift, I wouldn't have minded a clean break language like Swift.

It does now with actor based concurrency

What do you mean specifically about memory safety? A clean break new-syntax Objective C could have dropped the C part of ObjC, added strict nullability, dropped header files, add non ABI breaking features like enum ADTs and a bunch of other tweaks and still kept most of the same language compiler code without all the downsides of swift. Swift became a silver bullet homer car as far as languages go.

That would not have helped with use-after-free, though, which Swift does solve.

That's solved by ARC, not Swift.

It was really solved by reference counting, way back when Foundation was introduced. The ARC increment was tiny.

Tiny? It made it so you’d never have to deal with an overrelease ever again…

Yes, tiny.

Not sure what you're on about with the "overrelease" bit, but all ARC did was automate things with additional compiler support that were already automated.

And it caused additional crashes in code that shouldn't even be able to crash:

https://blog.metaobject.com/2014/06/compiler-writers-gone-wi...

For Cocoa like classes, it did not solve anything else for the rest.

My stack-allocated integers don't need it.

Yeah, but those heap allocated structs surely do.

And although there is now partial ARC support for that scenario, partial is the keyword here, as it needs to obey specific access patterns to actually work.

But why on earth would I heap-allocate structs in Objective-C? That's what I have objects for. If I am going to dumb things down to structs, the reason is that I don't want heap allocation.

Unless I have no clue whatsoever as to what I am doing.

As in, I just wrote pure C (no Objective- at all) and for some reason changed the extension of the file to .m

Anyway, not using the solution that is there is not the same as the solution not existing, it certainly doesn't qualify as "the rest".

You "mpweiher" might not do it, but I assure you plenty of enterprise programming cogs do.

They code mostly in a C like way, and only use Objective-C at the level it is required to call into Apple specific APIs.

When using C++, then their code looks like what I call C+.

The same set of people that are to blame for Objective-C conservative GC never working in practice, when mixing Frameworks compiled with different modes.

Er...no.

I mean, sure, I believe you that you've seen this. But I've looked at quite a number of iOS/macOS projects and this was never a problem. Not even close. If anything, people were extremely hesitant if not actually afraid of using C features outside of the very basic ones like control structures, arithmetic and assignment.

Doesn't change the fact ARC doesn't work with structs, and people actually allocate them on the heap, hence why on 2018 Objective-C got some support for also applying ARC to structs.

Maybe time to also review the WWDC session and the points made there?

Oh right, good point. Other types of memory safety are more relevant here then.