¿Qué es ImplicitUsings en C# y por qué es útil?

Con la llegada de .NET 6 y la idea de simplificar el código, Microsoft introdujo una nueva funcionalidad que puede ahorrarte varias líneas repetitivas en los archivos .cs: los usings implícitos, habilitados con la propiedad <ImplicitUsings>.

Cuando activás esta propiedad en el archivo .csproj, el compilador de C# agrega automáticamente un conjunto de using comunes a todos los archivos del proyecto, sin que tengas que escribirlos vos mismo.

Por ejemplo: 

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>

    <TargetFramework>net8.0</TargetFramework>

    <ImplicitUsings>enable</ImplicitUsings>

  </PropertyGroup>

</Project>

Gracias a esto, podés usar tipos como List<string>, Task, HttpClient, etc., directamente, sin declarar explícitamente:

using System.Collections.Generic;

using System.Threading.Tasks;

using System.Net.Http;

¿Qué usings incluye? Depende del tipo de proyecto (console, ASP.NET, etc.), pero algunos de los más comunes son:

• System
• System.Collections.Generic
• System.IO
• System.Linq
• System.Net.Http
• System.Threading.Tasks
• Y muchos más según el SDK usado

Si querés ver la lista exacta, podés mirar el archivo generado: obj/YourProject.GlobalUsings.g.cs

<ImplicitUsings> es una pequeña gran herramienta que simplifica la escritura de código en C#, especialmente útil en proyectos nuevos. Al eliminar la necesidad de repetir los mismos using una y otra vez, te permite concentrarte en lo que realmente importa: la lógica de tu aplicación.

Clases, Métodos, Propiedades e Indexadores Parciales en C#

En C#, el modificador partial no se limita solo a clases. También puede aplicarse a métodos, propiedades y hasta indexadores.  

Esta característica permite dividir y extender la definición de estos elementos, haciendo que el código sea más limpio, modular y mantenible.

Una clase parcial es aquella que puede ser dividida en múltiples archivos.  

Cada fragmento de la clase debe usar el modificador partial.

Veamos un ejemplo:

// Archivo Persona_Datos.cs

public partial class Persona

{

    public string Nombre { get; set; }

}

// Archivo Persona_Operaciones.cs

public partial class Persona

{

    public string ObtenerNombreCompleto() => Nombre;

}

Al compilar, el compilador junta todas las partes como si estuvieran en un único archivo.

Un método parcial (partial void) permite declarar un método que puede (o no) ser implementado en otra parte de la clase.  

Si no se implementa, el compilador simplemente lo ignora, como si nunca hubiera existido.

Vamos con el ejemplo: 

// Declaración

public partial class Persona

{

    partial void ValidarNombre();

}

// Implementación opcional

public partial class Persona

{

    partial void ValidarNombre()

    {

        if (string.IsNullOrEmpty(Nombre))

        {

            Console.WriteLine("Nombre inválido");

        }

    }

}

• Los métodos parciales siempre deben ser void.
• No pueden tener modificadores de acceso (`public`, `private`, etc.).
• No pueden ser virtuales ni static ni async.

