Haxe Review: Funktionen und Stärken von Haxe 4

Unser vorheriger Haxe-Review endete mit einem Blick auf das damals kommende Haxe 4. Mit der offiziellen Veröffentlichung von Haxe 4 (und kurz darauf zwei Bug-Patch-Releases – Version 4.0.1 und 4.0.2) ist es Zeit für einen neuen Haxe-Review . Was sind die neuesten Ergänzungen zu dieser aufkeimenden Programmiersprache? Wohin steuert die Programmiersprachen-Community von Haxe? Sind Haxe-Game-Engines immer noch die Hauptstütze?

Haxe Review: Die neuen Funktionen von Haxe 4

Mit mehr als drei Jahren Entwicklungszeit seit der letzten Hauptversion verbessert Version 4 der Programmiersprache Haxe die Makroleistung, die Entwicklererfahrung und die Syntax. Drei seiner Verbesserungen gelten noch als experimentell, sind aber hervorzuheben: das neue JVM-Bytecode-Ziel, Unterstützung für Inline-Markup und Null-Sicherheitsprüfungen.

Das experimentelle JVM-Bytecode-Kompilierungsziel in Haxe 4

Das neue JVM-Bytecode-Target von Haxe 4 macht die Java-Entwicklung über Haxe ein ganzes Stück effizienter, indem es einen großen Kompilierungsschritt einspart: Es gibt keinen zweiten Schritt, bei dem Javas eigener Compiler ( javac ) die Java-Quellcodeausgabe von Haxes Transpiler kompilieren muss.

Diese Kompilierungsmethode mit Haxe 4 entfernt auch vollständig die Abhängigkeit vom Java Developer Kit (JDK) und öffnet die Tür für interaktives Debugging, das in Zukunft implementiert werden soll.

Bis die Mainstream-Version von hxjava mit Haxe 4 kompatibel ist, umfasst die grundlegende Einrichtung die Installation von Haxe und Haxelib und die anschließende Ausführung von haxelib install hxjava 4.0.0-alpha . Damit ist der Entwicklungsablauf einfach:

 # transpile directly to JVM bytecode with Haxe (-D jvm would also work): haxe --main HelloWorld --java jar_output --define jvm # run JVM bytecode with Java: java -jar jar_output/HelloWorld.jar

Da die direkte JVM-Kompilierung in Haxe 4 immer noch experimentellen Status hat, gibt es ein paar Einschränkungen:

• Es gibt einige Android-spezifische Probleme.
• Die Laufzeitperformance ist nicht ganz so gut, auch wenn sie am Ende schneller sein wird als die indirekte Methode.

Nichtsdestotrotz ist es ein bemerkenswerter Schritt in die richtige Richtung für jeden, der Java-basierte Technologien nutzt.

Experimentelle Inline-Markup-Unterstützung in Haxe 4

JSX, jemand? Haxe 4 ermöglicht Inline-Markup, sodass Entwickler beispielsweise HTML direkt im Haxe-Quellcode schreiben können:

 var dom = jsx( <div> <h1>Hello!</h1> <p>This is a paragraph.</p> </div> );

Da jsx() hier eine statische Makrofunktion sein kann, ermöglicht dies einem Projekt, während der Kompilierung zu prüfen, ob das Markup der XML-Spezifikation entspricht, die der Entwickler implementieren möchte. Da die XML-Unterstützung selbst in die Haxe-API integriert ist, kann die Prüfung Xml.parse() nutzen, aber für eine grundlegende „XML-ähnliche“ Parsierbarkeit ist nicht einmal das erforderlich:

 static macro function jsx(expr) { return switch expr.expr { case EMeta({name: ":markup"}, {expr: EConst(CString(s))}): macro $v{"XML MARKUP: " + s}; case _: throw new haxe.macro.Expr.Error("not an xml literal", expr.pos); } }

Die Absicht mit dieser Funktion ist es, Haxe aus der Spielentwicklungsblase zu drängen (obwohl es sicherlich auch dort Verwendung findet). Es ist allgemein genug, dass es auf Compiler-Ebene implementiert wird – daher wird die Haxe-API im obigen Makro nicht benötigt –, aber die Überprüfung auf bestimmte DSLs ist die nächste Frage, die das Compiler-Team und die Community klären müssen.

