Lanzamiento de Elixir 1.17: tipos de teoría de conjuntos en patrones, duraciones, OTP 27

 (elixir-lang.org)
1 puntos por GN⁺ 2024-06-13 | 1 comentarios | Compartir por WhatsApp
  • Se agrega una función de tipos graduales de teoría de conjuntos que infiere tipos a partir de patrones y emite advertencias en tiempo de compilación, para encontrar fallas y bugs en bases de código sin modificar el software existente
  • Las nuevas advertencias de tipos actualmente se enfocan en atom y map/struct, y detectan coincidencias de patrones y accesos a campos con claves inexistentes, llamadas a funciones que no son módulos, llamadas incorrectas a funciones anónimas, comparaciones estructurales entre structs, comparaciones de tipos sin intersección, patrones binarios incorrectos, rescue de excepciones no definidas, entre otros
  • El typechecker actualmente infiere tipos solo a partir de patrones dentro de la misma función; el análisis entre guards y límites de funciones se agregará en próximos lanzamientos
  • Se agrega soporte para Erlang/OTP 27 y se deja de dar soporte a Erlang/OTP 24; se recomienda migrar a Erlang/OTP 26 o superior, incluido Windows
  • El soporte para WERL, la interfaz gráfica de terminal de Erlang para Windows, se eliminará en Elixir v1.18
  • Se agregan el nuevo tipo de dato Duration y Date.shift/2, que permiten desplazar fechas, horas y date times según una duración; en DateTime se gestionan los cambios de zona horaria y el Daylight Saving Time
  • Se agrega Kernel.to_timeout/1, que normaliza duraciones e integers al valor de timeout usado por varias APIs como Process y GenServer
  • La funcionalidad de process label de Erlang/OTP 27 puede usarse en Elixir con Process.set_label/1, y Logger formatea reportes de gen_statem e incluye el process label de Erlang/OTP 27 en eventos de logger
  • Se agregan Keyword.intersect/2,3, el nuevo profiler de Mix mix profile.tprof y el guard Kernel.is_non_struct_map/1 para reducir la trampa de que %{} también haga match con structs
  • Con la incorporación de mix profile.tprof, mix profile.cprof y mix profile.eprof pasan a estar sujetos a soft-deprecation

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-06-13
Opiniones en Hacker News

  • En los últimos años, el ecosistema de Elixir realmente se está convirtiendo en la solución más simple para muchísimos usos.
    Con Phoenix y LiveView, el desarrollo web es rápido y agradable; con NX/Axon/Bumblebee, inteligencia artificial; con Membrane, streaming y procesamiento de audio y video; con Commanded, CQRS y event sourcing; con Nerves, creación de dispositivos embebidos; y con LiveView Native, que está en desarrollo, hasta apps móviles.
    Colas, pipelines y procesamiento por lotes también se pueden manejar según el caso con funciones integradas o con GenStage, Broadway y Oban.
    Aun así, personalmente la función clave es IEx, el REPL de Elixir. Poder interactuar directamente con código en desarrollo o en producción, inspeccionarlo y depurarlo es algo que te cambia la vida.
    Que ahora se sumen tipos es la última pieza del rompecabezas para darnos más confianza en el código que desplegamos.

    • Además de eso, ExUnit hace que las pruebas sean extremadamente fáciles, el gestor de paquetes Hex simplemente funciona bien, y FLAME permite escalar procesos a otra computadora con casi una sola línea de código.
      Ecto permite trabajar con bases de datos SQL de forma funcional; todavía no sé bien cómo debería ver a los ORM, pero si con unas cuantas consultas componibles pude eliminar el 90% del SQL, lo considero un éxito.
      Después de sufrir durante meses con despliegues, tiempo de actividad, errores de segmentación, tiempos de paquetes, etc., trasladé el servidor web y la capa de datos a Elixir + Phoenix, y ahora está mucho mejor probado, es más fácil de razonar, la escalabilidad es confiable y el despliegue fue sencillo.
      Gracias a convención sobre configuración, con Phoenix pude arrancar ridículamente rápido, mucho más rápido que con FastAPI. Siento que debí haberlo hecho hace meses.
      Ahora estoy entrenando modelos con Nx y probando Bumblebee/Livebook, mientras agrego presence y funciones live a la app casi gratis.
    • Para hacerle un poco de promoción a LiveView Native: no solo permite crear apps móviles, sino también para escritorio, relojes, TV y Apple Vision Pro.
      Todo usando los mismos conceptos, rendimiento y comodidad de desarrollo de LiveView.
    • Viniendo de lenguajes con un sistema de tipos estático potente y útil, esto es lo que más se extraña, así que estoy mirando Gleam con curiosidad.
      Creo que me costaría volver a algo como Erlang o Elixir.
    • El REPL de Elixir es de primer nivel, y estoy de acuerdo en que es la verdadera killer feature del lenguaje.
      Lo extraño muchísimo cada vez que escribo código en otros lenguajes, sobre todo cuando me pagan por programar.
      Tener un buen REPL reduce mucho la fricción habitual al programar. En vez de ejecutar toda la app para tantear un fragmento de código problemático, puedes ir construyendo ideas poco a poco y probarlas en el momento.
      La biblioteca estándar de Elixir también es excelente, y acceder a la documentación desde el REPL es muy fácil, lo que ayuda mucho a mantener el flujo. Cuando programo en Elixir, rara vez abro el navegador para buscar respuestas a preguntas pequeñas, porque normalmente puedo encontrarlas sin salir del REPL.
      Eso también me incentiva a escribir buenas cadenas de documentación en mi propio código.
      Lo mejor es que puedes correr el REPL junto con el código en ejecución. Incluso cuando tienes que ejecutar la app, puedes dejarla corriendo y, en el entorno de desarrollo, manipular datos reales e inspeccionar el estado interno. En otros stacks eso es imposible o requiere un depurador.
      Espero que, con las nuevas funciones relacionadas con tipos, las herramientas mejoren aún más.
      A eso se suma la diversión y la potencia del paradigma funcional, formas sólidas de manejar mutabilidad y estado, y sin tener que lidiar con la sintaxis de LISP. Personalmente, es un lenguaje que toca todas las notas correctas, y por eso me encanta.
    • ¿No tienen muchos otros lenguajes cosas así? Ruby tiene IRB.
      ¿IEx hace algo que IRB no haga?

  • En los últimos años, los equipos de Elixir y Erlang han hecho un trabajo realmente bueno, y tampoco se puede dejar de lado el trabajo de quienes escriben bibliotecas y libros.
    Nunca había esperado tanto un lanzamiento. Estuve siguiendo por un tiempo los commits de Elixir y OTP, y siento que Elixir/Erlang definitivamente tomó impulso.

  • Estoy usando Elixir para el backend de un proyecto paralelo y Remix en el frontend; trabajar en el backend es muy cómodo y productivo.
    Reconozco la productividad de LiveView, pero en mi caso tenía que manejar conexiones de red inestables, así que, como era de esperarse, la experiencia con LiveView no fue buena.
    Me gustaría que, en la mente de los desarrolladores, Elixir se separara un poco de LiveView. Incluso usándolo solo como un backend de API simple, sin LiveView ni canales en tiempo real, Elixir es realmente divertido.

    • Me gusta muchísimo Elixir, lo uso para casi todo, y LiveBook se volvió mi lugar por defecto para empezar a crear software de juguete.
      Pero con LiveView no puedo. Es bastante difícil de entender y tiene muchas trampas bajo los pies. Por ejemplo, a veces hay que acordarse de manejar las comprobaciones de autenticación tanto en el pipe_through del router como en el callback on_mount de LiveView. Ver [0].
      El solo hecho de que la frase anterior no signifique nada para un desarrollador que recién llega a Phoenix y LiveView ya es prueba suficiente de que LiveView no debería ser el enfoque predeterminado.
      Crea una curva de aprendizaje muy empinada donde no hace falta. Elixir/Phoenix en sí es fácil.
      Creo que, para un desarrollador que está aprendiendo Elixir/Phoenix desde cero, lo correcto es empezar con las dead views de Phoenix al estilo MVC y luego leer “Elixir in Action” para aprender los fundamentos de OTP. Ese libro es fácil, me abrió los ojos y cambió casi toda mi forma de programar.
      Y recién después conviene pasar a LiveView.
      [0]: https://hexdocs.pm/phoenix_live_view/security-model.html#liv...
    • Si ejecutas mix phx.new con el flag —no-live, puedes usar Phoenix sin LiveView. En proyectos existentes también se puede quitar manualmente.
    • Las respuestas que han llegado hasta ahora no están entendiendo el punto central.
      El problema no es de conocimiento técnico ni de valores predeterminados de instalación, sino de percepción entre los desarrolladores. Demasiada gente asocia Elixir y el resto de su ecosistema primero con LiveView, y pasa de largo ignorando el resto del ecosistema.
      Elixir es mucho más que eso, e incluso Phoenix es más grande que LiveView.
      Se pueden construir perfectamente aplicaciones en Elixir productivas y costo-eficientes incluso sin LiveView, y hasta sin Phoenix. Elegir Elixir para el backend debería ser más común de lo que es hoy, aunque también entiendo los lugares comunes y miedos que llevan a elegir otra cosa.

  • Estoy construyendo mi startup con un stack 100% full-stack en Elixir, y es la mejor tecnología que he usado hasta ahora.
    Sigo evangelizando a mis amigos técnicos más serios sobre lo buena que es.
    Ahora solo quisiera que RabbitMQ y su cliente corrieran en OTP 27. Tengo ganas de actualizar.

    • Me da curiosidad saber qué estás haciendo que te hace sentir que Elixir encaja justo en el punto ideal frente a otras tecnologías.
    • RabbitMQ es bastante sólido; ¿estás teniendo problemas como fugas de rendimiento?
      Nosotros llevamos años usando inicio de sesión de clientes con certificados SSL y estamos muy satisfechos con su estabilidad.

  • No alcanzan las palabras buenas para hablar de Elixir y Phoenix. Y cuando lleguen los tipos, será todavía mejor.
    Se escucha mucho sobre BEAM y su potencia, pero por experiencia se puede avanzar muchísimo antes de tener que pensar en esa parte del stack. Phoenix la abstrae de forma excelente, así que obtienes los beneficios sin esfuerzo.
    Un ejemplo es Oban. Dentro de Postgres obtienes, casi gratis, trabajos en segundo plano potentes, flexibles y fáciles de usar con código Elixir. Es realmente impresionante.
    Recomiendo probarlo.

    • Estaría totalmente de acuerdo si no fuera por LiveView.
      Por LiveView y la obsesión de marketing a su alrededor, gente que de otro modo habría podido ignorar OTP por más tiempo se topa con OTP muy temprano en su recorrido, quizá desde su primera ruta de controlador.
      Escribir flujos de LiveView robustos y probarlos bien es tan complejo intelectualmente como escribir un GenServer con estado, con varios flujos no lineales y distintos puntos de entrada call/cast.
      LiveView usa otros términos y tiene pequeñas capas de conveniencia como async assigns, pero mecánicamente es literalmente un GenServer. Creo que entender bien esto es importante para usarlo de forma efectiva.
      Oban me encanta, y lo extraño profundamente en otros ecosistemas.

  • Como comentario aparte, ¿alguien ha probado elixir-desktop [1]? Es un paquete de wxWidgets + LiveView, así que se parece bastante a una app de Electron.
    En [2], Wojtek Mach explica cómo el equipo de Elixir creó Livebook Desktop. Habla de cómo empezó el proyecto, de bugs sutiles que encontraron al crear la app para macOS, de las limitaciones de wxWidgets en Windows y de varios detalles de implementación.
    Me gustaría que el equipo de Elixir lanzara oficialmente algo como elixir-desktop basado en Livebook. Es decir, ofrecer un proyecto de plantilla oficial que bifurque el repositorio de Livebook para generar aplicaciones de escritorio basadas en LiveView.
    Hoy Livebook se distribuye como ejecutables para Windows y Mac. ¿Qué tal si siguieran el mismo enfoque para que los desarrolladores puedan distribuir ejecutables independientes, como con Electron?
    También conozco LiveView Native [3], pero creo que va en otra dirección.
    [1] https://github.com/elixir-desktop/desktop-example-app
    [2] https://www.youtube.com/watch?v=Kiw6eWKcQbg
    [3] https://native.live/

  • Espero con ganas el día en que desaparezca la excusa de que no tiene tipos, que ha frenado la popularización de Elixir

  • Durante 10 años he leído aquí historias geniales sobre Elixir, y también me gusta el lenguaje
    Pero hace unos años dejé de buscar trabajos en Elixir, porque los sueldos seguían pareciéndome más bajos que en los lenguajes mainstream
    Puede que sea el lenguaje que más quiero usar, pero para mí el sueldo y un producto genial son más importantes que el stack tecnológico, así que quizá en la práctica no pueda hacerlo. Aun así, sigue siendo divertido seguirlo de lejos

    • Como desarrollador de Elixir, me sorprende escuchar que los sueldos son más bajos que en los lenguajes mainstream
      Me da curiosidad si estás buscando en Estados Unidos o en otra región
    • Los sueldos suelen ser consistentemente más altos que en los stacks mainstream. En parte, porque la mayoría de las vacantes de Elixir buscan ingenieros sénior

  • Una buena función de este lanzamiento es la incorporación de get_in/1, que funciona con structs. Por ejemplo, se puede usar como get_in(struct.foo.bar)
    Si foo devuelve nil, no se lanza una excepción al acceder a bar

    • Ya era posible en versiones anteriores de Elixir, pero la sintaxis era ruidosa
      Para niveles que no fueran mapas comunes, se necesitaba Access.key, así:
      get_in(struct, [Access.key(:foo), :bar])

  • Esta era la última pieza que quería. También espero con ganas los siguientes pasos
    Por lo demás, según mi criterio, este lenguaje está funcionalmente 100% completo

    • La última vez que miré Elixir, parecía haber consenso en que “al final también hay que hacer Erlang”
      ¿Sigue siendo así, o ya no hace falta bajar a Erlang?