[dgfgfdagasdfgfa]

Could someone explain why I should build a language developed entirely by and for writing Apple ecosystem products? It seems like if I'm not targeting MacOS or iOS directly, the long list of benefits suddenly looks much, much smaller compared to e.g. JVM, .NET, Go, etc etc.

"letʼs start hacking, letʼs start building something, letʼs see where it goes pulling on the string" feels scarily accurate, and it's unclear where the language will be in 5 years.

Among other things, there's no way to disable objective-c interop, even though it complicates the language and feels like someone merged smalltalk, C++, and ML—not a pretty combination. But—literally the only reason you'd enable that would be to work with Cocoa/UIKit.

I'm still out on ARC—it was much less of a problem than I expected on my last project, but it never feels like an optimal solution, and you can never just "forget about it for the first draft" the way you can a VM's GC.

[LeoNatan25]

> a language developed entirely by and for writing Apple ecosystem products

So, apparently you didn't even read the article, as it is explicitly stated that this was not the intention or direction of Swift.

> Among other things, there's no way to disable objective-c interop, even though it complicates the language and feels like someone merged smalltalk, C++, and ML—not a pretty combination. But—literally the only reason you'd enable that would be to work with Cocoa/UIKit.

Swift on Linux does not use any of the ObjC runtime features that are used on Apple platforms.

[wulfklaue]

> So, apparently you didn't even read the article, as it is explicitly stated that this was not the intention or direction of Swift.

It might actually help that there is a real commitment in that direction. The issue being that it was IBM that mostly pushed for changes in foundation and without there initial blue socket support, even the most basic tasks did not even succeed.

Let alone the none existing windows support. It may not have been Chris his intention but one now ex-employee intention does not mean a lot when the company determines the direction after his release.

[LeoNatan25]

While I agree that the state of the Foundation frameworks should be better, I would not go as far as saying Apple is disinterested. Just lower priority. Also, seeing how Swift has evolved, the community has a very large impact on the direct Swift is taking.

[drewcrawford]

> there's no way to disable objective-c interop

Believe it or not, this compiler option is named `-disable-objc-interop`.

> Could someone explain why I should build a language developed entirely by and for writing Apple ecosystem products?

Possibly because you have an affinity for value types, performance, or safety. A language is a lot more than just a checkbox of platforms it supports, although iOS is a pretty large checkbox right now.

> the long list of benefits suddenly looks much, much smaller compared to e.g. JVM, .NET, Go, etc etc.

Swift isn't trying to compete with any of those. I mean sure in the "world domination 10 year plan" sense, but for the forseeable future the bullets that make Java attractive to enterprises (lots of developers, lots of libraries, lots of platforms) are not on anyone's todo list in the Swift community.

Rather, the short-term goal is to compete with C/C++/Rust. So you are writing a web server (e.g. nginx alternative, not a webapp) or a TLS stack or an h264 decoder and buffer overflows on the internet sounds scary, you are doing pro audio plugins where 10ms playback buffer is the difference between "works" and "the audio pops", you need to write an array out to network in a single pass to place your buy order before the trader across the street from you, but still have a reasonably productive way to iterate your trading algorithm because Trump is elected, etc.

As far as JVM/.NET, a cardinal rule of software is that it bloats over time. So JVM/.NET/Go can never "scale down" to the kinds of things C/C++ developers do, but it is less known whether a low-level language can "bloat up" to do what .NET developers do. In fact, C++ kinda does "bloat up", because C++ .NET exists. But that is basically an accident, because C++ was not designed in the 80s with .NET developers in mind, and perhaps for that reason it is not the most popular .NET. To the extent we have a plan, the plan with Swift is to try that "on purpose this time" and see if it works better when we're designing it to do that rather than grabbing a round peg off the shelf and hammering it into our square hole. It probably won't ever be as good at .NET problems as .NET, but perhaps it can get close, for useful values of close.

> you can never just "forget about it for the first draft" the way you can a VM's GC.

Similarly, ARC does not exist to compete with your VM on ease-of-use, it competes with malloc/free on ease of use (and your VM on performance). If your VM is performant enough (or you can afford the hardware to make it so), great, but that just isn't the case for many programming domains, and that's the issue we're addressing.

There is also a quasi-non-performance aspect to ARC that is often overlooked: deterministic deallocation. Most VM memory models are unbounded in that resources never have to be deallocated, but in a system like ARC we have fairly tight guarantees on when deallocation will take place. So if your objects have handles to finite resources in some way (think like open file handles, sockets, something to clean up when they blow away) the natural Swift solution will be much more conservative with the resource use relative to the natural JVM solution. Because of that it may be more useful to think of ARC as a general-purpose resource minimization scheme (where memory is merely one kind of resource) rather than as a memory model or GC alternative itself.

[pjmlp]

> There is also a quasi-non-performance aspect to ARC that is often overlooked: deterministic deallocation.

Assuming there are no pauses due to deletion of deeply nested data structures, or worse, stack overflows.

Herb Sutter has a very interesting presentation at CppCon 2016 about these issues, where he then presents a kind of C++ library based GC to work around them.

Also ARC has performance impact, because increment/decrements need to be synchronized due to threaded code.