Experimentelle Nullsicherheit in Haxe 4

Seit der Erfindung der Nullreferenz im Jahr 1965 war das Problem der Nullsicherheit oft der Fluch von Entwicklern in typisierten Nullable-Umgebungen wie der der Programmiersprache Haxe. Aleksandr Kuzmenko schätzt, dass GitHub mehr als 10 Millionen Nullzeiger-Referenzfehler behebt.

Haxe 4 verfügt über integrierte Null-Sicherheitsmakros zur Kompilierzeit, die durch Einfügen einer @:nullSafety -Zeile direkt vor einer bestimmten Definition aktiviert werden können. Es ist in den @:nullSafety(Loose) (Standardeinstellung) und @:nullSafety(Strict) und kann bei Bedarf mit @:nullSafety(Off) deaktiviert werden. Strict Modus durchsucht Funktionsaufrufe nach Feldmutationen, die null zuweisen könnten, selbst in einem sicherheitsdeaktivierten Null-Kontext.

Ruby-Entwickler fragen sich vielleicht, ob der handliche sichere Navigationsoperator ( ?. in Ruby) auf dem Radar ist. Noch nicht, aber wie bei vielen Aspekten der Programmierung in Haxe gibt es dafür ein Makro (beachten Sie, dass es stattdessen !. verwendet).

Entwicklererfahrung (DX) mit Haxe 4: Syntaxzusätze, syntaktischer Zucker und mehr

Die DX-bezogenen Ergänzungen der Haxe-Programmiersprache und die Haxe-IDE-Unterstützung bringen die Haxe-4-Erfahrung an verschiedenen Fronten mindestens auf ein Niveau mit anderen Programmiersprachen. In gewisser Weise versucht Haxe, alles für alle zu sein, aber das Compiler-Team verfolgt einen durchdachten Ansatz, um die nützlichsten Funktionen und Konventionen aus anderen Sprachen zu integrieren.

Das Ergebnis ist, dass sich die Haxe-Programmiersprache und die Standard-API weiterentwickeln, ohne ihre Stabilität, Sensibilität und Kohärenz zu beeinträchtigen. Nicht alles in diesem Haxe-Review wird einem Hype-würdig erscheinen, und genau das ist der Punkt: DX verbessert sich, und dies spricht dafür, einfach auffällige „Features du Jour “ zu jagen.

Es muss jedoch ein Gleichgewicht gefunden werden: Die Änderungen von Haxe werden mit einem Bewusstsein für die Muster vorgenommen, denen andere Sprachen folgen, und Haxe 4 bemüht sich sicherlich, Neuankömmlinge aus populäreren Sprachen anzusprechen.

Neue „Funktionstyp“-Syntax

In diesem Sinne unterstützt Haxe jetzt zwei Hauptarten zur Darstellung von Funktionstypen. Die alte Syntax „schlägt vor, dass Auto-Currying und partielle Anwendung unterstützt werden, aber sie sind es nicht“, so der ursprüngliche Funktionsvorschlag:

 Int -> String -> Void

Die neue Syntax erlaubt benannte Argumente, was DX verbessert:

 (id:Int, name:String) -> Void

Aber abgesehen von DX ist die Verwendung der neuen Syntax von Haxe 4 für Funktionstypen eine gute Angewohnheit, da die alte, minderwertige Syntax in einer zukünftigen Hauptversion entfernt werden könnte.

Syntaktischer Zucker … irgendwie

Vielleicht ist es nicht bahnbrechend, aber die syntaktischen Verbesserungen von Haxe 4 werden sowohl für bestehende Haxe-Entwickler mit bestimmten Entwicklungshintergründen (z. B. ES6) als auch für diejenigen, die von ihnen zum ersten Mal zu Haxe kommen, eine willkommene Neuigkeit sein.

Pfeilfunktionssyntax („short lambda“) wird jetzt unterstützt, was in Haxes Fall mehr oder weniger nur eine Abkürzung für die Eingabe von function und return ist. Schlüsselwert- und Indexwert-Iterationssyntaxen (für Karten bzw. Arrays) werden jetzt ebenfalls unterstützt. Typdeklarationen mit statischen Erweiterungen können nur global eine using -Anweisung verwenden, anstatt sie überall dort zu benötigen, wo die entsprechenden statischen Erweiterungsmethoden verwendet werden.

