Para el desarrollo móvil, solo en términos de lenguaje de programación, ¿Swift no es superior a Java (Android)?

No, aunque el marketing de Apple y su base de fanáticos quisieran que creyeras eso, y sorprendentemente también lo haría Google (para que Oracle se establezca como parte de su demanda en curso).

Para su información, soy el cofundador de Codename One (Cross-Platform Mobile Native), que es efectivamente Java para iOS / Android / Windows, etc. Por lo tanto, soy parcial pero también tengo bastante experiencia en los componentes internos de VM.

Dejando de lado los aspectos del lenguaje que son más una cuestión de gustos y cambian mucho. Analicemos la tecnología subyacente.

Swift tiene dos cosas malas que funcionan para él: el legado de Objective-C y ARC. El último de los cuales se presenta como una ventaja que es una locura …

El legado de Objective-C significa que Swift utiliza invocaciones dinámicas que son inherentemente más lentas y difíciles de optimizar incluso después de llamadas repetidas. Como se compila con anticipación, a diferencia de Java, que se puede JITAR, esto es algo que no se puede solucionar. La implementación de Java para Android cambió a un compilador AOT en 5.x luego volvió a agregar un JIT en 6.x. El valor de un JIT radica en su capacidad para eliminar por completo algunas complejidades centrales del rendimiento, por ejemplo, la incorporación de métodos virtuales, que en sí misma es la base para optimizaciones de tiempo de ejecución transfronterizas realmente sorprendentes.

La decisión de ARC es difícil. El GC es a menudo el aspecto más incomprendido y difamado de Java, a menudo ridiculizado por personas que en realidad nunca escribieron un GC y que no entienden la profundidad de las compensaciones. En los puntos de referencia sintéticos, un GC puede perder debido a su inherente opacidad e inconsistencia, pero en términos técnicos de bajo nivel es muy superior al ARC.

Entonces, ¿por qué Apple eligió ARC en lugar de GC?

Su legado original del código C / Objective-C hizo que escribir un GC adecuado fuera realmente difícil. Hicieron tal intento en el pasado y funcionó mal, por lo que eligieron ARC que automatiza el proceso integrado de recuento de referencias. El conteo de referencias parece un enfoque de gastos generales más bajos y cuando creamos originalmente el Codename One GC pensamos que podría llevarnos a grandes ganancias de rendimiento, pero descubrimos que estábamos equivocados y que siempre hay un precio que pagar.

ARC paga una sobrecarga con cada asignación y desreferencia, esto no parece mucho para alguien que nunca escribió un contador de referencia a gran escala, pero cuando agrega la complejidad de llamar al código externo (que se establece en el desarrollador) y el hilo bloquea el precio Sube. Tiene la ventaja de ser simple y consistente.

GC, por otro lado, puede asignar y hacer referencia a un objeto con una sobrecarga notablemente baja. ¡Más eficientemente que la llamada malloc de C!

El precio que paga es durante un ciclo de GC en el que la aplicación podría detenerse. Si tiene muchas asignaciones y su CPU se utiliza en gran medida, esto será un problema, pero para escenarios del mundo real, esto solo falla debido a GC incorrectos o código de usuario incorrecto que asigna demasiado dentro de un hilo de representación. Tenga en cuenta que los GC funcionan de forma asíncrona y reclaman los objetos en un subproceso separado, lo que reduce aún más la sobrecarga y utiliza correctamente los múltiples núcleos de sus dispositivos (a diferencia de ARC).

Entonces, ¿por qué los dispositivos iOS se sienten más rápidos?

1. Menos abstracción: la API de iOS es MUCHO más simple y yo diría que es mejor que Google. Google resumió y componió todo a un nivel tal que hay tanta indirección que es realmente difícil optimizar casos de uso simples. Un ejemplo simple sería la pantalla de inicio (o la nueva primera pantalla XIB) que Apple muestra al inicio instantáneo “falso”. Android no hace / no puede hacer eso.
2. Mejor hardware
3. Mejores herramientas de evaluación comparativa: las herramientas de evaluación comparativa de Android son algunas de las peores piezas de cr * p que he usado en años. Las manzanas son algunas de las mejores …
4. Increíbles API de gráficos de bajo nivel (animación principal, etc.)

Si si si.

Amo a Java Es un gran lenguaje.

Pero Swift es 20 años más moderno. Tiene una sintaxis hermosa, limpia y razonablemente concisa. Tiene cosas que nunca me perdí en Java, pero estoy muy contento de poder volver a usar, particularmente tuplas y estructuras con métodos.

Tratar las colecciones como tipos de valor: cuando vi eso, mi reacción fue “esto no va a causar problemas”, pero es una gran idea.

De hecho, Swift colapsa muy inteligentemente algunas de las diferencias entre objetos y primitivas, al crear básicamente tipos anulables.

El mismo trato con la escritura inferida (sí, sé que Java tiene esto ahora, pero no tan bien implementado como en Swift). Otra idea que pensé sería un desastre para los programadores experimentados, pero funciona muy bien.

Tengo diez veces más experiencia en codificación en Java que en Swift, pero creo que aún podría escribir una aplicación en Swift en menos tiempo que necesitaría en Java, y como usa ARC, probablemente se ejecute más rápido.

Ni siquiera se moleste en preguntar sobre Swift vs Objective-C. Objective-C es un lenguaje realmente horrible; están en extremos casi opuestos en términos de diseño y usabilidad.

Está en iOS, Swift es mejor porque ambos son producidos por Apple.

Sin embargo, las diferencias técnicas entre los idiomas no son muy importantes para la mayoría del desarrollo. Otros temas como; La disponibilidad de desarrolladores que conocen el idioma y pueden usarlo bien es más importante.