swift

> Do you have examples where Swift suffers compared to other languages solely because of ARC? Literally all of them. Every single program where the ARC system is actually widely used. Swift otherwise generates really good code, and should be meeting/beating Java most of the time, but if the ARC system is used, performance instantly takes a massive hit. This is very visible in the small synthetic benchmarks at: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... In every benchmark where it was possible to write the program so that no references are updated in the hot loop, Swift comes out really impressive, beating Java. In benchmarks where reference updates are unavoidable, performance is more in line with Python. > Also, is this something that Apple might theoretically make up for by optimizing their custom CPUs for it, witho

> I want to try swift but the fact that there is no windows support is a deal killer for me. There’s no official support, at least not yet. But it’s in the tree. > And it perplexes me how over the years there have been no serious attempts to make it happen. https://github.com/apple/swift/search?q=windows&unscoped_q=w...

The `some` keyword declares an opaque result type ([0]), which means "this function has a concrete return type, but the identity of that type is a hidden implementation detail." An opaque result type can be used like a generic type -- the compiler doesn't know the exact type, but it does know that calls to the function will always return the same type (which is important when working with protocols such as `Equatable` that have associatedtype or Self requirements). A `some`-typed variable or stored property wouldn't make any sense because it would be a variable that has a concrete but unknown type. You can't assign something to such a variable, because there's no way to know whether the value you're trying to assign matches the hidden concrete type of the variable. Perhaps the "automatic type-erasure" feature you're wanting is actually ge

For what it's worth, that Reddit post is from last summer, and Swift on Linux development progresses extremely quickly. It's become pretty mature on Ubuntu by now. It's definitely more rough on Windows and Android, but at least CI is set up and passing on both platforms (which wasn't the case a year ago): https://github.com/apple/swift/blob/master/README.md

Technically Swift uses a "modified" version of Timsort that "performs straight merges instead of adopting timsort's galloping strategy" [0]. [0] https://github.com/apple/swift/pull/19717

Perhaps Apple's contributions aren't as visible, but just off the top of my head here's two major open source contributions from them: Swift[1] and FoundationDB[2] [1] https://github.com/apple/swift [2] https://github.com/apple/foundationdb

Rust definitely has a lot to improve on. I'm a daily Rust user, and the compile times are still absolutely terrible, and I have to agree it isn't a simple language for any sane definition of simple. That said: almost all your points apply to C++. There's nothing simple about C++. it can be incredibly complex and slow (though faster than Rust, but that's not much of an achievement). The rules around what constitutes valid (non-UB) code is anything but simple. It isn't uncommon for the syntax to look arcane (IMO much more so than Rust, although obviously YMMV). The standard library is extremely shallow, making developers have to resort to third party libraries for trivial things, except there's no package manager or standard build system, so good luck with that. And yet, here we are, with C++ dominating the market. So I don't think any of t

It appears to be https://github.com/apple/swift/pull/25221, which doesn't yet have a public proposal.

I wouldn’t call them hacks, but there are things in the runtime that you can’t implement yourself in Swift. Examples (corrections welcome): - you can’t allocate memory and then turn it into an Swift object. - you can’t write Decodable in pure Swift (reflection isn’t powerful enough to do “set the field named “foo” in this structure to “bar”) - reference counts are hidden from Swift code (yes, there’s swift_retainCount to read them, but that’s documented as returning a random number (https://github.com/apple/swift/blob/master/docs/Runtime.md) because it should not be used). So, if the compiler emits more reference count logic than needed in the data structure that your library uses, there’s no way to improve on it.

Collection's startIndex and subscripting is supposed to be O(1), so I'd assume that first is also supposed to be O(1) since it's trivial to implement it by composing the first two (in fact, this is how Swift implements it by default if you don't override it: https://github.com/apple/swift/blob/e08b2194487d883896a377a0...)

Yes, it is more similar to Swift than Rust. I guess people are more familiar with Rust.. since Swift hasn't actually implemented it yet? https://github.com/apple/swift/blob/master/docs/OwnershipMan...