Erlang/OTP 29.0

 (erlang.org)
1 Punkte von GN⁺ 5 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Der SSH-Daemon deaktiviert standardmäßig die Shell- und Exec-Dienste, sodass authentifizierte Nutzer ohne explizite Konfiguration keinen beliebigen Erlang-Code ausführen können
  • Beim Start des SSH-Daemons wird auch das SFTP-Subsystem nicht mehr standardmäßig aktiviert, wodurch die sicheren Standardeinstellungen verbessert werden
  • Das Attribut -unsafe wurde hinzugefügt, um unsichere Funktionen zu kennzeichnen, und der Compiler erzeugt standardmäßig Warnungen für Aufrufe von Funktionen, die in Erlang/OTP als immer unsicher bekannt sind
  • xref kann Aufrufe unsicherer Funktionen und undokumentierte Funktionen finden; außerdem wird die Filterung des Attributs ignore_xref nun von xref selbst verarbeitet
  • In den Standard-SSL-Einstellungen ist x25519mlkem768 nun die bevorzugte Schlüsselaustauschgruppe, und der Standard-Schlüsselaustauschalgorithmus von SSH wurde ebenfalls auf mlkem768x25519-sha256 geändert, das ML-KEM-768 und X25519 kombiniert
  • Im Standard-Codepfad des Erlang-Systems wurde das aktuelle Arbeitsverzeichnis . von der ersten an die letzte Position verschoben, wodurch sich die Lade-Reihenfolge ändert
  • 32-Bit-Erlang/OTP-Builds für Windows werden nicht mehr bereitgestellt
  • Native Records aus EEP-79 wurden implementiert und gelten in Erlang/OTP 29 als experimentelle Funktion
  • Das Guard-BIF is_integer/3, Comprehensions mit mehreren Werten auf Basis von EEP 78 sowie Variablenbindung innerhalb von Comprehensions über die Funktion compr_assign wurden hinzugefügt
  • Der Compiler fügt standardmäßig Warnungen für catch, den Export von Variablen außerhalb von Unterausdrücken, and/or sowie Match-Alias-Muster wie {a,B} = {X,Y} hinzu und bietet jeweils Optionen zum Deaktivieren
  • Veraltete Guard-Tests sollen in Erlang/OTP 30 aus der Sprache entfernt werden; die bestehenden Warnungen zur Verwendung obsoleter Guards bleiben bestehen
  • Mit io_ansi lassen sich ANSI-/Virtual-Terminal-Sequenzen an das Terminal ausgeben, und mit ct_doctest können Beispiele in Erlang-Moduldokumentationen und Dokumentdateien getestet werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 5 시간 전
