Swift 5 ya está aquí: Apple lanza su primera versión de desarrollo

Swift 5 ya está aquí: Apple lanza su primera versión de desarrollo
14 comentarios Facebook Twitter Flipboard E-mail

Swift. Lenguaje abierto de programación de propósito general creado por Apple y apuesta de presente y futuro de la compañía. Apple acaba de lanzar en la página oficial del lenguaje la primera imagen precargada para descarga oficial del lenguaje en su nueva versión 5, dentro del hilo de versiones de desarrollo, que suele renovarse habitualmente cada 2 semanas con una nueva compilación. Tenéis el enlace para descargarla al final del artículo.

Swift es un lenguaje que pasó de ser cerrado tras su lanzamiento a ser lenguaje abierto en 2015 (el 2 de diciembre) y ahora es bandera de los programas educativos de Apple para potenciar la programación en los colegios de todo el mundo. Un lenguaje de programación que, contra lo que pudiera pensarse, no sirve solo para crear apps para los sistemas operativos de Apple. Swift funciona también en Linux, en Windows (si instalamos el subsistema de Linux), es capaz de trabajar en dispositivos iOT a través de los últimos modelos de Raspberry Pi y su sistema Raspbian y su último desembarco ha sido en aplicaciones de lado servidor (o backend) donde tenemos algunos frameworks (librerías) hechas en Swift que nos permiten crear servidores que funcionen en AWS (Amazon Web Service), Heroku o IBM Cloud, entre otros.

Swift es un lenguaje que fue lanzado para sorpresa de todos el 2 de junio de 2014 y que ha ido a una versión mayor con diferentes cambios que lo han ido evolucionando cada año, desde entonces. Cada septiembre con la nueva versión mayor de iOS, llegaba una versión nueva del lenguaje. Al menos así ha sido hasta Swift 4, porque este año en septiembre la versión lanzada de Swift fue una versión menor, la 4.2. ¿El motivo?, Swift 5 representa un hito muy importante para el lenguaje y el primer paso para su prometedor futuro. Ya que Swift en esta versión conseguirá algo que todos los lenguajes que se tomen en serio deben alcanzar en algún momento de su evolución: la estabilidad binaria.

Swift 5 y la estabilidad binaria

El motivo del retraso de la versión 5 no ha sido otro que trabajar mejor en la estabilidad binaria del propio lenguaje. Pero, ¿qué es eso de una estabilidad binaria? En programación muchos de ustedes estarán habituados a oír el término API. Que si tal API, que si API para allá que si usa tal API, etc. Una API es la interfaz de programación de la aplicación o Application Programming Interface. Es el conjunto de métodos, herramientas y protocolos de comunicación que se utilizan para construir un programa. Una API puede ser abierta (podemos ver el código de la misma) o cerrada (dicho código está generado como ejecutable y no podemos verlo, solo usar aquellas partes de la misma declaradas como públicas). Uno de los componentes principales de una API es lo que conocemos como especificación: las cabeceras de los diferentes componentes del programa y sus métodos, que le dicen a un programador como tienen que llamarlos, invocarlos, crearlos, etc... básicamente el nombre, parámetros que recibe, qué devuelve... lo básico para usarlo.

Pero cuando compilamos un programa obtenemos un código binario. Convertimos las líneas de código en instrucciones en lenguaje máquina que funciona en la arquitectura para la que hayamos compilado. Esto hace que el código que hemos creado tiene que conectar a nivel binario con aquellos componentes que usa y que haya una equivalencia que permita entenderse a las diferentes partes binarias. Y esto es lo que llamamos la ABI o Interfaz Binaria de Aplicación (Application Binary Interface).

Swift, hasta la versión 5, generaba una versión binaria diferente para cada código compilado aunque sea el mismo. Eso obliga a incluir el binario de la versión del lenguaje usada en la propia app. Pero a partir de Swift 5 no será necesario.

Pues bien, Swift hasta la llegada de esta versión 5 no era capaz de crear una ABI estable, cada compilación generaba un código máquina diferente en función de la versión que usamos. Esto provoca que las llamadas y las versiones compiladas de cada componente de Swift cambien en cada versión del lenguaje y por lo tanto un código creado en la versión 4.0 solo es capaz de funcionar contra las librerías binarias del lenguaje de esa misma versión. Si intentamos que funcione contra otra versión no lo hará porque las llamadas a nivel binario no coinciden: no son estables.

Por este motivo, desde los comienzos de Swift, Apple mete la librería de la versión del lenguaje que hemos usado directamente en el programa que creamos o app, cosa que no hace con Objective-C pues todas las librerías creadas con ese lenguaje sí tienen una interfaz binaria estable y por lo tanto están pre-cargadas en el sistema operativo. Esa es la clave de la actual evolución de Swift.

Swift bajando a la capa binaria