Enums und Enum-Abstracts haben einige andere Verbesserungen, von denen eine darin besteht, dass letztere aus dem Zuständigkeitsbereich von Makros zu direkter Compiler-Unterstützung übergegangen sind. Andere Features, die auf ähnliche Weise verschoben wurden, umfassen finale Klassen, finale Schnittstellen und externe Felder.

Einige Funktionen, die auf Makros angewiesen sind, blieben auf Makros angewiesen, wurden aber dennoch verbessert. Das Überladen von Operatoren wurde auf Feldsetzer hochgestuft, und Metadaten können jetzt mit Namespaces versehen werden . Trennzeichen wie in @:prefix.subprefix.name .

Die obigen Änderungen als syntaktischen Zucker zu bezeichnen, ist zugegebenermaßen zu stark vereinfacht, aber die Leser können gerne in die ursprünglichen Vorschläge eintauchen, auf die in den Versionshinweisen von Haxe 4 verwiesen wird, wenn sie mehr Details benötigen.

Mehr Haxe 4 DX-Boosts

Während in Haxe bereits interaktives Debugging für verschiedene kompilierte Targets möglich war, ermöglicht das neue eval -Target interaktives Debugging für interpretierten Code. Als einfaches Beispiel können Sie das Projektverzeichnis eines beliebigen Haxe „Hello, World“-Tutorials nehmen und eine Datei mit dem Namen „ whatever-you-want.hxml “ hinzufügen, die so aussieht:

 --main HelloWorld --interp

…und erhalten Sie interaktives Debugging in der VSCode IDE einfach durch:

1. Öffnen des Projektverzeichnisses in VSCode ;
2. Irgendwo einen Haltepunkt hinzufügen; und
3. Drücken Sie F5 und wählen Sie „Haxe Interpreter“ aus der Dropdown-Liste.

Mit dieser Funktion können Sie Makrocode auf die gleiche Weise interaktiv debuggen, selbst wenn Sie tatsächlich für ein bestimmtes Ziel wie java kompilieren (anstatt --interp verwenden). Die einzige Installationsvoraussetzung neben Haxe und VSCode selbst ist die Haxe VSCode-Erweiterung.

IDE-Dienste

Apropos IDEs: Haxe 4 führt ein neues IDE-Dienstprotokoll ein, das bereits in der neuesten VSCode-Haxe-Erweiterung vshaxe genutzt wird. Neben einer erheblichen Leistungssteigerung ermöglicht dies vshaxe, einige äußerst nützliche DX-Verbesserungen bereitzustellen, darunter:

• (Lang erwartete) automatische Importe
• Hover-Hinweise zur automatischen Vervollständigung, die weitere Details anzeigen, z. B. die Beantwortung der Frage „Woher stammt dieses Feld?“
• Sehr gründliche automatische Vervollständigung auf mehrere raffinierte neue Arten, wie erwartete Typvervollständigung, Postfix-Vervollständigung und Überschreibungsvervollständigung
• Optimierungen auf Tastendruck beim Eintippen von Code

Es ist viel einfacher, den Wert dieser über die hervorragenden visuellen Demos aus dem relevanten vshaxe-Änderungsprotokoll zu erkennen. vshaxe mit VSCode ist nicht die einzige Haxe-IDE, die es gibt – HaxeDevelop und Kode Studio sind Haxe-spezifisch, und es gibt Haxe-IDE-Plug-ins für IntelliJ IDEA, Sublime Text, Atom usw. – aber es scheint der Konkurrenz voraus zu sein das neue IDE-Dienstprotokoll von Haxe 4 zu nutzen, dicht gefolgt von IntelliJ-Haxe.

Unicode-Literale

Entwickler, die echte Unicode-String-Literale verwenden möchten, werden dafür in Haxe 4 Unterstützung finden, aber es gibt einige Nuancen, die es zu beachten gilt.

Nur-Lese-Arrays

