4 ms·

> “Do the benefits you intend to add outweigh these downsides.” Or does there exist some other language that gets it close enough, plus has decades of work and

> “Do the benefits you intend to add outweigh these downsides.” Or does there exist some other language that gets it close enough, plus has decades of work and stability going for it? The fact that Apple kept this thing to such a small number of people before announcing it leads me to believe they never even considered this sort of analysis. I don’t see how that follows, and think it isn’t true. They wanted [1] a) a modern safe approachable [2] language b) with excellent interoperability with their Objective-C code, so that it could gradually replace it. c) that’s at least as time and space efficient as the Objective-C/C/C++ combo. d) that they have control over. d) alone implies they needed a new language, but even ignoring d), what were their options? The ‘approachable’ in a) (IMO) rules out languages like rust (which also didn’t exist yet), b) implies they needed reference counting and strong typing, c) rules out anything interpreted or JVM-based. [1] https://www.swift.org/about https://www.swift.org/about doesn’t mention most of these, but I don’t think that makes it untrue. [2] I think they got that only partially. Swift looks like a simple language, but is not one (anymore)

dangus 3y ago
Yeah, I don’t really know what the author expected Apple to do with the options they had. They couldn’t have used an existing language without some serious compromises. The solution didn’t exist. The only choice was to go into uncharted territory. > Swift didn't have to "earn" its place, prove that its benefits outweighed its downsides. The writing was on the wall, Apple was saying this is the future, which threw the entire community in to chaos Italicized emphasis mine…I think that saying that the community was thrown into chaos is a bit of a stretch and a dramatization. There was no rug pull, you can still make Objective-C apps if you want to.
- paulddraper 3y ago
  What would be the serious compromise with using Go?
  - randomdata 3y ago
    The serious compromise every other language had is no great way to send Objective-C messages. You can monkey around with objc_msgSend in pretty much any language, but that’s not exactly ergonomic for developers. You would struggle to convince developers that is an improvement over simply using Objective-C. Is there something about Go that improves on that problem?
- randomdata 3y ago
  The author was involved in the creation of Objective-J. It would be interesting to hear about how he saw it meeting his criteria.
- troupo 3y ago
  > There was no rug pull, you can still make Objective-C apps if you want to. This was an exaggeration, for sure, but there was uncertainty: it wasn't a given that Apple would keep spending time on Objective-C and related libraries. Apple is well known for killing things, even long-established ones.
paulddraper 3y ago
JVM based is clearly possible, as the most popular mobile OS the world uses it, and on far less capable devices. But even if you ignore that, there were plenty of choices: Go, D, Nim. The key criteria was control.
- adrianmsmith 3y ago
  But JVM, Go, D and Nim don't have > b) with excellent interoperability with their Objective-C code, so that it could gradually replace it.
- Someone 3y ago
  > JVM based is clearly possible, as the most popular mobile OS the world uses it, and on far less capable devices. The gap seems to have been closed somewhat, but RAM-wise I don’t think top of the line Android devices ever were far less capable, likely not even less capable. For example: Apple still sells the iPhone 13 with 4Gb of RAM, the iPhone 15 has 6GB, the top of the line iPhone 15 Pro Max 8GB. The Google pixel 8 has 8GB, the Pixel 8 Pro 12GB RAM, and those aren’t the devices with the highest amount of RAM you can buy. Having less RAM translates into having better standby time for the same battery size, or smaller batteries for the same standby time. I think that was and is important to Apple. > But even if you ignore that, there were plenty of choices: Go, D, Nim. I don’t see any of those qualify for the criterion “Or does there exist some other language that gets it close enough, plus has decades of work and stability going for it” Go is from 2009, D technically from 2001, but in practice from 2007, when the standard library was replaced (https://en.wikipedia.org/wiki/D_(programming_language)#History https://en.wikipedia.org/wiki/D_(programming_language)#Histo...), NIM from 2008.
  - paulddraper 3y ago
    > I don’t think top of the line Android devices ever were far less capable I emphasized the relevant part of your statement. It's the bottom of the line Android devices that fall into the "far less capable" category > decades of work and stability Swift doesn't satisfy that criterion either. That's a no true scotsman.

dangus 3y ago

Yeah, I don’t really know what the author expected Apple to do with the options they had. They couldn’t have used an existing language without some serious compromises. The solution didn’t exist. The only choice was to go into uncharted territory. > Swift didn't have to "earn" its place, prove that its benefits outweighed its downsides. The writing was on the wall, Apple was saying this is the future, which threw the entire community in to chaos Italicized emphasis mine…I think that saying that the community was thrown into chaos is a bit of a stretch and a dramatization. There was no rug pull, you can still make Objective-C apps if you want to.

paulddraper 3y ago
What would be the serious compromise with using Go?
- randomdata 3y ago
  The serious compromise every other language had is no great way to send Objective-C messages. You can monkey around with objc_msgSend in pretty much any language, but that’s not exactly ergonomic for developers. You would struggle to convince developers that is an improvement over simply using Objective-C. Is there something about Go that improves on that problem?
randomdata 3y ago
The author was involved in the creation of Objective-J. It would be interesting to hear about how he saw it meeting his criteria.
troupo 3y ago
> There was no rug pull, you can still make Objective-C apps if you want to. This was an exaggeration, for sure, but there was uncertainty: it wasn't a given that Apple would keep spending time on Objective-C and related libraries. Apple is well known for killing things, even long-established ones.

paulddraper 3y ago

JVM based is clearly possible, as the most popular mobile OS the world uses it, and on far less capable devices. But even if you ignore that, there were plenty of choices: Go, D, Nim. The key criteria was control.

adrianmsmith 3y ago
But JVM, Go, D and Nim don't have > b) with excellent interoperability with their Objective-C code, so that it could gradually replace it.
Someone 3y ago
> JVM based is clearly possible, as the most popular mobile OS the world uses it, and on far less capable devices. The gap seems to have been closed somewhat, but RAM-wise I don’t think top of the line Android devices ever were far less capable, likely not even less capable. For example: Apple still sells the iPhone 13 with 4Gb of RAM, the iPhone 15 has 6GB, the top of the line iPhone 15 Pro Max 8GB. The Google pixel 8 has 8GB, the Pixel 8 Pro 12GB RAM, and those aren’t the devices with the highest amount of RAM you can buy. Having less RAM translates into having better standby time for the same battery size, or smaller batteries for the same standby time. I think that was and is important to Apple. > But even if you ignore that, there were plenty of choices: Go, D, Nim. I don’t see any of those qualify for the criterion “Or does there exist some other language that gets it close enough, plus has decades of work and stability going for it” Go is from 2009, D technically from 2001, but in practice from 2007, when the standard library was replaced (https://en.wikipedia.org/wiki/D_(programming_language)#History https://en.wikipedia.org/wiki/D_(programming_language)#Histo...), NIM from 2008.
- paulddraper 3y ago
  > I don’t think top of the line Android devices ever were far less capable I emphasized the relevant part of your statement. It's the bottom of the line Android devices that fall into the "far less capable" category > decades of work and stability Swift doesn't satisfy that criterion either. That's a no true scotsman.