Hacker-News-Kommentare

  • Die Verbesserungen sehen ziemlich gut aus. Dass der SSH-Daemon jetzt standardmäßig deaktiviert ist und SFTP ebenfalls standardmäßig deaktiviert ist, ist sicherheitstechnisch eine gute Änderung.
    Das Modul io_ansi sieht auch ziemlich cool aus. Derzeit gibt es bei Erlang nicht gerade viele überzeugende Optionen, wenn man komplexe Kommandozeilen-Anwendungen bauen will, daher dürfte es künftig sehr helfen, wenn das in der Standardbibliothek landet. Dass fwrite auf natürliche Weise zwischen Nodes funktioniert, ist genau die Art von Vorteil, die man von Erlang erwartet.
    Die Ergänzung von Native Records ist ebenfalls interessant. In Elixir fühlt es sich derzeit je nach Situation so an, als würden Records, Tupel und Maps durcheinander verwendet, daher bin ich gespannt, wie das künftig eingesetzt wird. Wie im EEP gesagt wird, werden bestehende Records wohl nicht vollständig abgeschafft, aber es wirkt wie eine erhebliche Verbesserung.
    https://www.erlang.org/doc/apps/ssh/ssh.html
    https://www.erlang.org/docs/29/apps/stdlib/io_ansi.html
    https://github.com/erlang/eep/pull/81

    • Ich glaube nicht, dass der SSH-Daemon jemals automatisch aktiviert oder gestartet wurde. Die Formulierungen der beiden Punkte sind unterschiedlich, aber gemeint ist offenbar, dass die aufgeführten Komponenten beim Start des SSH-Daemons nicht mehr standardmäßig mitgestartet werden.
      Der SSH-Daemon folgt nun dem Prinzip secure by default, da Shell- und Exec-Services standardmäßig deaktiviert sind. Wenn man sie nicht ausdrücklich konfiguriert, wird verhindert, dass authentifizierte Nutzer beliebigen Erlang-Code ausführen können.
      Auch das SFTP-Subsystem wird beim Start des SSH-Daemons nicht mehr standardmäßig aktiviert.

  • Für alle, die sich fragen, wofür OTP in Erlang/OTP steht: Ursprünglich ist das ein Paket aus Bibliotheken und Prinzipien, mit dem sich hochzuverlässige und fehlertolerante Anwendungen für den Telekommunikationsbereich standardisiert entwickeln lassen.
    Es lohnt sich, kurz die Einleitung der „OTP Design Principles“ zu lesen.
    https://www.erlang.org/doc/system/design_principles.html

    • OTP = Open Telecom Platform

  • Wenn eure Produktions-App noch unter 29 läuft, könnte es sinnvoll sein, so schnell wie möglich auf diese Version oder die neueste Patch-Version zu aktualisieren. Ich habe gerade in Produktion ausgerollt, und ein automatischer Sicherheitsscan hat 2 CRITICAL CVEs mit Datumsangaben zwischen Februar und Mai 2026 sowie mehrere Einträge mit hohem Risiko gefunden.

    • Gibt es eine Liste?

  • Ich frage mich, ob überhaupt noch jemand Erlang für neue Projekte nutzt.
    Ich weiß, dass es hier viele Elixir-Fans gibt, aber ich meine reines Erlang.
    Falls ihr noch Erlang verwendet: Warum bevorzugt ihr es gegenüber Elixir?

    • Ja, sogar dieses Jahr. Neue IoT-Arbeit auf Basis von AtomVM, ein in Erlang geschriebener Applikationsserver und ein TUI-Framework, an dem noch gearbeitet wird.
      Elixir bringt mir gegenüber Erlang keinen praktischen Vorteil. Sicher, es hat seine Stärken, aber Erlang passt einfach besser zu meiner Denkweise. Ich würde das Lernen oder gegenseitige Helfen auch gern eher wie ein soziales Treffen angehen, finde aber nicht so recht die passende Gruppe dafür.

  • Kann jemand die internen Strukturen erklären?

  • Ich bin gespannt, wie sich Records im Ökosystem einordnen werden.

    • Ich wollte schon sagen: „Records gibt es doch seit Jahrzehnten?“, aber dann habe ich das Changelog gelesen.
      Interessant. Ich frage mich, ob es irgendwann eine Welt geben wird, in der Elixir Maps zu native records kompiliert.

  • Weiß jemand, ob WhatsApp noch auf Erlang basiert?

    • Ja.
      Sie verwenden Erlang schon seit den frühen 2010er-Jahren, und ungefähr damals hat die Tech-Branche erfahren, dass WhatsApp mit etwa 30 Ingenieuren mehr als 400 Millionen aktive Nutzer unterstützt.
      Ich hatte damals einen ihrer Ingenieure kontaktiert, und als ich noch in den USA lebte, hat er mir per E-Mail freundlich einige Fragen beantwortet. Später haben wir sogar zusammen Kaffee getrunken, und wir stehen bis heute in Kontakt.
      Man kann sagen, dass Erlang noch immer ein wichtiger Bestandteil von WhatsApp ist.
    • Nach dem Vortrag auf der Code BEAM Europe 2025 ist das ziemlich wahrscheinlich: https://www.youtube.com/watch?v=tC435RGwRCI
    • Ich weiß es nicht aus erster Hand, aber ich bin 2019 weggegangen, und die öffentlichen Erlang-bezogenen Repositories von WhatsApp sind immer noch aktiv. Soweit ich weiß, hat sich Erlang auch nicht im gesamten Meta-Konzern verbreitet, daher gäbe es wenig Grund, weiterhin Erlang-Arbeit zu machen, falls WhatsApp davon weggegangen wäre.
    • Ja. Ein früherer Mitarbeiter von mir arbeitet jetzt dort.
    • Ja. Sie nutzen Erlang, und Rust nimmt ebenfalls allmählich zu.

  • Unterstützung für das Attribut -unsafe hinzugefügt, also genau der richtige Zeitpunkt, alles in Rust neu zu schreiben /s

  • Ich weiß wirklich nicht, wer überhaupt Erlang nutzt. Ich habe Rails verwendet und dann Phoenix ausprobiert, aber damit war es viel schwieriger, irgendetwas zu erreichen.
    Ich verstehe den Hype um Phoenix nicht.
    Für Einzelentwickler ist Rails wahrscheinlich das produktivste System für Web-Apps. LLMs schreiben auch sehr gut Ruby-on-Rails-Code. Obwohl das Python-Trainingskorpus riesig ist, schreiben sie nach meiner Erfahrung deutlich besser Rails als Django.
    Experimentelle Apps schreibe ich in Rails, und wenn sie stabil werden, schreibe ich sie in Go neu. Wenn der Umfang der App noch unklar ist, verbraucht direktes Entwickeln in Go viel mehr Tokens, während Rails dafür sehr effizient ist.
    Heutzutage braucht man oft nicht einmal mehr React oder Angular; in Rails nutze ich Hotwire und in Go HTMX.
    Selbst das Erlang-Forum verwendet Discourse, das in Rails geschrieben ist.

    • Ich schreibe seit 2016 hauptberuflich Elixir-Apps. Meine Kunden sind sehr zufrieden damit, keine Abstürze zu sehen. Tatsächlich haben alle Anwendungen, die ich in den letzten zehn Jahren in Produktion ausgerollt habe, 100 % Uptime erreicht. Hardware-, Betriebssystem- und Netzwerkausfälle, die außerhalb meiner Kontrolle liegen, ausgenommen.
      Es wäre gut, den Blick etwas zu weiten.
    • Rails ist meiner Meinung nach höchstens am ersten Tag schneller als Phoenix, wenn man die Entwicklungsgeschwindigkeit misst. Danach stößt man auf implizite Logik, Dinge wie method_missing und verbringt mehr Zeit damit, zu verstehen, wie etwas funktioniert.
      Elixir/Phoenix ist in dieser Hinsicht expliziter und dadurch bei langfristiger Wartung, also nach der ersten Woche, viel angenehmer. Es gibt keinen versteckten Zustand, man muss nicht herumrätseln, woher ModuleName.method(params) kommt, und man muss nichts vorbereiten, um die Methode auszuführen — man übergibt einfach die richtigen Argumente. Der Nachteil ist nur, dass die sofort verfügbaren Paketbibliotheken kleiner sind.
    • Willst du mal raten, was Ruby Discord verwendet?
    • Phoenix ist vor allem wegen OTP, Channels und LiveView interessant. Ich glaube allerdings nicht, dass LiveView 2026 meine Wahl wäre, und wenn man solche Funktionen nicht braucht, ist es möglicherweise weniger attraktiv.
      Ecto ist auch nicht schlecht.
      Claude Code schreibt sehr guten Elixir-Code.
      Überraschenderweise ist man mit oder ohne LLM produktiver, wenn man Technologien nutzt, die man bereits kennt.
    • Es hat eine gewisse absolute Ironie, zu schreiben: „Wenn der Umfang der App noch unklar ist, verbraucht direktes Entwickeln in Go viel mehr Tokens, während Rails dafür sehr effizient ist.“ Damit gibst du nach all dem Gerede letztlich zu, dass du den Code gar nicht selbst schreibst.