This is a common talking point I hear in the Objective-C community, but nobody has come up with a credible design or implementation of "incrementally evolve Objective-C and drop the C part" beyond stating that it's trivial, etc.
Swift is the bandwagon at Apple due to how Chris Latner started the project and his clout and I think it would be politically untenable to make ObjectiveSwift going against that, especially now at Apple.
Nobody else but apple would make ObjectiveSwift too, because for better or worst ObjC & Swift are languages that are for the apple platform and nothing else. If you don't need to make something for apple, and you're going to do it without major tech company sponsorship, then you have freedom and you go make things like Rust, Nim or Elm instead.
With all of Swift's problems, I would never recommend it for a server side platform, and it's adoption shows that reality.
Because of all of the above, you'll only see hypothetical proposals, no implementations.
What about all the work done to support Swift on Linux? I had thought that was mostly done by the community rather than from Apple itself, but I could be wrong
It is interesting that it works, and some folks might even create some products that use it, but it won't ever take the world by storm.
Similarly like Mono was never that much relevant, with Miguel and others ended up creating Xamarin and focusing on mobile instead.
.NET nowadays has a good story on Linux, because now it matters to Microsoft to make it relevant, and yet most UNIX shops would rather go with Java, Rust, Go,....
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.
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.
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...
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.
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".
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.
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.
Maybe time to also review the WWDC session and the points made there?
The price is, if you violate the ODR the standard says your program is not valid C++ (and thus has no defined meaning) but there is no requirement for a diagnostic (ie a compile or link error) and the build might complete.
This has sometimes been described as "False positives for the question is this a program?" and is a pretty serious penalty to pay for the benefit of improved compile time.
If we decide "Oh, but I do want to detect inconsistencies, my users would want me to warn them about that" then we can't have the parallelization because we need to rendezvous constantly to verify the definitions are consistent.
There are a bunch of tricks that people do today to get some semblance of ODR checking for not too high a cost, and to avoid some ODR pitfalls that might defeat the checks they have. C++ programmers have accepted this danger, if you don't like it then C++ isn't the language for you.
https://belkadan.com/blog/2021/08/Swift-Regret-Type-based-Ov...
Honestly you would have gotten %80-%90 of the benefits of swift by making Obj-C use a new syntax that looked like swift and continued to improve Obj-C as a language than what you would have gotten with swift. A lot of the ugly of obj-c could have been translated away with very simple 1:1 syntactic sugar macros. And you would actually have fast, responsive compile and indexing times, unlike swift.