Propiedades Parciales (desde C# 12)

Desde C# 12, se pueden crear propiedades parciales, permitiendo que la lógica de getters y setters sea definida en distintas partes del código.

public partial class Persona

{

    public partial string Nombre { get; set; }

}

// En otro archivo:

public partial class Persona

{

    public partial string Nombre

    {

        get => _nombre;

        set => _nombre = value.Trim();

    }

    private string _nombre;

}

Con esta característica se puede separar la definición de una propiedad de su comportamiento, facilitando la generación automática de propiedades o su personalización.

Un indexador parcial permite dividir la definición de un indexador (this[...]) en varias partes.

Por ejemplo:

public partial class MiColeccion

{

    public partial string this[int index] { get; set; }

}

// En otro archivo:

public partial class MiColeccion

{

    private string[] _datos = new string[10];

    public partial string this[int index]

    {

        get => _datos[index];

        set => _datos[index] = value;

    }

}

Partial es muy importante porque: 

• Separar código generado automáticamente del código personalizado.
• Mejorar la legibilidad y mantenimiento en proyectos grandes.
• Permitir que distintos desarrolladores trabajen simultáneamente en distintas partes de una clase.
• Facilitar extensiones futuras sin modificar directamente el código base.

El soporte de C# para clases, métodos, propiedades e indexadores parciales te da un gran poder para modularizar tu código de forma clara y ordenada.  

Esta es una característica que, bien aprovechada, puede hacer una gran diferencia en proyectos de cualquier tamaño.

Parámetros por Referencia en C#: ref, out, in y Punteros (unsafe)

Cuando programás en C#, tenés varias formas de pasar argumentos a un método: por valor (el comportamiento predeterminado) o por referencia. Esta última opción es muy útil cuando necesitás que el método pueda modificar directamente la variable original, sin copiarla.

En este post te cuento las distintas formas de hacerlo: ref, out, in, y punteros (unsafe). Además, te muestro cómo declararlos, cuándo conviene usarlos, y qué diferencias tienen entre sí.

ref: Lectura y escritura

Con ref, el método puede leer y modificar la variable pasada. Pero el valor debe estar inicializado antes de pasarla.

void SumarUno(ref int numero)
{
    numero += 1;
}

int x = 5;
SumarUno(ref x);  // x ahora vale 6




out: Solo escritura

Con out, el método debe asignar un valor. La variable no necesita estar inicializada previamente.

void ObtenerDoble(out int resultado)
{
    resultado = 84;
}

int r;
ObtenerDoble(out r);  // r ahora vale 84

Ideal cuando querés devolver más de un valor desde un método.




in: Solo lectura

Con in, pasás una variable por referencia, pero solo para lectura. Sirve especialmente con structs grandes, para evitar la copia de memoria.

void Mostrar(in int numero)
{
    Console.WriteLine(numero);
}

int y = 10;
Mostrar(in y);  // y no se puede modificar dentro del método

Punteros (unsafe): Bajo nivel

Si necesitás controlar la memoria directamente, podés usar punteros en código unsafe.

unsafe void Incrementar(int* ptr)
{
    *ptr += 1;
}

unsafe
{
    int z = 7;
    Incrementar(&z);  // z ahora vale 8
}

Declaración rápida

// ref
void Modificar(ref int x)

// out
void Inicializar(out int x)

// in
void SoloLeer(in int x)

// unsafe pointer
unsafe void Modificar(int* x)

Comparativa rápida

Keyword	¿Inicialización previa?	¿Se puede leer?	¿Se puede escribir?	Uso típico
ref	✅	✅	✅	Modificar valor
out	❌	❌	✅	Devolver datos
in	✅	✅	❌	Structs grandes
*	✅	✅	✅	Bajo nivel

Ejemplos útiles

// struct con ref
struct Punto { public int X, Y; }

void Mover(ref Punto p) => p.X += 10;

// out con TryParse
bool TryParseNumero(string s, out int resultado)
{
    return int.TryParse(s, out resultado);
}

// in con cálculo
void MostrarDistancia(in Punto p)
{
    Console.WriteLine($"Distancia: {Math.Sqrt(p.X * p.X + p.Y * p.Y)}");
}

// unsafe con array
unsafe void Duplicar(int* arr, int n)
{
    for (int i = 0; i < n; i++) arr[i] *= 2;
}

C# te da muchas formas de pasar datos, y conocer ref, out, in y los punteros te permite optimizar tu código, mejorar la performance, y diseñar APIs más expresivas. Cada palabra clave tiene su contexto ideal, y entenderlas bien te va a dar más poder sobre lo que tu código realmente hace.

El Poder del underscore (_) en Scala

Scala es un lenguaje conciso y expresivo, y una de sus herramientas más versátiles es el underscore (_). Aunque parece un simple guion bajo, su significado depende del contexto, y puede representar una variable anónima, un tipo genérico, una función parcial, o incluso un importador wildcard. Vamos a repasar sus usos principales con ejemplos simples.

Cuando usás una función que espera un argumento, podés usar _ para decir “acá va ese argumento”.

val nums = List(1, 2, 3)

val dobles = nums.map(_ * 2)  // equivale a nums.map(x => x * 2)

Esto es súper útil para evitar código repetitivo.

Se puede utilizar para ignorar parámetros no usados

Cuando definís una función pero no te interesa usar todos los parámetros:

val funcion = (_: Int) => 42  // ignora el valor que recibe y siempre retorna 42

También se usa para desestructuración parcial:

val (a, _) = (1, 2)  // Ignora el segundo valor

Importaciones tipo wildcard. Igual que en Java con *, pero en Scala se usa _:

import scala.collection.mutable._  // importa todas las clases de mutable

Referencia a métodos como funciones. Cuando pasás un método como función, usas _ para convertirlo a función de orden superior:

def cuadrado(x: Int): Int = x * x

val lista = List(1, 2, 3).map(cuadrado)     // OK

val lista2 = List(1, 2, 3).map(cuadrado _)  // También válido, por conversión explícita

Inicialización por defecto en clases o valores:

var x: String = _  // valor por defecto: null

var y: Int = _     // valor por defecto: 0

Esto es más común en Java-style code o interoperabilidad con frameworks como Spark o Akka.

Tipos genéricos anónimos, como vimos antes:

val lista: List[_] = List("a", 1, true)  // lista de algún tipo desconocido

También podés usar _ <: Animal o _ >: Perro para acotar subtipos o supertypos.

Podés dejar argumentos sin aplicar en una llamada y usar _ para marcar que falta ese valor:

def multiplicar(a: Int, b: Int): Int = a * b

val porDos = multiplicar(2, _: Int)  // función que multiplica por 2

println(porDos(5))  // 10

Dominar el uso del _ te permite escribir código Scala más idiomático y elegante.

Nuevas características de C# 13

C# 13, junto con .NET 9, trae una serie de mejoras que buscan simplificar la escritura de código, mejorar el rendimiento y ofrecer mayor flexibilidad a los desarrolladores. Veamos que trajo:

Colecciones params mejoradas

Ahora, el modificador params se puede aplicar a tipos que admiten inicialización mediante expresiones de colección, no solo a arreglos. Esto permite una mayor flexibilidad al definir métodos que aceptan un número variable de argumentos.

public void EscribirNombres(params List<string> nombres)

    => Console.WriteLine(string.Join(", ", nombres));

Nuevo tipo de bloqueo: System.Threading.Lock

Se introduce un nuevo tipo de bloqueo que mejora la sincronización de subprocesos. A diferencia del uso tradicional de lock con objetos, System.Threading.Lock proporciona una API más clara y segura para manejar exclusiones mutuas.

var myLock = new Lock();

using (myLock.EnterScope())

{

    // Código protegido

}

Nueva secuencia de escape: \e

Se añade la secuencia de escape \e para representar el carácter de escape ASCII (U+001B). Anteriormente, se utilizaban \u001b o \x1b, pero esta nueva notación es más clara y evita ambigüedades.

Tipos naturales de grupo de métodos

Se mejora la inferencia de tipos al trabajar con grupos de métodos, permitiendo que el compilador determine de manera más precisa el tipo adecuado en contextos donde se utilizan delegados o expresiones lambda.

Propiedades e indexadores parciales

Al igual que los métodos parciales, ahora es posible declarar propiedades e indexadores parciales. Esto facilita la separación de la declaración y la implementación, especialmente útil al trabajar con generadores de código.

partial class MiClase

{

    public partial int MiPropiedad { get; set; }

}

Acceso implícito a indexadores en inicializadores de objetos

Se permite el uso de índices implícitos, como [^1], dentro de inicializadores de objetos, lo que simplifica la inicialización de colecciones y estructuras de datos complejas.

var miArreglo = new int[5] { [^1] = 10 };

Soporte para ref struct en interfaces y genéricos

Los tipos ref struct ahora pueden implementar interfaces y ser utilizados como argumentos de tipo en genéricos, ampliando su aplicabilidad en escenarios de alto rendimiento y manipulación de memoria.

Variables ref y contextos unsafe en iteradores y métodos asincrónicos

Se habilita el uso de variables ref locales y contextos unsafe dentro de métodos asincrónicos y iteradores, siempre que se cumplan ciertas restricciones para garantizar la seguridad del código.

Atributo OverloadResolutionPriority

Se introduce el atributo OverloadResolutionPriority que permite a los desarrolladores especificar la prioridad de resolución de sobrecargas, facilitando la evolución de las API sin romper compatibilidad con versiones anteriores.

Estas mejoras reflejan el compromiso continuo de la comunidad de C# por evolucionar el lenguaje, haciéndolo más potente y expresivo. 

Dejo link: https://developers.redhat.com/articles/2025/04/16/c-13-new-features#

Tipos Genéricos Anónimos en Scala: Wildcards y Subtipado

Antes de empezar este post tal vez sería bueno que leas este post antes :D

Scala permite definir colecciones y estructuras de datos genéricas, pero a veces no necesitamos saber con precisión qué tipo contienen, o simplemente queremos permitir varios tipos relacionados. Para esos casos existen los tipos genéricos anónimos, representados por el underscore (_).

Un tipo genérico anónimo en Scala se escribe con un guion bajo (_) en lugar de especificar un tipo concreto. Es útil cuando:

• No necesitás conocer el tipo exacto.
• Queremos aceptar varios subtipos o supertypos.

Veamos un ejemplo:

Lista de cualquier tipo (wildcard total)

val lista: List[_] = List(1, "hola", true)

Esto indica que lista es de algún tipo List[T], pero no importa cuál es T.

Subtipado: _ <: Tipo

Permite aceptar cualquier subtipo del tipo dado (covarianza).

class Animal

class Perro extends Animal

class Gato extends Animal

val animales: List[_ <: Animal] = List(new Perro, new Gato)

Esto significa: una lista de algo que es subtipo de Animal.

Supertyping: _ >: Tipo

Permite aceptar cualquier supertipo del tipo dado (contravarianza).

val cosas: List[_ >: Perro] = List(new Animal, new Perro)

Esto significa: una lista de algo que es supertipo de Perro.

Y ¿Por qué usar genéricos anónimos?

• Cuando escribís funciones genéricas que pueden aceptar muchos tipos.
• Para asegurar compatibilidad con estructuras covariantes/contravariantes.
• Para restringir o abrir el tipo de manera controlada.

Los tipos anónimos no te permiten hacer mucho con los elementos (no podés acceder a sus métodos específicos), porque Scala no sabe exactamente qué tipo hay.

val lista: List[_] = List("hola", "chau")

// lista(0).toUpperCase()  // ERROR: no se puede garantizar el tipo

En Java existe el signo de pregunta para esto (?):

List<?> lista;

List<? extends Animal> subtipos;

List<? super Perro> supertypos;

En Scala es más limpio y expresivo:

List[_]

List[_ <: Animal]

List[_ >: Perro]

Los tipos genéricos anónimos en Scala te permiten trabajar con estructuras de datos más genéricas y flexibles, especialmente en APIs o librerías donde no se necesita o no se conoce el tipo exacto. Son ideales para mantener la seguridad de tipos sin perder generalidad.

Tipos de Herencia en C++

En C++, cuando una clase hereda de otra, podemos especificar cómo se deben heredar los miembros públicos y protegidos de la clase base. Esto se hace mediante el tipo de herencia, que puede ser public, protected o private.

public: Herencia Pública

class Animal {

public:

    void respirar() {}

};

class Perro : public Animal {

    // "respirar" sigue siendo público

};

Es la más común para relaciones del tipo es-un (ej: un perro es un animal). Y queda todo como el padre, los metodos publicos y protejidos siguen publicos y protejidos en el hijo. 

protected: Herencia Protegida

class Perro : protected Animal {

    // "respirar" pasa a ser protegido

};

Esta forma rara vez se usa, pero puede servir para limitar el acceso desde fuera sin perder herencia funcional. Los metodos publicos y protejidos pasan a protejidos en el hijo. 

private: Herencia Privada

class Perro : private Animal {

    // "respirar" pasa a ser privado

};

Es útil cuando querés usar la funcionalidad de la clase base sin exponer su interfaz públicamente. Los metodos publicos y protejidos pasan a privados en el hijo. 

Y si no pongo nada ¿Cuál es el valor por defecto?

El valor por defecto en las clases es private y en los structs public. 

Genéricos en Scala: Covarianza y Contravarianza

Scala es un lenguaje poderoso que combina programación funcional y orientada a objetos. Uno de sus conceptos más sofisticados es el sistema de tipos paramétricos, o genéricos, que permiten escribir código flexible y seguro. 

Los genéricos permiten parametrizar clases, traits y métodos con tipos. Por ejemplo:

class Caja[T](valor: T) {

  def get: T = valor

}

Esta clase puede contener un Int, un String, o cualquier otro tipo.

Imaginemos que tenemos las siguientes clases:

class Animal

class Perro extends Animal

Ahora, supongamos que existe una clase genérica Caja[T]. ¿Debería Caja[Perro] ser un subtipo de Caja[Animal]?

En Scala, la relación de subtipos entre tipos genéricos no se asume automáticamente. Vos decidís explícitamente cómo se comporta con respecto a la varianza.

Scala permite controlar la varianza de un tipo genérico con anotaciones en la declaración del tipo.

Invarianza (sin anotación):

class Caja[T](valor: T)

No hay relación de subtipos entre Caja[Perro] y Caja[Animal].

Covarianza (+T)

class Caja[+T](valor: T)

Caja[Perro] es subtipo de Caja[Animal] si Perro es subtipo de Animal.

Usá covarianza cuando vas a leer datos del tipo genérico, pero no escribir.

Ejemplo:

class ListaCovariante[+A](val cabeza: A)

No podés definir un método como:

def setCabeza(a: A): Unit // ERROR con +A

Porque podría romper la seguridad de tipos.

Contravarianza (-T)

class Procesador[-T] {

  def procesar(t: T): Unit = println("Procesando")

}

Procesador[Animal] es subtipo de Procesador[Perro].

Esto es útil cuando recibís datos del tipo genérico (por ejemplo, funciones o procesadores).

Veamos un ejemplo:

class Animal

class Perro extends Animal

class Gato extends Animal

// Covariante: productor

class CajaProductora[+A](val valor: A)

// Contravariante: consumidor

class Procesador[-A] {

  def procesar(a: A): Unit = println(s"Procesando: $a")

}

Uso:

val perro = new Perro

val gato = new Gato

val caja: CajaProductora[Animal] = new CajaProductora[Perro](perro)

val procesador: Procesador[Perro] = new Procesador[Animal]()

procesador.procesar(perro)

En Scala, los tipos de las funciones son contravariantes en los parámetros y covariantes en el resultado.

val f: Perro => Animal = (a: Animal) => a // válido

¿Por qué? Porque si necesitás una función que acepte Perro, es seguro usar una función que acepte Animal, ya que Animal puede incluir a Perro.

La varianza en Scala te permite expresar con precisión las relaciones de subtipos entre clases genéricas:

• +T (covariante): útil para leer
• -T (contravariante): útil para escribir
• T (invariante): comportamiento por defecto

Comprender este sistema es clave para diseñar APIs robustas, especialmente en programación funcional y colecciones.

Full Stack Open

Le quiero recomendar la página fullstackopen, la cual brinda un curso sobre el desarrollo web moderno. Para no hacerlo tan largo, lo que nos dice esta pagina es lo siguiente: 

¡Aprende React, Redux, Node.js, MongoDB, GraphQL y TypeScript de una sola vez! Este curso te presentará el desarrollo web moderno basado en JavaScript. El enfoque principal es crear aplicaciones de una sola página con ReactJS que usando REST API creadas con Node.js.

Dejo link: https://fullstackopen.com/es/

Covarianza y contravarianza en C++

La covarianza y contravarianza en C++ con templates es un poco más manual que en otros lenguajes como Java o C#, porque C++ no tiene soporte directo para la varianza en plantillas. Pero hay formas de simularla o controlarla explícitamente usando herencia, punteros, referencias, std::variant, std::any, SFINAE y concepts.

Primero: ¿Qué es covarianza y contravarianza?

• Covarianza: cuando un tipo genérico Container<Derived> puede ser tratado como Container<Base>.
• Contravarianza: lo contrario Container<Base> puede ser usado donde se espera Container<Derived>.
• Invarianza: no se permite ninguna conversión.

Las Plantillas en C++ son invariantes, esto no es válido:

template <typename T>

class Caja<T> {};

class Animal {};

class Perro : public Animal {};

Caja<Perro>* cp = new Caja<Perro>();

Caja<Animal>* ca = cp;  //  ERROR: no se permite, son tipos distintos

Y listo, fin del post ... Pero pero sí hay covarianza con punteros y referencias a clases (no templates)

Esto funciona:

class Animal {

public:

    virtual void hablar() {}

};

class Perro : public Animal {

public:

    override void hablar() {}

};

Animal* a = new Perro();  // Anda por Covarianza de punteros

¿Cómo resolver o simular varianza con templates?

Usar herencia con punteros o referencias

template <typename T>

class Caja {

public:

    T* valor;

};

Perro* p = new Perro();

Caja<Perro> c1;

c1.valor = p;

Caja<Animal> c2 = c1;  //  No compila directamente

Podemos hacer funciones que trabajen con T* o T& para aprovechar la covarianza de punteros.

Hacer una jerarquía polimórfica manual

class ICajaBase {

public:

    virtual ~ICajaBase() = default;

};

template <typename T>

class Caja : public ICajaBase {

public:

    T valor;

};

Luego podemos trabajar con ICajaBase* y aplicar RTTI o dynamic_cast.

Usar std::variant o std::any para manejar múltiples tipos

#include <variant>

std::variant<Perro, Gato> animal;

Esto evita plantillas covariantes, pero permite flexibilidad en tiempo de ejecución.

Usar std::enable_if, SFINAE o concepts para limitar compatibilidades

template <typename T>

class Caja {

public:

    static_assert(std::is_base_of<Animal, T>::value, "T debe ser un Animal");

};

En C++, las plantillas son invariantes. pero podemos usar covarianza con punteros y referencias a clases base. Si queremos modelar jerarquías con templates, tenemos que hacerlo manualmente usando herencia, punteros, std::variant o SFINAE.

NativeAOT en .NET

Cuando exploramos el desarrollo moderno en .NET, una de las optimizaciones más atractivas es NativeAOT (Ahead-of-Time Compilation). Esta funcionalidad permite compilar aplicaciones directamente a código nativo antes de que se ejecuten, evitando la compilación Just-In-Time (JIT) y logrando mejoras significativas en el rendimiento.

NativeAOT permite compilar aplicaciones .NET a código máquina nativo al momento del publish, en lugar de hacerlo en tiempo de ejecución (como lo hace el JIT). Esto ofrece beneficios importantes:

• Tiempo de inicio muy rápido (ideal para CLI, microservicios y funciones serverless).
• Menor consumo de memoria, ya que no se necesita el motor JIT ni metadatos innecesarios.
• Sin dependencias externas, se genera un ejecutable autónomo (self-contained).
• Mejor rendimiento predecible, sin pausas por compilación dinámica.

Pero no todo lo que brilla es oro, como desventajas podemos nombrar:

• Mayor tiempo de compilación, ya que el análisis y generación de código nativo lleva más procesamiento.
• Menor compatibilidad con características dinámicas como reflexión, `Assembly.Load`, `Emit`, o serialización automática sin hints.
• Mayor complejidad en configuración: requiere ajustes específicos en el código y/o hints de runtime.
• Tamaño del ejecutable potencialmente mayor, dependiendo del trimming y dependencias.

Agregar la propiedad IsAotCompatible en true en el archivo .csproj del proyecto le indica al SDK de .NET que tu aplicación es compatible con NativeAOT. Esto significa que puede ser compilada a código nativo, pero no activa la compilación AOT automáticamente.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>

    <OutputType>Exe</OutputType>

    <TargetFramework>net8.0</TargetFramework>

    <IsAotCompatible>true</IsAotCompatible>

  </PropertyGroup>

</Project>

La compilación AOT se activa explícitamente con:

dotnet publish -c Release -r win-x64 /p:PublishAot=true

Aunque NativeAOT ofrece muchas ventajas, no es la opción predeterminada por varias razones:

• Compatibilidad: La mayoría de las aplicaciones .NET usan características como reflexión, Assembly.Load, o Emit, que no son compatibles con AOT. 
• Restricciones técnicas: AOT requiere que toda la información esté disponible en tiempo de compilación. Esto implica evitar estructuras dinámicas, y muchas veces obliga a proporcionar hints o metadatos adicionales para que funcione correctamente.
• Tiempo de compilación: Compilar con AOT puede llevar más tiempo, ya que realiza trimming, análisis y generación de código nativo. Esto puede dificultar el ciclo rápido de desarrollo y prueba.
• Tamaño del binario: Aunque AOT puede reducir el runtime necesario, a veces el tamaño del ejecutable final puede ser mayor, dependiendo de las dependencias incluidas.

Entonces ¿Cuándo usar NativeAOT?

Es ideal para:

• Aplicaciones de consola o CLI.
• Microservicios que buscan iniciar rápido y consumir poca memoria.
• Apps en contenedores donde se busca eficiencia.
• Entornos con recursos limitados.
• Funciones serverless (como Azure Functions, AWS Lambda).

NativeAOT es una herramienta poderosa que puede ofrecer mejoras notables de rendimiento y eficiencia, pero requiere ciertas adaptaciones. 

Si lo pensamos bien, en un mundo donde todas las aplicaciones tienen a correr en el cloud utilizando docker, que una aplicación sea nativa y ocupe menos recursos se vuelve más importante y como la multiplataformidad la brinda docker ya no es tan importante. NativeAOT se vuelve indispensable. 

PEP 750: ¡Template Strings aceptadas oficialmente en Python!

El lenguaje Python sigue evolucionando con propuestas que buscan mejorar la legibilidad, la seguridad y la flexibilidad del código. Una de las más recientes incorporaciones al lenguaje es la PEP 750, que introduce un nuevo sistema de plantillas de texto: Template Strings.

Aunque Python ya cuenta con varias formas de interpolar texto (como `str.format()` o f-strings), esta propuesta agrega una forma más estructurada y segura de construir cadenas dinámicas, especialmente útil en contextos donde el contenido proviene del usuario o debe ser validado y separado del código de negocio.

La idea es inspirarse en los template literals de lenguajes como JavaScript, pero con una sintaxis propia y flexible.

Características clave:

• Se introduce un nuevo prefijo de cadena: t"" o t'''...''', al estilo de las f-strings (f"").
• Las expresiones a interpolar deben ser variables ya definidas (sin expresiones arbitrarias como en las f-strings), lo que reduce riesgos de seguridad.
• Pueden ser útiles para escenarios como generación de HTML, SQL, etc., donde conviene tener una separación estricta entre datos y estructura.

nombre = "Emanuel"

edad = 30

mensaje = t"Hola, {nombre}. Tenés {edad} años."

print(mensaje)  # Hola, Emanuel. Tenés 30 años.

A diferencia de las f"" strings, no podés hacer expresiones como edad + 1, lo que previene comportamientos inesperados y hace el código más declarativo.

Las Template Strings están diseñadas con seguridad en mente. En lugar de permitir cualquier expresión de Python dentro de la cadena (como en f""), restringen la interpolación a nombres de variables válidos. Esto es ideal en:

• Aplicaciones web (evitar inyecciones accidentales).
• Motores de plantillas simplificados.
• Contextos educativos o de scripting seguro.

La PEP 750 ya fue aceptada y se espera su inclusión oficial en una versión futura de Python (posiblemente Python 3.13 si todo va bien).

Dejo link: https://peps.python.org/pep-0750/

JEP 463 : Clases Implícitamente Declaradas y Métodos main de Instancia

La Propuesta de Mejora de Java (JEP) 463, titulada "Clases Implícitamente Declaradas y Métodos main de Instancia", introduce en Java 22 una funcionalidad que simplifica la escritura de programas básicos, especialmente útil para principiantes en el lenguaje.

El propósito principal de esta propuesta es permitir que los estudiantes y nuevos programadores escriban sus primeros programas en Java sin necesidad de comprender características avanzadas del lenguaje. Esto se logra permitiendo la declaración implícita de clases y la utilización de métodos main de instancia, eliminando la necesidad de especificar modificadores como public, static y el parámetro String[] args.

Las características Principales son: 

1. Clases Implícitamente Declaradas: Permiten escribir programas sin declarar explícitamente una clase. El compilador asume una clase implícita que envuelve el código proporcionado.

   void main() {

       System.out.println("Hola, mundo!");

   }

En este caso, no es necesario declarar una clase explícita; el compilador lo maneja automáticamente. 

2. Métodos main de Instancia: Permiten que el método main sea un método de instancia en lugar de un método estático. Esto facilita la introducción de conceptos orientados a objetos de manera más natural para los principiantes.

   void main() {

       System.out.println("Hola desde un método main de instancia!");

   }

Aquí, el método main no requiere ser estático, lo que simplifica la estructura del programa inicial. 

Como beneficios podemos nombrar:

• Simplicidad: Reduce la cantidad de código ceremonial necesario para escribir programas simples, facilitando el aprendizaje inicial de Java.
• Progresión Natural: Permite a los estudiantes comenzar con estructuras simples y luego introducir gradualmente conceptos más complejos como clases y métodos estáticos.
• Compatibilidad: Mantiene la compatibilidad con las características existentes de Java, permitiendo una transición suave hacia programas más complejos.

Es importante destacar que esta funcionalidad se introdujo como una característica en vista previa en Java 21 bajo la JEP 445 y se reintrodujo en Java 22 con la JEP 463, incorporando mejoras basadas en la retroalimentación recibida. Como característica en vista previa, está sujeta a cambios en futuras versiones del lenguaje. 

La JEP 463 representa un avance significativo en la accesibilidad del lenguaje Java para nuevos programadores, simplificando la estructura necesaria para escribir programas básicos y facilitando una curva de aprendizaje más amigable. Al permitir la declaración implícita de clases y métodos main de instancia, Java se vuelve más accesible sin comprometer su robustez para desarrollos más complejos.

Dejo link: https://openjdk.org/jeps/463 

Cómo crear un Servicio REST en C++

Aunque C++ no es el primer lenguaje que se nos viene a la cabeza cuando hablamos de servicios web, existen varias bibliotecas que nos permiten construir APIs RESTful de manera sencilla y eficiente. En este post te muestro cómo hacerlo utilizando Crow, una de las librerías más populares para este propósito.

Crow es una microframework para C++ similar a Flask (Python) o Express (Node.js). Es ligera, rápida y permite definir rutas y manejar peticiones HTTP con facilidad.

Vamos a necesitar: 

• Un compilador moderno compatible con C++17 o superior.
• CMake (versión 3.14 o superior).

Si usás vcpkg podés instalar Crow fácilmente:

vcpkg install crow

O podés clonar el repositorio:

git clone https://github.com/CrowCpp/crow.git

Veamos un hola mundo : 

#include "crow_all.h"

int main()

{

    crow::SimpleApp app;

    CROW_ROUTE(app, "/")([](){

        return "¡Hola, mundo desde C++!";

    });

    CROW_ROUTE(app, "/suma/<int>/<int>")([](int a, int b){

        return crow::response(std::to_string(a + b));

    });

    app.port(18080).multithreaded().run();

}

¿Qué hace este código?

Define dos rutas: `/` y `/suma/{a}/{b}`.

Devuelve texto plano como respuesta.

Usa crow::SimpleApp para levantar un servidor en el puerto `18080`.

Compilamos con CMake

cmake_minimum_required(VERSION 3.14)

project(servicio_rest_cpp)

set(CMAKE_CXX_STANDARD 17)

add_executable(servicio_rest main.cpp)

target_include_directories(servicio_rest PRIVATE /ruta/a/crow)

Luego:

mkdir build && cd build

cmake ..

make

./servicio_rest

Y ya podés acceder a http://localhost:18080/.

C++ no se queda atrás cuando se trata de crear servicios REST. Con herramientas como Crow, podés construir APIs eficientes, con alto rendimiento y mantenerte en el ecosistema de C++. Perfecto para integrarse con sistemas existentes o para casos donde el rendimiento es crítico.

Dejo link: 

https://crowcpp.org/master/

JEP 459: Plantillas de Cadenas en Java

La propuesta de Mejora de Java (JEP) 459, titulada "Plantillas de Cadenas", introduce en Java una nueva funcionalidad que permite la creación de cadenas dinámicas de manera más sencilla y segura. Esta característica, presentada como vista previa en Java 22, complementa las literales de cadena y los bloques de texto existentes al combinar texto literal con expresiones embebidas y procesadores de plantillas para producir resultados especializados. 

Objetivos de JEP 459

• Simplificar la escritura de programas Java: Facilita la expresión de cadenas que incluyen valores calculados en tiempo de ejecución.
• Mejorar la legibilidad: Permite una sintaxis más clara al mezclar texto y expresiones, ya sea en una sola línea o en múltiples líneas.
• Incrementar la seguridad: Al componer cadenas a partir de valores proporcionados por el usuario, se mejora la validación y transformación de las plantillas y sus valores embebidos.
• Mantener flexibilidad: Permite que las bibliotecas de Java definan la sintaxis de formato utilizada en las plantillas de cadenas.
• Simplificar el uso de APIs: Facilita la interacción con APIs que aceptan cadenas escritas en lenguajes no Java, como SQL, XML y JSON. 

Las plantillas de cadenas permiten insertar expresiones directamente dentro de cadenas de texto utilizando una sintaxis específica. A continuación, se muestra un ejemplo básico de su uso:

String nombre = "Duke";

String mensaje = STR."Hola, \{nombre}!";

System.out.println(mensaje);

En este ejemplo, `STR` es un procesador de plantillas que evalúa la expresión embebida `\{nombre}` y la reemplaza con su valor correspondiente, produciendo la salida: "Hola, Duke!". 

Java 22 incorpora varios procesadores de plantillas, entre los que se incluyen:

• STR: Realiza interpolación de cadenas, reemplazando cada expresión embebida con su valor correspondiente convertido a cadena.
• FMT: Similar a STR, pero acepta especificadores de formato como los definidos en java.util.Formatter, permitiendo un formateo más detallado.
• RAW`: No procesa automáticamente la plantilla de cadena, útil para crear procesadores de plantillas personalizados.

Es fundamental tener en cuenta que las plantillas de cadenas fueron introducidas como una funcionalidad en vista previa en Java 21 y reintroducidas en Java 22 con JEP 459. Sin embargo, esta característica fue retirada en Java 23 para una revisión y rediseño adicionales, por lo que no está disponible en versiones posteriores.

Aunque actualmente esta característica está en revisión, su implementación futura promete simplificar y asegurar la construcción de cadenas en Java, facilitando la interacción con otros sistemas y mejorando la legibilidad del código.

Dejo link: https://openjdk.org/jeps/459