Die Standard-Haxe-API verfügt jetzt über schreibgeschützte Arrays. Diese sind so einfach zu verwenden wie das Deklarieren einer Variablen vom Typ, z. B. haxe.ds.ReadOnlyArray<Int> , wonach der Versuch, Werte festzulegen, zu pushen oder auszulesen, zu verschiedenen Compilerfehlern führt. Fügen Sie der Deklaration das Schlüsselwort final hinzu, und die Neuzuweisung des Arrays selbst wird ebenfalls nicht zugelassen.

Call-Site-Inlining

Call-Site-Inlining ist eine neue Haxe-Sprachfunktion, die Entwicklern eine feinkörnige Kontrolle darüber ermöglicht, wo Funktionen eingebettet werden, was nützlich ist, wenn häufig aufgerufene Funktionen optimiert werden, bei denen der Gesamtkompromiß zwischen Größe und Leistung ansonsten eine Lose-Lose-Entscheidung sein könnte.

Dies sind lohnende Ergänzungen zu der bereits hervorragenden Programmiersprache Haxe. Was bauen die Entwickler in der Haxe-Community jetzt auf, wo Haxe 4 herausgekommen ist?

Jenseits von Haxe Game Engines: Webentwicklung mit Haxe 4

Die Benutzerbasis von Haxe wurde in der Vergangenheit von Spieleprogrammierern dominiert. Aber es gibt viele Beispiele für den Einsatz von Haxe – in großem Umfang – in anderen Segmenten, wie Business-Stacks, mobilen Apps und dem Web, sowohl für die Front- als auch für die Back-End-Entwicklung.

Zu diesem Zweck liefert Haxe 4 regenerierte HTML-Externs, was bedeutet, dass die js.html -Standard-API von Haxe mit der breiteren Web-API, wie sie MDN definiert, auf den neuesten Stand gebracht wurde, sowie Fehler behoben und fehlende APIs hinzugefügt wurden. (Zum Beispiel enthält Haxe 4 jetzt die Push-API.)

In Juraj Kirchheims Vortrag Weaving a Better Web with Haxe weist er auf Beispiele von Haxe-basierten Weblösungen hin, die in einer Unternehmensumgebung um Größenordnungen effizienter – aber auch robuster – sind.

Er spricht sich auch gegen den Rails-Architekturansatz (in Bezug auf die Ordnerhierarchie) aus, aber Entwickler, die ein vollständiges Web-Framework a la Rails bevorzugen, können immer noch eines finden. In anderen Fällen kann es für Entwickler von Vorteil sein, die Quelle eines vollständigen Webprojekts zu überprüfen. In diesem Fall lohnt es sich, einen Blick auf das öffentliche Repo für Giffon zu werfen, eine Crowd-Gifting-Plattform, die Haxe 4 unterstützt. Quelle Haxe-Bibliotheken wie das JavaScript-spaltende Haxe Modular, das generische thx.core und seine Schwesterbibliotheken sowie das ehrwürdige Haxe-Web-Toolkit Tinkerbell unterstützen alle bereits Haxe 4. Ebenso die plattformübergreifende UI-Lösung HaxeUI, die jedoch einen Webkontext unterstützt zielt auf einen viel breiteren Anwendungsbereich ab, einschließlich der Entwicklung von Geschäfts- und Desktop-Apps; Insbesondere hat es sich bis zur neuen Veröffentlichung der Haxe-Sprache stetig weiterentwickelt.

Web, Spiele, Unternehmen … unabhängig von der Plattform und dem App-Geschmack, auf die ein Entwicklungsteam – selbst ein Ein-Mann-Team – abzielt, müssen sich Haxe-Entwickler schließlich mit der Verwaltung von Abhängigkeiten auseinandersetzen. Eine hilfreiche Ressource für Haxe-Entwickler sind die Folien aus dem Vortrag von Adam Breece, Scaling well with other.

Haxe als beste Programmiersprache für Spiele

Gibt es überhaupt eine einzige „beste“ Sprache für die Spieleentwicklung? Es ist eine subjektive Frage, über die leicht hitzige Debatten geführt werden können. Größer, als man allein aufgrund der Größe seiner Community erwarten würde, ist Haxes Erfolg im Bereich der Spieleentwicklung sicherlich kein Zufall. Joe Williamson gibt in einem Interview über den Gewinn des Ludum Dare 45 Game Jam im Jahr 2019 einen Einblick, warum dies der Fall sein könnte, und dies scheint sich mit Haxe 4 fortzusetzen.