Si ahora es necesario incluir la librería de la misma versión que usamos de Swift, a partir de la salida de la versión 5 de forma oficial (supuestamente en primavera) no hará falta nunca más. La librería de Swift vendrá incluida como componente de iOS, macOS, watchOS y tvOS. Por lo que las apps pesarán menos, serán más livianas para el sistema y todo el sistema ganará en fluidez y uso de recursos. A partir de esta versión, la interfaz binaria de la librería será siempre igual por lo que dará igual qué versión de Swift usemos ahora o en el futuro a partir de la 5 para nuestros programas: siempre funcionará porque hay una estabilidad y las llamadas conectan. El código compilado siempre encontrará las cosas en el mismo sitio cuando llame a la librería binaria que estará cargada en el sistema operativo.

El futuro de Swift más allá de Apple

Pero no acaba ahí la cosa, porque una estabilidad binaria garantiza un futuro de Swift más allá de Apple. Un futuro como el que Microsoft se comprometió hace unos años en su conferencia Build para desarrolladores: incluir Swift como un lenguaje más a poder ser usado en Visual Studio. Los de Redmond solo pusieron esa condición obvia: que el lenguaje fuera estable a nivel binario. Con ello es cargar la librería en el ecosistema de Visual Studio y dar soporte al compilador MSBuild que ya soporta estructuras de terceros como Clang, al igual que Swift, por lo que incorporar el lenguaje no sería complicado técnicamente.

Swift

Y hay más, porque Apple trabaja ahora para que Swift cumpla el protocolo LSP (Language Server Protocol), un estándar abierto creado por Microsoft para que cualquier lenguaje pueda ofrecer servicios a cualquier editor de código o entorno integrado (IDE) para usar un lenguaje. Servicios como el auto-completado de código, el marcado de color del mismo, formato e incluso acceso a ayudas y documentación además de información de dependencias entre diferentes ficheros de código. Para todo ello Microsoft tiene un protocolo que se ha convertido en estándar y Apple no solo está trabajando en soportarlo en Swift e integrarlo en Xcode, también colaborará activamente en el proyecto de código abierto de Microsoft para proponer nuevas funciones y mejoras a incorporar al estándar. Así que la incorporación de Swift en Visual Studio sería muy simple a todos los niveles de integración y compilación.

Swift hoy día es capaz de crear programas de propósito general para Linux e incluso para Android. En el futuro lo hará en Windows y con ello podrá ponerse a altura de otros lenguajes de propósito general y ser una opción viable para cualquier desarrollo en cualquier sistema. Ese es el objetivo de Apple.

A eso le unimos que Chris Lattner, uno de los responsables principales en la creación del lenguaje, que ahora trabaja en Google como Director Senior de Tensorflow (la librería de Machine Learning de Google) va a usar Swift y su compilador para dar capacidad binaria a Python y permitir que los modelos entrenados pueden ejecutarse desde una capa binaria y no interpretada como hasta ahora. Esto permitirá que Swift y Python sean interoperables uno con el otro y que cualquier código en Python pueda ser usado en Swift directamente. Y dará un extra de capacidad y rendimiento a cualquier desarrollo enfocado en aprendizaje automático. Eso ha hecho que el equipo de Google Brain se implique en el desarrollo de Swift y que Google tenga su propio fork (copia de proyecto) del lenguaje en la cuenta de Google en GitHub, como un proyecto más de código abierto en que trabajan. Apple y Google han alcanzado de hecho un acuerdo para ir incorporando los cambios que Google vaya proponiendo al lenguaje para conseguir esta funcionalidad enfocada en aprendizaje automático e integración de Python de forma oficial para el lenguaje.

Como último apunte curioso, para que se hagan una idea de la magnitud: el nuevo sistema operativo Fucshia de Google, que está llamado a ser el sustituto de Android, tiene soporte para Swift de forma oficial (dentro del estado actual de desarrollo en que se encuentra).

Ya disponible en GitHub

Ya podemos ir al proyecto en GitHub o a la página oficial de Swift y descargar esta nueva versión. Si lo hacemos para Linux es muy sencilla de instalar pues solo hay que pre-instalar el soporte de Clang con el gestor de paquetes del sistema y luego descomprimir el fichero bajado. Si es en Mac tiene un instalador y nos aparecerá el Toolchain como disponible en Xcode para poder usarlo incluso en los Playgrounds y probar los cambios de código en el mismo, que no son muchos pero tienen curiosas novedades que lo mejoran aún más.

Si os interesa el tema, solo tenéis que decirlo en los comentarios y haremos más artículos aquí en Applesfera hablando sobre el lenguaje, sus funciones, cambios, posibilidades y más. Y un último apunte: no confundan Swift, el lenguaje de propósito general, con la librería de Apple Cocoa o Cocoa Touch que sirve para crear apps que es cerrada y que solo funciona en sistemas Apple. Son dos cosas diferentes. Es como pensar que C# solo sirve para crear aplicaciones para Windows, cuando es usado en muchos otros entornos según qué librería se use, o incluso el mismísimo Java. Una cosa es un lenguaje y otra usar una librería con él.

Comentarios cerrados
Inicio