Elixir 1.17 veröffentlicht: mengentheoretische Typen für Patterns, Durations, OTP 27

 (elixir-lang.org)
1 Punkte von GN⁺ 2024-06-13 | 1 Kommentare | Auf WhatsApp teilen
  • Graduelle mengentheoretische Typen leiten Typen aus Patterns ab und geben Warnungen zur Compile-Zeit aus; damit lassen sich Defekte und Bugs in Codebases finden, ohne bestehende Software zu ändern
  • Die neuen Typwarnungen konzentrieren sich derzeit auf Atoms und Maps/Structs und erkennen Pattern Matching auf nicht vorhandene Keys sowie Feldzugriffe, Aufrufe von Nicht-Modul-Funktionen, fehlerhafte Aufrufe anonymer Funktionen, strukturelle Vergleiche zwischen Structs, Vergleiche nicht überlappender Typen, fehlerhafte Binary-Patterns und das Rescuen undefinierter Exceptions
  • Der Typechecker leitet Typen derzeit nur aus Patterns innerhalb derselben Funktion ab; Analysen über Guards und Funktionsgrenzen hinweg sollen in künftigen Releases hinzukommen
  • Unterstützung für Erlang/OTP 27 wurde hinzugefügt, die Unterstützung für Erlang/OTP 24 wurde eingestellt; die Migration auf Erlang/OTP 26 oder neuer wird empfohlen, einschließlich unter Windows
  • Die Unterstützung für WERL, die grafische Erlang-Terminaloberfläche für Windows, soll in Elixir v1.18 entfernt werden
  • Der neue Datentyp Duration und Date.shift/2 wurden hinzugefügt, sodass sich Datumsangaben, Zeiten und DateTimes anhand einer Duration verschieben lassen; bei DateTime werden Zeitzonenänderungen und Daylight Saving Time berücksichtigt
  • Kernel.to_timeout/1 wurde hinzugefügt, um Durations und Integer auf Timeout-Werte zu normalisieren, die in verschiedenen APIs wie Process und GenServer verwendet werden
  • Die Process-Label-Funktion aus Erlang/OTP 27 ist in Elixir über Process.set_label/1 nutzbar; Logger formatiert gen_statem-Reports und nimmt Erlang/OTP-27-Process-Labels in Logger-Events auf
  • Keyword.intersect/2,3, der neue Mix-Profiler mix profile.tprof sowie der Guard Kernel.is_non_struct_map/1 wurden hinzugefügt, um den Stolperstein zu reduzieren, dass %{} auch Structs matcht
  • Mit der Einführung von mix profile.tprof werden mix profile.cprof und mix profile.eprof soft-deprecated

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-06-13
Meinungen auf Hacker News

  • In den letzten Jahren ist das Elixir-Ökosystem für wirklich viele Anwendungsfälle zur einfachsten Lösung geworden.
    Mit Phoenix und LiveView ist Webentwicklung schnell und angenehm; mit NX/Axon/Bumblebee geht KI, mit Membrane Audio-/Video-Streaming und -Verarbeitung, mit Commanded CQRS und Event Sourcing, mit Nerves der Bau eingebetteter Geräte und mit dem in Entwicklung befindlichen LiveView Native sogar Mobile Apps.
    Queues, Pipelines und Batch-Verarbeitung lassen sich je nach Bedarf ebenfalls mit Bordmitteln oder mit GenStage, Broadway und Oban handhaben.
    Für mich persönlich ist die Kernfunktion dennoch IEx, Elixirs REPL. Direkt mit Code in Entwicklung oder Produktion interagieren zu können, hineinzuschauen und zu debuggen, ist lebensverändernd.
    Dass jetzt Typen dazukommen, ist das letzte Puzzleteil, das uns noch mehr Vertrauen in den Code gibt, den wir deployen.

    • Ergänzend dazu macht ExUnit Tests extrem einfach, der Hex-Paketmanager funktioniert einfach, und FLAME erlaubt es, Prozesse mit nahezu einer einzigen Codezeile auf andere Rechner zu skalieren.
      Ecto ermöglicht es, SQL-Datenbanken auf funktionale Weise zu behandeln. Ich weiß immer noch nicht, wie ich ORMs grundsätzlich einordnen soll, aber wenn man mit ein paar kombinierbaren Queries 90 % des SQL loswird, sehe ich das als Erfolg.
      Nachdem wir monatelang mit Deployment, Uptime, Segmentation Faults, Paketzeiten und Ähnlichem gekämpft hatten, haben wir Webserver und Datenschicht auf Elixir + Phoenix umgezogen. Jetzt ist alles deutlich besser getestet, leichter nachvollziehbar, verlässlich skalierbar und einfacher zu deployen.
      Dank Convention over Configuration konnte man mit Phoenix absurd schnell loslegen, viel schneller als mit FastAPI. Ich denke, wir hätten das schon vor Monaten tun sollen.
      Im Moment trainiere ich Modelle mit Nx, probiere Bumblebee/Livebook aus und füge der App Presence- und Live-Funktionen praktisch kostenlos hinzu.
    • Um LiveView Native kurz anzupreisen: Man kann damit nicht nur Mobile Apps bauen, sondern auch für Desktop, Watch, TV und Apple Vision Pro.
      Alles nutzt weiterhin die Konzepte, Performance und Entwicklerfreundlichkeit von LiveView.
    • Aus der Perspektive von jemandem, der aus Sprachen mit einem starken und nützlichen statischen Typsystem kommt, ist genau das die größte Lücke, weshalb ich Gleam mit Interesse beobachte.
      Ich glaube, es wäre schwer, wieder zu etwas wie Erlang oder Elixir zurückzugehen.
    • Elixirs REPL ist erstklassig, und ich stimme zu, dass es das echte Killer-Feature der Sprache ist.
      Immer wenn ich Code in anderen Sprachen schreibe, besonders wenn ich fürs Programmieren bezahlt werde, vermisse ich es sehr.
      Ein gutes REPL reduziert die typische Reibung beim Programmieren erheblich. Statt die ganze App zu starten, um an einem problematischen Codefragment herumzustochern, kann man Ideen schrittweise aufbauen und sofort ausprobieren.
      Auch die Elixir-Standardbibliothek ist hervorragend, und der Zugriff auf Dokumentation im REPL ist sehr einfach, was enorm hilft, im Flow zu bleiben. Wenn ich in Elixir programmiere, öffne ich selten den Browser, um kleine Fragen zu recherchieren, weil ich die Antwort meist finde, ohne das REPL zu verlassen.
      Dadurch werde ich auch dazu angehalten, in meinem eigenen Code gute Docstrings zu schreiben.
      Noch besser ist, dass man das REPL zusammen mit laufendem Code betreiben kann. Selbst wenn die App laufen muss, kann man sie einfach laufen lassen und in der Entwicklungsumgebung Live-Daten manipulieren und internen Zustand untersuchen. In anderen Stacks ist das unmöglich oder erfordert einen Debugger.
      Ich erwarte, dass die Werkzeuge mit den neuen Typ-Funktionen noch besser werden.
      Dazu kommen der Spaß und die Stärke des funktionalen Paradigmas, robuste Methoden für den Umgang mit Veränderlichkeit und Zustand – und man muss keine LISP-Syntax ertragen. Für mich persönlich trifft diese Sprache alle richtigen Töne, deshalb mag ich sie wirklich sehr.
    • Haben andere Sprachen nicht auch viel davon? Ruby hat IRB.
      Macht IEx irgendetwas, was IRB nicht kann?

  • In den letzten Jahren haben das Elixir- und das Erlang-Team wirklich großartige Arbeit geleistet, und die Arbeit der Bibliotheks- und Buchautorinnen und -autoren darf man ebenfalls nicht vergessen.
    Ich habe mich noch nie so sehr auf ein Release gefreut. Ich habe eine Zeit lang Elixir- und OTP-Commits verfolgt, und es fühlt sich eindeutig so an, als hätten Elixir/Erlang richtig Schwung bekommen.

  • Ich nutze Elixir für das Backend eines Nebenprojekts, das Frontend ist Remix, und die Arbeit am Backend ist äußerst angenehm und produktiv
    Die Produktivität von LiveView erkenne ich an, aber in meinem Fall musste ich instabile Netzwerkverbindungen handhaben, daher war die LiveView-Erfahrung erwartungsgemäß nicht gut
    Ich wünschte, Elixir würde sich in den Köpfen der Entwickler etwas stärker von LiveView lösen. Auch nur als simples API-Backend ohne LiveView oder Echtzeit-Channels macht Elixir wirklich Spaß

    • Ich mag Elixir wirklich sehr und nutze es für fast alles; LiveBook ist für mich zum Standardort geworden, an dem ich anfange, Spielzeug-Software zu bauen
      Mit LiveView komme ich aber nicht so gut zurecht. Es ist ziemlich schwer zu verstehen und hat viele Fallstricke. Zum Beispiel muss man Authentifizierungsprüfungen manchmal sowohl im pipe_through des Routers als auch im on_mount-Callback von LiveView im Kopf behalten und behandeln. Siehe [0]
      Allein die Tatsache, dass dieser Satz für einen Entwickler, der Phoenix und LiveView zum ersten Mal sieht, keinerlei Bedeutung hat, ist Beweis genug dafür, dass LiveView nicht der Standardweg sein sollte
      Es erzeugt dort eine sehr steile Lernkurve, wo sie nicht nötig ist. Elixir/Phoenix selbst ist einfach
      Wenn ein Entwickler Elixir/Phoenix neu lernt, halte ich es für richtig, zuerst Phoenix Dead Views im MVC-Stil zu verwenden und danach „Elixir in Action“ zu lesen, um die OTP-Grundlagen zu lernen. Das Buch war leicht verständlich, augenöffnend und hat fast meine gesamte Art zu programmieren verändert
      Und erst danach sollte man zu LiveView übergehen
      [0]: https://hexdocs.pm/phoenix_live_view/security-model.html#liv...
    • Wenn man mix phx.new mit dem Flag —no-live ausführt, kann man Phoenix ohne LiveView nutzen. Auch aus bestehenden Projekten lässt es sich manuell entfernen
    • Die bisherigen Antworten verfehlen den Kern
      Das Problem ist keine Frage von technischem Wissen oder Installations-Defaults, sondern eine Frage der Wahrnehmung unter Entwicklern. Zu viele Menschen denken bei Elixir und dem restlichen Ökosystem zuerst an LiveView und gehen am übrigen Ökosystem achtlos vorbei
      Elixir ist viel mehr als das, und selbst Phoenix ist größer als LiveView
      Man kann auch ohne LiveView, und natürlich auch ohne Phoenix, produktive und kosteneffiziente Elixir-Anwendungen bauen. Elixir sollte im Backend häufiger gewählt werden als heute, aber ich verstehe auch die verbreiteten Vorstellungen und Ängste, die zu anderen Entscheidungen führen

  • Ich baue mein Startup als 100 % Elixir Fullstack auf, und es ist die beste Technologie, die ich bisher verwendet habe
    Ich erzähle meinen ernsthaft technikaffinen Freunden ständig, wie gut es ist
    Jetzt wäre es wirklich schön, wenn RabbitMQ und sein Client unter OTP 27 laufen würden. Ich möchte upgraden

    • Ich bin neugierig, woran du arbeitest, dass du das Gefühl hast, Elixir passt genau an dieser Stelle besser als andere Technologien
    • RabbitMQ ist ziemlich robust; hast du Probleme wie Performance-Leaks?
      Wir verwenden seit Jahren Client-Logins über SSL-Zertifikate und sind mit der Stabilität sehr zufrieden

  • Über Elixir und Phoenix kann man gar nicht genug Gutes sagen. Wenn jetzt noch Typen dazukommen, wird es noch besser
    Man hört viel über die BEAM und ihre Stärke, aber meiner Erfahrung nach kann man sehr lange kommen, bevor man über diesen Teil des Stacks nachdenken muss. Phoenix abstrahiert das hervorragend, sodass man die Vorteile ohne Aufwand bekommt
    Ein Beispiel ist Oban. Man bekommt nahezu kostenlos mächtige, flexible und leicht zu nutzende Background-Jobs als Elixir-Code innerhalb von Postgres. Wirklich beeindruckend
    Ich empfehle, es auszuprobieren

    • Ohne LiveView würde ich vollständig zustimmen
      Wegen LiveView und der Marketing-Fixierung darum herum stoßen Menschen, die OTP sonst länger nicht hätten kennen müssen, sehr früh auf ihrer Reise damit zusammen, vielleicht schon ab der ersten Controller-Route
      Einen robusten LiveView-Flow zu schreiben und gut zu testen ist intellektuell so komplex wie das Schreiben eines stateful GenServers mit mehreren nichtlinearen Flows und verschiedenen call/cast-Einstiegspunkten
      LiveView verwendet andere Begriffe und hat kleine Komfortschichten wie async assigns, aber mechanisch ist es buchstäblich ein GenServer. Ich denke, es ist wichtig, das gut zu verstehen, um es effektiv zu nutzen
      Oban liebe ich wirklich und vermisse es in anderen Ökosystemen schmerzlich

  • Nebenbei: Hat jemand elixir-desktop [1] ausprobiert? Es ist ein Bundle aus wxWidgets + LiveView und damit einer Electron-App ziemlich ähnlich
    In [2] erklärt Wojtek Mach, wie das Elixir-Team Livebook Desktop gebaut hat. Er behandelt, wie das Projekt begonnen hat, subtile Bugs, die beim Bau der macOS-App entdeckt wurden, Einschränkungen von wxWidgets unter Windows und diverse Implementierungsdetails
    Es wäre schön, wenn das Elixir-Team auf Basis von Livebook offiziell etwas wie elixir-desktop veröffentlichen würde. Also etwa ein offizielles Template-Projekt, bei dem man das Livebook-Repository forkt und daraus eine LiveView-basierte Desktop-Anwendung erzeugt
    Livebook wird derzeit als ausführbare Datei für Windows und Mac verteilt. Wie wäre es, denselben Ansatz zu verfolgen, damit Entwickler wie bei Electron eigenständige ausführbare Dateien verteilen können?
    LiveView Native [3] kenne ich auch, sehe es aber als eine andere Richtung
    [1] https://github.com/elixir-desktop/desktop-example-app
    [2] https://www.youtube.com/watch?v=Kiw6eWKcQbg
    [3] https://native.live/

  • Ich freue mich auf den Tag, an dem die Ausrede es gibt keine Typen, die der Verbreitung von Elixir im Weg stand, verschwindet

  • Seit zehn Jahren lese ich hier tolle Geschichten über Elixir, und ich mag die Sprache auch.
    Aber die Suche nach Elixir-Jobs habe ich vor ein paar Jahren aufgegeben, weil die Gehälter weiterhin niedriger wirkten als bei Mainstream-Sprachen.
    Es könnte die Sprache sein, die ich am liebsten verwenden würde, aber für mich sind Gehalt und ein spannendes Produkt wichtiger als der Tech-Stack, sodass es in der Praxis vielleicht nichts wird. Trotzdem macht es weiterhin Spaß, sie aus der Ferne zu verfolgen.

    • Als Elixir-Entwickler klingt es für mich überraschend, dass die Gehälter niedriger sind als bei Mainstream-Sprachen.
      Ich frage mich, ob du in den USA suchst oder in einer anderen Region.
    • Die Gehälter liegen durchweg eher höher als bei Mainstream-Stacks. Das liegt teilweise daran, dass die meisten Elixir-Stellen nach Senior Engineers suchen.

  • Eine gute Neuerung in diesem Release ist die Ergänzung von get_in/1, das mit Structs funktioniert. Man kann zum Beispiel get_in(struct.foo.bar) schreiben.
    Wenn foo nil zurückgibt, löst der Zugriff auf bar keine Exception aus.

    • Das war auch in früheren Elixir-Versionen möglich, aber die Syntax war umständlich.
      Für Ebenen, die keine normalen Maps sind, brauchte man Access.key, etwa so:
      get_in(struct, [Access.key(:foo), :bar])

  • Das ist das letzte Puzzlestück, das ich mir gewünscht habe. Ich bin gespannt auf die nächsten Schritte.
    Ansonsten ist diese Sprache nach meinem Maßstab funktional zu 100 % vollständig.

    • Als ich mir Elixir zuletzt angesehen habe, schien der Konsens zu sein: „Am Ende muss man auch Erlang können.“
      Ist das immer noch so, oder muss man nicht mehr auf Erlang heruntergehen?