Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Cómo empezar a programar tiempos de ejecución en AL2023
AL2023 proporciona diferentes versiones de los tiempos de ejecución de algunos idiomas. Trabajamos con proyectos originales que admiten varias versiones al mismo tiempo. Obtenga información sobre cómo instalar y administrar estos paquetes con versiones nominales mediante el comando `dnf` para buscar e instalar estos paquetes.
En los siguientes temas se describe cómo existe cada ecosistema lingüístico. AL2023
**Topics**
+ [C, C\$1\$1 y Fortran en AL2023](c-cplusplus.md)
+ [.NETen AL2023](dotnet.md)
+ [Goen AL2023](go.md)
+ [Java en AL2023](java.md)
+ [Node.jsen AL2 023](nodejs.md)
+ [Perl en AL2023](perl.md)
+ [PHPen AL2 023](php.md)
+ [Pythonen AL2023](python.md)
+ [Rubyen AL2023](ruby.md)
+ [Rusten AL2023](rust.md)
+ [Swiften AL2023](swift.md)
+ [TypeScript en AL2023](typescript.md)
# C, C\$1\$1 y Fortran en AL2023
AL2023 incluye tanto la colección de compiladores de GNU (GCC) como la interfaz Clang de LLVM (máquina virtual de bajo nivel).
La versión principal de GCC permanecerá constante durante toda la vida útil de AL2023. Las versiones menores incluyen correcciones de errores y podrían incluirse en las versiones de AL2023. Es posible que otras correcciones de errores, rendimiento y seguridad estén incorporadas a la versión principal de GCC que se incluye en AL2023.
AL2023 incluye la versión 11 de GCC como compilador predeterminado con las interfaces C (`gcc`), C\$1\$1 (`g++`) y Fortran (`gfortran`). Además, AL2023 proporciona la versión 14 de GCC como un compilador alternativo opcional que se puede instalar junto con la versión predeterminada.
AL2023 no habilita las interfaces Ada (`gnat`), Go (`gcc-go`), Objective-C ni Objective-C\$1\$1.
Los indicadores de compilación predeterminados con los que se crean los RPM de AL2023 incluyen indicadores de optimización y endurecimiento. Para crear su propio código con GCC, le recomendamos que incluya indicadores de optimización y endurecimiento.
**nota**
Cuando se invoca `gcc --version`, se muestra una cadena de versión como la siguiente `gcc (GCC) 11.3.1 20221121 (Red Hat 11.3.1-4)`. `Red Hat` hace referencia a la [ramificación de proveedores de GCC](https://gcc.gnu.org/gitwrite.html#vendor) en la que se basa el paquete GCC de Amazon Linux. Según la URL del informe de errores que aparece en `gcc --help`, todos los informes de errores y las solicitudes de soporte deben dirigirse a Amazon Linux.
Para obtener más información sobre algunos de los cambios a largo plazo en esta rama de proveedores, como la macro de `__GNUC_RH_RELEASE__`, consulte las fuentes de los paquetes de [Fedora](https://src.fedoraproject.org/rpms/gcc/pull-request/27).
Para obtener más información sobre la cadena de herramientas principal, consulte [Paquetes principales de cadenas de herramientas glibc, gcc, binutils](core-glibc.md).
Para obtener información sobre AL2023 y su relación con otras distribuciones de Linux, consulte [Relación con Fedora](relationship-to-fedora.md).
Para obtener información adicional sobre el cambio del triplete del compilador en AL2023 en comparación con AL2, consulte [Triplete del compilador](compare-with-al2.md#compiler-triplet).
**Topics**
+ [GCC 14](#gcc14)
+ [Comparación de versiones de lenguajes estándar](#language-standards-comparison)
## GCC 14
AL2023 proporciona GCC 14 como compilador opcional que se puede instalar junto con GCC 11 predeterminado. GCC 14 incluye las últimas funciones y optimizaciones del lenguaje, lo que lo hace adecuado para proyectos que requieren compatibilidad con los estándares C, C\$1\$1 o Fortran más recientes.
Para instalar GCC 14, utilice el siguiente comando:
```
sudo dnf install gcc14 gcc14-c++ gcc14-gfortran
```
Los compiladores de GCC 14 se instalan con nombres de comandos específicos de cada versión para evitar conflictos con GCC 11 predeterminado:
+ `gcc14-gcc`: compilador de C
+ `gcc14-g++`: compilador de C\$1\$1
+ `gcc14-gfortran`: compilador de Fortran
Ejemplo de uso:
```
gcc14-gcc -o myprogram myprogram.c
gcc14-g++ -o mycppprogram mycppprogram.cpp
gcc14-gfortran -o myfortranprogram myfortranprogram.f90
```
Puede comprobar la versión instalada ejecutando:
```
gcc14-gcc --version
```
Esto mostrará información de la versión similar a la siguiente: `gcc14-gcc (GCC) 14.2.1 20250110 (Red Hat 14.2.1-7)`
**nota**
Tanto GCC 11 como GCC 14 se pueden instalar simultáneamente en el mismo sistema. Los comandos `gcc`, `g++` y `gfortran` predeterminados seguirán utilizando GCC 11, mientras que el acceso a GCC 14 se realizará a través de los comandos específicos de la versión.
## Comparación de versiones de lenguajes estándar
En la siguiente tabla se comparan las versiones estándar de lenguajes predeterminados entre las distintas versiones de Amazon Linux y versiones del compilador de GCC:
| Versión de Amazon Linux | Estándar C (predeterminado) | Estándar C\$1\$1 (predeterminado) | Estándar de Fortran |
| --- | --- | --- | --- |
| AL2 con GCC 7 (predeterminado) | C11 (201112L) | C\$1\$114 (201402L) | Fortran 2008 |
| AL2 con GCC 10 (opcional) | C17/C18 (201710L) | C\$1\$114 (201402L) | Fortran 2008 |
| AL2023 con GCC 11 (predeterminado) | C17/C18 (201710L) | C\$1\$117 (201703L) | Fortran 2008 |
| AL2023 con GCC 14 (opcional) | C17/C18 (201710L) | C\$1\$117 (201703L) | Fortran 2008 |
**Mejoras clave por versión de GCC:**
+ **GCC 10 frente a GCC 7:** se actualizó el estándar C predeterminado de C11 a C17/C18, se agregó compatibilidad con las funciones de C\$1\$120 y se mejoraron las capacidades de optimización.
+ **GCC 11 frente a GCC 10:** se actualizó el estándar predeterminado de C\$1\$1 de C\$1\$114 a C\$1\$117, se mejoró la compatibilidad con C\$1\$120 y se agregaron características experimentales de C\$1\$123.
+ **GCC 14 frente a GCC 11:** se agregó compatibilidad total con el estándar C23, se mejoraron las características de C\$1\$123, se mejoró la optimización y se mejoró el cumplimiento de las normas.
**Estándares de lenguajes compatibles:**
+ **Estándares C:** todas las versiones son compatibles con C90, C99, C11 y C17/C18. GCC 10\$1 es compatible con C2x (borrador de la C23), mientras que GCC 14 es totalmente compatible con la versión C23.
+ **Estándares C\$1\$1:** todas las versiones son compatibles con C\$1\$198, C\$1\$103, C\$1\$111, C\$1\$114, C\$1\$117 y C\$1\$120. GCC 11\$1 ofrece compatibilidad experimental con C\$1\$123 y GCC 14 ofrece características mejoradas de C\$1\$123.
+ **Estándares de Fortran:** todas las versiones son compatibles principalmente con Fortran 2008, con diferentes niveles de funciones de Fortran 2018 según la versión GCC.
**nota**
Si bien los estándares predeterminados se mantienen consistentes entre la versión GCC 11 y la 14, GCC 14 proporciona una compatibilidad significativamente mejorada con las características del lenguaje, una mejor optimización, un diagnóstico mejorado y una implementación más completa de los estándares más nuevos cuando se solicita explícitamente mediante marcas `-std=`.
# .NETen AL2023
AL2023 actualmente proporciona el [https://dotnet.microsoft.com/](https://dotnet.microsoft.com/)motor de ejecución y el SDK, en las versiones 8.0, 9.0 y 10.0. .NETLa versión 6.0 llegó end-of-life en noviembre de 2024 y ya no es compatible. Cada versión es compatible durante el mismo período de tiempo que la versión anterior. .NET Para obtener más información, consulte las [declaraciones de soporte de paquetes](https://docs.aws.amazon.com/linux/al2023/release-notes/support-info-by-support-statement.html).
## Migración a versiones más recientes .NET
**La .NET comunidad upstream proporciona documentación de migración para la migración:**
+ [a .NET 10](https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotnet-10/overview)
+ [a .NET 9](https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotnet-9/overview)
+ [a .NET 8](https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotnet-8/overview)
## Instalando .NET en AL2023
Se pueden instalar varias versiones del .NET motor de ejecución simultáneamente AL2023. Sin embargo, los `dotnet-host` paquetes `dotnet` y se comparten en todas las versiones del SDK, por lo que solo una versión del SDK puede ser propietaria del punto de entrada de la `/usr/bin/dotnet` CLI a la vez. Si se instala una versión diferente del SDK, el `dotnet` comando compartido se actualizará a esa versión.
Para instalar una versión específica del .NET SDK, usa el `dnf` comando:
```
sudo dnf install dotnet-sdk-10.0
```
`10.0`Sustitúyala por la versión deseada (8.0, 9.0 o 10.0).
Para instalar solo el motor de ejecución sin el SDK:
```
sudo dnf install dotnet-runtime-9.0
```
# Goen AL2023
Es posible que desee crear su propio código escrito [https://go.dev/](https://go.dev/)en Amazon Linux y utilizar una cadena de herramientas incluida. AL2023 Similar a AL2, AL2023 actualizará la Go cadena de herramientas a lo largo de la vida útil del sistema operativo. Esto puede ser en respuesta a cualquier CVE de la cadena de herramientas que enviamos o como parte de una publicación trimestral.
Go es un lenguaje que se mueve relativamente rápido. Puede darse una situación en la que las aplicaciones existentes escritas en Go tengan que adaptarse a las nuevas versiones de la cadena de herramientas de Go. Para obtener más información sobre Go, consulte [Go 1 y el futuro de los programas Go](https://go.dev/doc/go1compat).
Aunque AL2023 incorporará nuevas versiones de la Go cadena de herramientas a lo largo de su vida útil, no estará en sintonía con las versiones anteriores. Go Por lo tanto, el uso de la Go cadena de herramientas que se proporciona en el documento AL2023 puede no ser adecuado si se quiere crear Go código con las funciones más avanzadas del Go lenguaje y de la biblioteca estándar.
Durante su vida útil AL2023, las versiones anteriores de los paquetes no se eliminan de los repositorios. Si se necesita una cadena de herramientas de Go anterior, los clientes pueden optar por no corregir los errores y las correcciones de seguridad de las cadenas de herramientas de Go más recientes, e instalar una versión anterior desde los repositorios con los mismos mecanismos disponibles para cualquier RPM.
Si quieres crear tu propio Go código AL2023, puedes utilizar la cadena de Go herramientas incluida AL2023 con la seguridad de que esta cadena de herramientas podría avanzar a lo largo de su vida útil. AL2023
## AL2023 Funciones Lambda escritas en Go
Como Go compila en código nativo, Lambda trata a Go como un tiempo de ejecución personalizado. Puede usar el `provided.al2023` tiempo de ejecución para implementar Go funciones en AL2023 Lambda.
Para obtener más información, consulte [Creación de funciones de Lambda con Go](https://docs.aws.amazon.com/lambda/latest/dg/lambda-golang.html) en la *Guía para desarrolladores de AWS Lambda *.
# Java en AL2023
AL2023 ofrece varias versiones de [Amazon Corretto](https://aws.amazon.com/corretto/) para admitir cargas de trabajo basadas en Java. Todos los paquetes basados en Java incluidos en AL2023 están diseñados con Amazon Corretto 17.
Corretto es una versión del Open Java Development Kit (OpenJDK) con el apoyo de Amazon a largo plazo. Corretto está certificado mediante el kit de compatibilidad técnica de Java (TCK) para garantizar que cumple con el estándar Java SE y está disponible en Linux, Windows y macOS.
Hay un paquete [Amazon Corretto](https://aws.amazon.com/corretto/) disponible para cada uno de los Corretto 1.8.0, Corretto 11 y Corretto 17.
Cada versión de Corretto en AL2023 es compatible durante el mismo período de tiempo que la versión de Corretto, o hasta el fin del servicio de AL2023, lo que ocurra primero. Para obtener más información, consulte las [declaraciones de soporte del paquete Amazon Linux](https://docs.aws.amazon.com/linux/al2023/release-notes/support-info-by-support-statement.html) y las [preguntas frecuentes de Amazon Corretto](https://aws.amazon.com/corretto/faqs).
# Node.jsen AL2 023
[https://nodejs.org/](https://nodejs.org/)en AL2 023 se representa mediante las versiones 20, 22 y 24. Amazon Linux sigue el [programa de soporte](https://github.com/nodejs/Release) previo y siempre se puede comprobar el estado del soporte de cualquier versión de Node.js en la [página de estado del soporte de Package](https://docs.aws.amazon.com/linux/al2023/release-notes/support-info-by-package.html). Todas las versiones compatibles de Node.js tienen espacios de nombres y se pueden instalar en el mismo sistema simultáneamente. El espacio de nombres garantiza que cada instalación de Node.js sea única dentro del sistema de archivos. Esto se consigue cambiando el nombre de los directorios y archivos clave en función de la versión en tiempo de ejecución. Los nombres reales de los ejecutables serán similares a *node-\$1MAJOR\$1VERSION\$1* o *npm-\$1MAJOR\$1VERSION\$1*. Solo puede haber una versión de Node.js activa a la vez. Esta versión activa proporciona los directorios y nombres de archivo predeterminados, como *node*, *npm* o*/usr/lib/node\$1modules*, y los dirige al entorno de ejecución actualmente activo.
Esto se logra utilizando las capacidades de la herramienta de *alternativas*. Es importante recordar que los nombres de los ejecutables predeterminados son virtuales y pueden cambiar en cualquier momento al apuntar a una versión de Node.js instalada diferente. Esta flexibilidad permite al software que utiliza *node* in the shebang seleccionar la versión deseada cuando se invoca. Sin embargo, cuando Node.js se requiere una versión específica de, la persistencia de la versión se puede lograr llamando al ejecutable con espacio de nombres (por ejemplo, *node-20 o *node-22**), que siempre usará la versión especificada del tiempo de ejecución. Además, los ejecutables con espacio de nombres de la herramienta *npm, como npm-20* o npm-22, siempre están asociados a la versión de Node.js correspondiente, independientemente del tiempo de ejecución activo actualmente.
Node.jsse distribuye en varios paquetes con espacios de nombres que comienzan por "». `nodejs{MAJOR_VERSION}` Estos paquetes proporcionan *node*, una versión compatible de la herramienta *npm*, documentación, bibliotecas y mucho más. Por ejemplo, *node* y *npm* de los Node.js 22 los proporcionan los `nodejs22-npm` paquetes `nodejs22` y, respectivamente.
La herramienta de *alternativas* proporciona un único comando para cambiar de una versión de Node.js a otra. De forma predeterminada, la herramienta de *alternativas* está configurada para estar en modo automático, que usa prioridades para determinar la versión de Node.js actualmente activa. Sin embargo, puede activar cualquier versión instalada en cualquier momento. Actualmente, todas las versiones compatibles de Node.js tienen la misma prioridad, lo que significa que la primera versión instalada se activará automáticamente.
**Algunos ejemplos útiles del uso de las *alternativas***
1. Compruebe para qué *alternativas* está configurada
```
alternatives --list
```
1. Compruebe la configuración actual del *nodo*
```
alternatives --display node
```
1. Cambie la versión de Node.js de forma interactiva
```
alternatives --config node
```
1. Cambie al modo manual y seleccione una versión específica
```
alternatives --set node /usr/bin/node-{MAJOR_VERSION}
```
1. Vuelva al modo de selección automática de versión
```
alternatives --auto node
```
# Perl en AL2023
AL2023 proporciona la versión 5.32 del lenguaje de programación [https://www.perl.org/](https://www.perl.org/)
A pesar de que Perl ha ofrecido un alto grado de compatibilidad lingüística como parte de las versiones de Perl 5 en las últimas décadas, no se espera que Amazon Linux pase de Perl 5.32 en la versión de AL2023. Amazon Linux seguirá aplicando parches de seguridad a Perl durante toda la vigencia de AL2023, de acuerdo con nuestras [declaraciones de soporte de paquetes](https://docs.aws.amazon.com/linux/al2023/release-notes/support-info-by-support-statement.html).
## Módulos Perl en AL2023
En AL2023, varios módulos Perl están empaquetados como RPM. Si bien hay muchos módulos Perl disponibles como RPM, Amazon Linux no pretende empaquetar todos los módulos Perl posibles. Los módulos empaquetados como RPM pueden ser utilizados por otros paquetes RPM del sistema operativo, por lo que Amazon Linux dará prioridad a esos parches de seguridad frente a las actualizaciones de características puras.
AL2023 también incluye `CPAN` para que los desarrolladores de Perl puedan utilizar el administrador de paquetes idiomático para módulos Perl.
# PHPen AL2 023
AL2Actualmente, 023 proporciona las versiones 8.1, 8.2, 8.3, 8.4 y 8.5 del lenguaje de [https://www.php.net/](https://www.php.net/)programación. Cada versión es compatible durante el mismo período de tiempo que el PHP inicial. Para obtener más información, consulte las [declaraciones de soporte de paquetes](https://docs.aws.amazon.com/linux/al2023/release-notes/support-info-by-support-statement.html).
## Migración desde versiones anteriores de PHP
**La comunidad del PHP inicial recopiló una documentación de migración completa para pasar:**
+ [de PHP 8.4.x a 8.5.x PHP](https://www.php.net/migration85)
+ [ de PHP 8.3.x a PHP 8.4.x](https://www.php.net/migration84)
+ [ de PHP 8.2.x a PHP 8.3.x](https://www.php.net/migration83)
+ [ de PHP 8.1.x a PHP 8.2.x](https://www.php.net/migration82)
+ [ de PHP 8.0.x a PHP 8.1.x](https://www.php.net/migration81)
AL2 incluye PHP 8.0, 8.1 y 8.2 para `amazon-linux-extras` permitir una ruta de actualización sencilla a la versión 023. AL2
## Migración desde las versiones PHP 7.x
**nota**
El proyecto [https://www.php.net/](https://www.php.net/) mantiene una lista y un cronograma de las [versiones compatibles](https://www.php.net/supported-versions.php), así como una lista de las [ramificaciones no compatibles](https://www.php.net/eol.php).
Cuando se lanzó la AL2 023, todas las versiones 7.x y 5.x de la 023 no [https://www.php.net/](https://www.php.net/)contaban con el apoyo de la PHP comunidad y no estaban incluidas como opciones en la versión 023. AL2
La comunidad de PHP inicial recopiló una [documentación de migración completa para pasar a PHP 8.0 desde PHP 7.4](https://www.php.net/migration80). En combinación con la documentación a la que se hace referencia en la sección anterior sobre la migración a las versiones PHP 8.1 y PHP 8.2, puede elaborar todos los pasos necesarios para migrar su aplicación basada en PHP a la versión moderna de PHP.
**nota**
AL2 incluye PHP 7,1, 7,2, 7,3 y 7,4 pulgadas. `amazon-linux-extras` Es importante tener en cuenta que no se end-of-life garantiza que todos estos extras reciban más actualizaciones de seguridad.
## PHPmódulos en AL2 023
AL2023 incluye muchos PHP módulos que se incluyen en PHP Core. AL2El objetivo de 023 no es incluir todos los paquetes de la [biblioteca comunitaria de PHP extensiones (PECL](https://pecl.php.net/)).
# Pythonen AL2023
AL2023 eliminó la Python versión 2.7 y todos los componentes Python necesarios ahora están escritos para funcionar con la Python versión 3.
AL2023 pone a disposición Python 3 `/usr/bin/python3` para mantener la compatibilidad con el código del cliente, así como con el código Python AL2023 incluido, que permanecerá como Python 3.9 durante toda su vida útil AL2023.
La versión de python a la que `/usr/bin/python3` apunta se considera el *sistema Python* y para AL2023 ello es la Python 3.9.
AL2023 actualmente proporciona versiones más recientes dePython, incluidas las versiones 3.11, 3.12, 3.13 y 3.14. Cada versión es compatible durante el mismo período de tiempo que la versión anterior. Python Para obtener más información, consulte las [declaraciones de soporte de paquetes](https://docs.aws.amazon.com/linux/al2023/release-notes/support-info-by-support-statement.html).
Se Python pueden instalar varias versiones de simultáneamente. AL2023 Si bien `/usr/bin/python3` siempre será Python 3.9, cada versión de Python tiene un espacio de nombres y se puede encontrar por su número de versión. Por ejemplo, si `python3.11` está instalada, `/usr/bin/python3.11` existirá junto con `/usr/bin/python3.9` y el enlace simbólico `/usr/bin/python3` apunta a `/usr/bin/python3.9`.
**nota**
No cambies a qué apunta el `/usr/bin/python3` enlace simbólico, ya que esto podría interrumpir la funcionalidad principal de AL2023.
## Migración a versiones más recientes Python
**La Python comunidad upstream proporciona documentación de migración para la migración:**
+ [a Python 3.14](https://docs.python.org/3/whatsnew/3.14.html)
+ [a Python 3.13](https://docs.python.org/3/whatsnew/3.13.html)
+ [a Python 3.12](https://docs.python.org/3/whatsnew/3.12.html)
+ [a Python 3.11](https://docs.python.org/3/whatsnew/3.11.html)
## Pythonmódulos en AL2023
Varios Python módulos se empaquetan como RPMs en AL2023. Por lo general, RPMs Python los módulos se construirán pensando únicamente en la versión del sistema dePython.
# Rubyen AL2023
[https://www.ruby-lang.org/en/](https://www.ruby-lang.org/en/)in AL2023 está representado por las versiones 3.2 y 3.4. Amazon Linux sigue el programa de soporte previo y siempre se puede comprobar el estado del soporte de cualquier Ruby versión en el sitio [web de Ruby](https://www.ruby-lang.org/en/). Todas las versiones compatibles de Ruby tienen espacios de nombres y se pueden instalar en el mismo sistema simultáneamente. El espacio de nombres garantiza que cada instalación de Ruby sea única dentro del sistema de archivos. Esto se consigue cambiando el nombre de los directorios y archivos clave en función de la versión en tiempo de ejecución. Los nombres reales de los ejecutables serán como *ruby \$1MAJOR.MINOR\$1* (p. ej., o). `ruby3.2` `ruby3.4` Ruby3.4 también proporciona el binario con espacio de nombres MRI (Matz's Ruby Interpreter)`ruby3.4-mri`, que hace referencia a la implementación de referencia estándar basada en C. Ruby Solo puede haber una versión de Ruby activa a la vez. Esta versión activa proporciona los directorios y nombres de archivo predeterminados, como *ruby*, *gem* o *bundle*, y los dirige al motor de ejecución actualmente activo.
Esto se logra utilizando las capacidades de la herramienta de *alternativas*. Es importante recordar que los nombres de los ejecutables predeterminados son virtuales y pueden cambiar en cualquier momento al apuntar a una versión de Ruby instalada diferente. Esta flexibilidad permite al software que utiliza *ruby* in the shebang seleccionar la versión deseada al invocarla. Sin embargo, cuando Ruby se requiere una versión específica de, la persistencia de la versión se puede lograr llamando al ejecutable con espacio de nombres (por ejemplo, `ruby3.2` o`ruby3.4`), que siempre utilizará la versión especificada del tiempo de ejecución. Además, los ejecutables con espacio de nombres de las herramientas *gemelas* y *empaquetadoras,* como,, o`ruby3.2-gem`, `ruby3.4-gem``ruby3.2-bundler`, siempre están asociados a la Ruby versión correspondiente`ruby3.4-bundler`, independientemente del tiempo de ejecución activo en ese momento.
Rubyse distribuye en varios paquetes con espacios de nombres que comienzan por "». `ruby{MAJOR.MINOR}` Estos paquetes proporcionan versiones compatibles con *Ruby* de las herramientas *Gem* y *Bundler*, documentación, bibliotecas y mucho más. Por ejemplo, el `ruby3.2` paquete proporciona el tiempo de ejecución principal de Ruby 3.2, que incluye (proporciona la *gema*) y `ruby3.2-rubygems` `ruby3.2-rubygem-bundler` (proporciona el paquete y el *paquete*) como *dependencias*.
*Tras instalar una Ruby versión, es posible que las entradas de las herramientas complementarias aparezcan como nulas en la configuración de las alternativas.* Esto se puede comprobar ejecutándolo`alternatives --display ruby`. Si las entradas aparecen como nulas, deben registrarse manualmente mediante`alternatives --install`. Por ejemplo, para registrar todas las herramientas complementarias de la versión Ruby 3.4:
```
sudo alternatives --install /usr/bin/gem gem /usr/bin/ruby3.4-gem 34
sudo alternatives --install /usr/bin/bundle bundle /usr/bin/ruby3.4-bundle 34
sudo alternatives --install /usr/bin/bundler bundler /usr/bin/ruby3.4-bundler 34
sudo alternatives --install /usr/bin/erb erb /usr/bin/ruby3.4-erb 34
sudo alternatives --install /usr/bin/racc racc /usr/bin/ruby3.4-racc 34
sudo alternatives --install /usr/bin/rdoc rdoc /usr/bin/ruby3.4-rdoc 34
sudo alternatives --install /usr/bin/ri ri /usr/bin/ruby3.4-ri 34
```
El valor de prioridad (por ejemplo, 34 para Ruby 3.4, 32 para Ruby 3.2) debe coincidir con la prioridad utilizada en la entrada principal alternativa de *Ruby*. Una vez registradas, las herramientas complementarias se administrarán automáticamente junto con la alternativa a *Ruby*.
La herramienta de *alternativas* proporciona un único comando para cambiar de una versión de Ruby a otra. De forma predeterminada, la herramienta de *alternativas* está configurada para estar en modo automático, que usa prioridades para determinar la versión de Ruby actualmente activa. Sin embargo, puede activar cualquier versión instalada en cualquier momento. Actualmente, todas las versiones compatibles de Ruby tienen la misma prioridad, lo que significa que la primera versión instalada se activará automáticamente.
**Algunos ejemplos útiles del uso de las *alternativas***
1. Compruebe para qué *alternativas* está configurada
```
alternatives --list
```
1. Comprueba la configuración actual de *ruby*
```
alternatives --display ruby
```
1. Cambie la versión de Ruby de forma interactiva
```
alternatives --config ruby
```
1. Cambie al modo manual y seleccione una versión específica
```
alternatives --set ruby /usr/bin/ruby{MAJOR.MINOR}
```
1. Vuelva al modo de selección automática de versión
```
alternatives --auto ruby
```
# Rusten AL2023
Es posible que desee compilar código escrito [https://www.rust-lang.org/](https://www.rust-lang.org/)en Amazon Linux y utilizar una cadena de herramientas incluida. AL2023
Similar a AL2, AL2023 actualizará la Rust cadena de herramientas a lo largo de la vida útil del sistema operativo. Esto puede ser en respuesta a cualquier CVE de la cadena de herramientas que enviamos o como parte de una publicación trimestral.
[Rust](https://www.rust-lang.org/) es un lenguaje que evoluciona con relativa rapidez, con nuevos lanzamientos con una cadencia aproximada de seis semanas. Estas versiones pueden añadir un nuevo lenguaje o características de biblioteca estándar. Aunque AL2023 incorporará nuevas versiones de la Rust cadena de herramientas a lo largo de su vida útil, no estará en sintonía con las versiones anteriores. Rust Por lo tanto, el uso de la Rust cadena de herramientas que se proporciona en el documento AL2023 puede no ser adecuado si desea crear Rust código con las funciones más avanzadas del lenguaje. Rust
Durante su vida útil AL2023, las versiones antiguas de los paquetes no se eliminan de los repositorios. Si se necesita una cadena de herramientas de Rust más antigua, los clientes pueden optar por no corregir los errores y las correcciones de seguridad de las cadenas de herramientas de Rust más recientes, e instalar una versión anterior desde los repositorios con los mismos mecanismos disponibles para cualquier RPM.
Si quieres crear tu propio Rust código AL2023, puedes utilizar la cadena de Rust herramientas incluida AL2023 con la seguridad de que esta cadena de herramientas podría avanzar a lo largo de su vida útil. AL2023
## AL2023 Funciones Lambda escritas en Rust
Como Rust compila en código nativo, Lambda trata a Rust como un tiempo de ejecución personalizado. Puede usar el `provided.al2023` tiempo de ejecución para implementar Rust funciones en AL2023 Lambda.
Para obtener más información, consulte [Creación de funciones de Lambda con Rust](https://docs.aws.amazon.com/lambda/latest/dg/lambda-rust.html) en la *Guía para desarrolladores de AWS Lambda *.
# Swiften AL2023
AL2023 actualmente proporciona el [https://https://www.swift.org](https://https://www.swift.org)tiempo de ejecución y el SDK.
En AL2023, el Swift SDK y el tiempo de ejecución se dividen en paquetes separados. El `swiftlang-lib` paquete contiene las bibliotecas de tiempo de ejecución y el `swiftlang` paquete contiene el SDK completo. Esto permite a los usuarios ejecutar binarios compilados con el Swift SDK en los hosts de producción sin necesidad de instalar el SDK completo. En este momento, hay diferentes versiones de que no Swift son compatibles con ABI, por lo queSwift, cuando se actualicen, las aplicaciones deberán reconstruirse con la nueva versión antes de poder implementarlas.
**nota**
Por ejemploRust, Swift las versiones seguirán a la última versión estable del Swift proyecto. Los paquetes no tendrán espacios de nombres y solo se admitirá una versión a la vez.
## Algunas notas sobre el uso de Swift AL2023
+ **Interoperabilidad con C\$1\$1**: es `clang` posible que el administrador de paquetes del sistema no funcione conSwift. Para resolver este problema, añada `swift-clang` a su configuración `PATH` o utilice alternativas para `clang` configurarlas`swift-clang`.
+ **Depuración del código Swift**: el sistema LLDB no puede depurar Swift las fuentes. En su lugar, utilice el que se LLDB incluye con el Swift paquete añadiendo el directorio de Swift instalación al suyo `PATH` o utilizando alternativas para `lldb` configurarlo. `swift-lldb`
# TypeScript en AL2023
**nota**
Este documento proporciona la información esencial sobre TypeScript y su entorno de ejecución basado en Node.js. También cubre un flujo de trabajo de desarrollo típico y explica cómo se empaqueta TypeScript en AL2023 para ofrecer un entorno de desarrollo coherente y reproducible.
[https://www.typescriptlang.org/](https://www.typescriptlang.org/) (TS) es un lenguaje de programación basado en JavaScript (JS) que ofrece todas las funciones de JS y, además, [lo amplía con un sistema de tipos](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html). En un escenario típico, los programas escritos en TS se traducen primero al código JS y luego se ejecutan como cualquier otro programa JS normalNode.js. En la terminología específica de TS, este proceso de traducción se denomina [“compilación” y lo realiza un “compilador”](https://www.typescriptlang.org/docs/handbook/typescript-tooling-in-5-minutes.html), llamado *tsc*. El propio compilador *tsc* está escrito en JS, por lo que, para ejecutarse, también necesita un entorno de ejecución de JS, como Node.js. A diferencia de otros entornos de ejecución de JS, Node.js actualmente solo tiene soporte TS experimental y ligero. La compatibilidad total con TS, incluida la verificación de tipos, aún requiere el uso de paquetes de terceros, como [TypeScript](https://www.npmjs.com/package/typescript). La forma esperada de obtener *tsc* (el compilador de TS) para el entorno de ejecución de Node.js es instalar el módulo de nodo Typescript. Esto se puede hacer usando uno de los administradores de paquetes, normalmente *npm*. Hay dos formas de instalar el compilador de TS usando *npm*: globalmente y en un proyecto. [El método recomendado oficialmente es instalar](https://www.typescriptlang.org/download/) el compilador de TS por proyecto, lo que garantiza la coherencia y la reproducibilidad de los proyectos a largo plazo. Sin embargo, instalar el compilador de TS de forma global puede seguir siendo útil, ya que proporciona la misma versión para todo el host y su entorno de ejecución de JS y, por lo tanto, para los proyectos que no tienen un compilador de TS instalado localmente. Así es precisamente como los paquetes RPM disponibles en Amazon Linux, como `nodejs20-typescript` o `nodejs22-typescript`, instalan un compilador de TS: globalmente en el nivel del sistema y por separado para cada versión de Node.js compatible.
El *tsc* no depende directamente de ninguna versión de Node.js. El compilador espera un cierto nivel de características de tiempo de ejecución, que se definen en un archivo especial (*tsconfig.json*) a través de opciones tales como [target](https://www.typescriptlang.org/tsconfig/#target) y [lib](https://www.typescriptlang.org/tsconfig/#lib). Los valores de estas opciones representan una versión del estándar [ECMAScript](https://en.wikipedia.org/wiki/ECMAScript_version_history) (ES), que puede (o no) ser compatible con el entorno de ejecución JS. Las distintas versiones de Node.js admiten diferentes versiones de ES. Cuanto más reciente sea la versión de Node.js, más alta y completa será la compatible con la versión estándar de ES. Si *tsconfig.json* no existe en el directorio raíz de un proyecto, se utilizará el conjunto predeterminado de opciones de configuración. La tabla de compatibilidad con las distintas versiones de Node.js y las funciones compatibles de las distintas versiones estándar de ES está disponible en [node.green](https://node.green/). El *tsc* tiene más de 100 opciones diferentes, que se pueden definir en *tsconfig.json*. También se admite el encadenamiento de configuraciones cuando algunas opciones de configuración se definen en otro archivo y luego se incluyen en el archivo principal. Este enfoque permite instalar una [configuración TS base](https://github.com/tsconfig/bases) compatible con una versión determinada de y, a continuación, ampliarla con opciones específicas del proyecto. Afortunadamente, las configuraciones TS base de Node.js están disponibles como módulos de nodo que se pueden instalar en una carpeta de proyecto mediante *npm*. Este es el código fuente de la configuración para las versiones de Node.js [18](https://github.com/tsconfig/bases/blob/main/bases/node18.json), [20](https://github.com/tsconfig/bases/blob/main/bases/node20.json) y [22](https://github.com/tsconfig/bases/blob/main/bases/node22.json).
El diseño del tiempo de ejecución de Node.js basado tiene una cierta debilidad: solo admite una versión del tiempo de ejecución en un host y requiere la reproducibilidad y la coherencia de todas las dependencias en el nivel del proyecto. Esto llevó al siguiente enfoque común de usar TypeScript: el compilador de TS, la configuración base de TS para la versión actual de Node.js y todas las dependencias de software se instalan localmente, dentro de un proyecto. Aunque se espera que los módulos de nodo instalados globalmente sean solo herramientas CLI, como *npm* y *tsc*, que también es una herramienta CLI, rara vez se instala globalmente. Afortunadamente, las instalaciones globales (en todo el sistema) y locales (dentro de un proyecto) de *tsc* pueden coexistir sin problemas y también pueden ser versiones diferentes que se utilizan de forma independiente. Tenga en cuenta que un *tsc* instalado localmente debe ejecutarse con la herramienta *npx*, que se instala junto con *npm*. Por lo tanto, incluso con un compilador TS de sistema, los usuarios tienen la oportunidad de elegir versiones de los componentes del motor de ejecución, por ejemplo Node.js (cambiando la versión activa por alternativas), un compilador de TS (instalándolo local o globalmente y también cambiando la versión activa a través de alternativas) y configurándolo según las necesidades específicas.
Amazon Linux empaqueta un compilador de TS de la misma forma que otros módulos de nodos instalados globalmente, como *npm*, en una versión básica por versión de Node.js. Los paquetes y los binarios tienen espacios de nombres y contienen la versión principal de Node.js como parte de sus nombres. El nombre ejecutable predeterminado del compilador, *tsc*, lo administra en tiempo de ejecución la herramienta de alternativas y apunta a la versión actualmente activa de Node.js para la que se instaló y con la que se ejecutará. Esta selección no depende de la versión de tiempo de ejecución actual de Node.js. Es posible tener un ejecutable de *nodo* que apunte a Node.js 20 y que *tsc* esté configurado para ser interpretado por Node.js 22. También es posible utilizar los nombres con espacios de nombres de un compilador de TS, por ejemplo, *tsc- \$1MAJOR\$1VERSION\$1* independientemente de para qué esté configurado el nombre de *tsc* predeterminado.
**Algunos comandos útiles para administrar la versión activa de un compilador de TS**
1. Compruebe para qué *alternativas* está configurada
```
alternatives --list
```
1. Compruebe la configuración actual de *tsc*
```
alternatives --display tsc
```
1. Cambie la versión de tsc de forma interactiva
```
alternatives --config tsc
```
1. Cambie al modo manual y seleccione una versión específica
```
alternatives --set tsc /usr/bin/tsc-{MAJOR_VERSION}
```
1. Vuelva al modo de selección automática de versión
```
alternatives --auto tsc
```
Un ejemplo de instalación y uso de varias versiones de Node y un compilador de TS en el mismo sistema:
```
# Check the AL2023 release
$ cat /etc/amazon-linux-release
Amazon Linux release 2023.9.20250929 (Amazon Linux)
# Install a TypeScript compiler for Node.js 20 and 22
# Node.js 20 and 22 will be installed automatically
$ sudo dnf install -qy nodejs20-typescript nodejs22-typescript
# Check what was installed
$ rpm -q nodejs20 nodejs20-typescript nodejs22 nodejs22-typescript
nodejs20-20.19.5-1.amzn2023.0.1.x86_64
nodejs20-typescript-5.9.2-1.amzn2023.0.1.noarch
nodejs22-22.19.0-1.amzn2023.0.1.x86_64
nodejs22-typescript-5.9.2-1.amzn2023.0.1.noarch
# Check the active version of Node.js - it is version 20
$ alternatives --display node
node - status is auto.
link currently points to /usr/bin/node-20
/usr/bin/node-20 - priority 100
slave npmrc: /usr/lib/nodejs20/lib/node_modules/npm/npmrc
slave npm: /usr/bin/npm-20
slave npx: /usr/bin/npx-20
slave node_modules: /usr/lib/nodejs20/lib/node_modules
/usr/bin/node-22 - priority 100
slave npmrc: /usr/lib/nodejs22/lib/node_modules/npm/npmrc
slave npm: /usr/bin/npm-22
slave npx: /usr/bin/npx-22
slave node_modules: /usr/lib/nodejs22/lib/node_modules
Current 'best' version is /usr/bin/node-20.
# Check the active JS runtime version for TypeScript
# Currently, the tsc compiler will be executed by Node.js 22
$ alternatives --display tsc
tsc - status is auto.
link currently points to /usr/bin/tsc-22
/usr/bin/tsc-22 - priority 100
slave tsserver: /usr/bin/tsserver-22
/usr/bin/tsc-20 - priority 100
slave tsserver: /usr/bin/tsserver-20
Current 'best' version is /usr/bin/tsc-22.
# Check versions printed by executables
$ node -v
v20.19.5
$ tsc -v
Version 5.9.2
# while the node is 20, tsc is executed by node 22 anyway
$ head -1 /usr/bin/tsc
#!/usr/bin/node-22
# However, instead of default executable names, e.g. node or tsc,
# we can use namespaced names to target any installed version
$ node-20 -v
v20.19.5
$ node-22 -v
v22.19.0
$ tsc-20 -v
Version 5.9.2
$ tsc-22 -v
Version 5.9.2
$ head -1 /usr/bin/tsc-20
#!/usr/bin/node-20
$ head -1 /usr/bin/tsc-22
#!/usr/bin/node-22
```