Der ursprüngliche Schöpfer von Haxe, Nicolas Cannasse, verwendet Haxe 4 bereits in der Produktion mit Northgard von Shiro Games. Motion Twin verwendet Haxe 4 auch in der Produktion für Dead Cells. Beide Spiele haben Zehntausende von positiven Bewertungen auf Steam und sind sowohl für PCs (Win, Mac und Linux) als auch für Konsolen erhältlich – ein wirklich beeindruckendes Ergebnis, wenn man bedenkt, dass beide Spiele kleinere Entwicklungsteams haben, aber eine Benutzerbasis in Millionenhöhe. Dead Cells hat sogar eine iOS-Version, mit einer Android-Version auf ihrem Radar.

In Bezug auf die Bibliothek halten mehrere große Haxe-Game-Engines definitiv mit den Änderungen von Haxe 4 Schritt. Zu den mit Haxe 4 kompatiblen Engines gehören Kha (und ein Teil der vielen Engines, die darauf aufbauen – z. B. Armory), HaxeFlixel und seine Hauptabhängigkeit OpenFL, NME und Heaps – natürlich, da Northgard und Dead Cells diese verwenden. HaxePunk arbeitet auch an der Kompatibilität mit Haxe 4; In einem Fall wurde eine Bibliothek, Nape, gegabelt, um mit Haxe 4 zu arbeiten.

Einige Entwickler stellen auch ihre eigenen Engines her, anstatt eine der vielen bereits vorhandenen zu verwenden. Zum Beispiel Kirill Poletaev, der detailliert beschreibt, wie und warum er seine eigene 3D-Haxe-Game-Engine geschrieben hat. Da diese Engine intern ist, macht es Sinn, dass es sich um ein Beispiel für ein Projekt handelt, das noch nicht auf Haxe 4 migriert wurde.

Haxe 4: Fortsetzung des reibungslosen Fortschritts einer exzellenten Toolchain

Da Haxe einen so breiten Nutzen hat, werden die wichtigsten Funktionen von Haxe 4 je nach Entwickler variieren, so dass diese Haxe-Überprüfung keinesfalls erschöpfend ist. Einige der Änderungen von Haxe 4 fehlen oben, darunter:

• Das Hinzufügen einer ES6-Ausgabe für das JavaScript-Ziel
• Das Entfernen von Funktionen (von denen einige noch über die hx3compat Bibliothek verfügbar sind) und Zielen (PHP5 und bald AS3)
• CLI-Flags werden konsistenter mit gängigen Tools gemacht ( -lib -using .hxml Dateien müssen beispielsweise in -L oder --library werden).
• Abgesehen davon, dass final jetzt ein Schlüsselwort ist (das daher nicht als Variablenname verwendet werden kann), sind auch operator und overload neu reservierte Schlüsselwörter.

Es gab auch einige bahnbrechende Änderungen, aber das sind so wenige, dass viele aktiv gepflegte Bibliotheken sich nicht einmal die Mühe machen, die Kompatibilität mit Haxe 4 explizit anzukündigen – im Allgemeinen soll die Migration von Haxe 3 ziemlich einfach sein. Schließlich ist eines der Ziele von Haxe Stabilität inmitten des Jonglierens mit der Unterstützung einer großen Anzahl von Zielplattformen, und Haxe 4 enttäuscht hier nicht.

Was ist mit neuen Benutzern? Am Ende muss der Leser entscheiden, ob Haxe die beste Programmiersprache für Spiele ist, ob das Haxe-Ökosystem die robustesten Bibliotheken für die Webentwicklung bietet oder ob Haxe-spezifische Tools das sinnvollste DX für einen bestimmten Workflow bieten. Zumindest ist Haxe in vielen Bereichen weiterhin ein brauchbarer Konkurrent und bietet so etwas wie einen geheimen Vorteil für fast jeden Entwickler.

Weiterführende Literatur: Entwickler, die neu bei Haxe sind, könnten an einem ziemlich neuen Haxe-Tutorial von John Gabriele und auch an den Versionshinweisen von Haxe 4.1.0 und Haxe 4.1.1 interessiert sein.