> Wenn TypeScript-Code nicht mehr in TypeScript geschrieben wird, könnte das Team TypeScript selbst nicht mehr direkt verwenden, was sich langfristig auf die Developer Experience auswirken kann.
Man sagt ja, man isst sein eigenes Hundefutter – also nutzt selbst, was man gebaut hat. Aber bei einer Programmiersprache gibt mir das doch etwas zu denken.
Wenn man allerdings die neuesten Technologien (?) einführen will, wird man nicht selten von JUnit4 ausgebremst, daher habe ich persönlich den kleinen Wunsch, dass auf JUnit5 migriert wird. https://docs.gradle.com/develocity/test-distribution/
Mit junit-vintage-engine lassen sich JUnit4-Tests zwar auch ohne große Änderungen unter JUnit5 ausführen, der Overhead ist jedoch ziemlich hoch. (ungefähr 20 % langsamer)
Als jemand, der irgendwie als Build Engineer für Android-Apps gelandet ist, würde ich dazu Folgendes anmerken..
Build: gradle
Auch wenn es sehr groß oder komplex ist, sollte man gradle verwenden... (blickt in die Ferne)
Für sehr große oder komplexe Projekte laufen derzeit die folgenden Projekte, um die Build-Performance von gradle zu verbessern. Wenn ihr gradle in einem großen Projekt nutzt, ist es sinnvoll, frühzeitig die Migration vorzubereiten.
Ich persönlich finde nicht, dass es einen zwingenden Grund gibt, Architektur-Layer im Build-System offenzulegen.
Bei der App, die ich betreue, legen wir feature-api / feature-impl als Module im Build-System offen.
feature-app :
Datenmodelle oder Interfaces, die mit anderen Modulen verknüpft sind
feature-impl:
die tatsächliche Implementierung des Features
Mit diesem Aufbau wirken sich Code-Änderungen in feature-impl nicht auf andere Module aus, die feature-api referenzieren (Abhängigkeitsisolierung). Das hilft erheblich bei incremental builds und einer höheren build cache hit rate.
Unit-Tests - junit 4
Ich denke, dass hier Googles Entscheidung eine große Rolle gespielt hat.
In letzter Zeit scheinen Dienste, die die Anzahl der Nutzungen oder die Zeit begrenzen, wieder im Trend zu liegen. Ich frage mich aber, ob das nicht wie diese App, die vor einiger Zeit kurz angesagt war und bei der man irgendwie sendungsartig gesprochen hat — ich erinnere mich nicht mehr genau an den Namen — nur kurz aufblitzt und dann wieder verschwindet.
Die Entwicklung der Sprache C# ist zwar nicht zum Stillstand gekommen, aber allzu oft hat man das Gefühl, dass Frameworks auf Basis von C# vernachlässigt werden.
Eine CPU-Auslastung von 100 % ist bei Computern nicht normal,
aber bei Menschen führt eine Arbeitsauslastung von 100 % zu dem Schluss, dass man sich noch mehr anstrengen müsse ...
Hm … als Randbemerkung lässt sich beobachten, dass in den letzten Jahren die meisten Startups auf Flutter setzen, während große Unternehmen wie META und OpenAI nativ entwickeln – ein merkwürdiges Phänomen …
Das sind erfreuliche Nachrichten! Erstaunlicherweise trifft die TypeScript-Sprache von MS, anders als erwartet, wirklich viele überraschende Entscheidungen (?). Aus Sicht von MS wirkt es auch sehr klug, dass es sich dabei fast um ihr erstes Open-Source-Projekt handelt und dass man sich – anders als bei Googles Dart, das JavaScript ersetzen wollte – dafür entschieden hat, JavaScript zu ergänzen. Und auch bei dieser nativen Portierungssprache ist es überraschend, dass man, obwohl es wohl viele eigene Sprachen im Unternehmen geben dürfte, sich für Googles Go entschieden hat.
Ich habe schon erlebt, dass generische Typen mit rekursivem Aufbau so langsam wurden, dass ich zu einer Ausweichlösung greifen musste. Wenn es wirklich 10-mal schneller ist, hoffe ich, dass sich auch solche Bereiche verbessern.
> Wenn TypeScript-Code nicht mehr in TypeScript geschrieben wird, könnte das Team TypeScript selbst nicht mehr direkt verwenden, was sich langfristig auf die Developer Experience auswirken kann.
Man sagt ja, man isst sein eigenes Hundefutter – also nutzt selbst, was man gebaut hat. Aber bei einer Programmiersprache gibt mir das doch etwas zu denken.
Wenn man allerdings die neuesten Technologien (?) einführen will, wird man nicht selten von JUnit4 ausgebremst, daher habe ich persönlich den kleinen Wunsch, dass auf JUnit5 migriert wird.
https://docs.gradle.com/develocity/test-distribution/
Mit
junit-vintage-enginelassen sich JUnit4-Tests zwar auch ohne große Änderungen unter JUnit5 ausführen, der Overhead ist jedoch ziemlich hoch. (ungefähr 20 % langsamer)Als jemand, der irgendwie als Build Engineer für Android-Apps gelandet ist, würde ich dazu Folgendes anmerken..
Auch wenn es sehr groß oder komplex ist, sollte man gradle verwenden... (blickt in die Ferne)
Für sehr große oder komplexe Projekte laufen derzeit die folgenden Projekte, um die Build-Performance von gradle zu verbessern. Wenn ihr gradle in einem großen Projekt nutzt, ist es sinnvoll, frühzeitig die Migration vorzubereiten.
Ich persönlich finde nicht, dass es einen zwingenden Grund gibt, Architektur-Layer im Build-System offenzulegen.
Bei der App, die ich betreue, legen wir feature-api / feature-impl als Module im Build-System offen.
Mit diesem Aufbau wirken sich Code-Änderungen in feature-impl nicht auf andere Module aus, die feature-api referenzieren (Abhängigkeitsisolierung). Das hilft erheblich bei incremental builds und einer höheren build cache hit rate.
Ich denke, dass hier Googles Entscheidung eine große Rolle gespielt hat.
Allerdings basiert das kürzlich veröffentlichte Screenshot-Testing-Plugin auf JUnit5.
Klingt nach Clubhouse, genau daran musste ich auch sofort denken.
In letzter Zeit scheinen Dienste, die die Anzahl der Nutzungen oder die Zeit begrenzen, wieder im Trend zu liegen. Ich frage mich aber, ob das nicht wie diese App, die vor einiger Zeit kurz angesagt war und bei der man irgendwie sendungsartig gesprochen hat — ich erinnere mich nicht mehr genau an den Namen — nur kurz aufblitzt und dann wieder verschwindet.
Oh, was für eine Ehre für die Familie Huh.
Der Traffic wird sich in diesem Zeitraum wahrscheinlich massiv bündeln, daher dürfte eine effiziente Verarbeitung nötig sein.
Ich mache mir Sorgen, dass die Wartung bestehender TypeScript-Codebases später vernachlässigt werden könnte.
Die Entwicklung der Sprache C# ist zwar nicht zum Stillstand gekommen, aber allzu oft hat man das Gefühl, dass Frameworks auf Basis von C# vernachlässigt werden.
Ich teste es gerade, und es fühlt sich irgendwie wie ein Rundum-sorglos-Paket an.
Ähnliche Beiträge tauchen immer wieder auf, aber die menschliche Gier kennt kein Ende, und dieselben Fehler werden wiederholt.
Eine CPU-Auslastung von 100 % ist bei Computern nicht normal,
aber bei Menschen führt eine Arbeitsauslastung von 100 % zu dem Schluss, dass man sich noch mehr anstrengen müsse ...
Hm … als Randbemerkung lässt sich beobachten, dass in den letzten Jahren die meisten Startups auf Flutter setzen, während große Unternehmen wie META und OpenAI nativ entwickeln – ein merkwürdiges Phänomen …
Ja, ich kann aber irgendwie auch die Gefühle der .NET-Entwickler verstehen ...
Das sind erfreuliche Nachrichten! Erstaunlicherweise trifft die TypeScript-Sprache von MS, anders als erwartet, wirklich viele überraschende Entscheidungen (?). Aus Sicht von MS wirkt es auch sehr klug, dass es sich dabei fast um ihr erstes Open-Source-Projekt handelt und dass man sich – anders als bei Googles Dart, das JavaScript ersetzen wollte – dafür entschieden hat, JavaScript zu ergänzen. Und auch bei dieser nativen Portierungssprache ist es überraschend, dass man, obwohl es wohl viele eigene Sprachen im Unternehmen geben dürfte, sich für Googles Go entschieden hat.
Die .NET- und Rust-Entwickler sind ziemlich wütend geworden.
Brother, Firmware-Update erzwingt die Sperre von Drittanbieter-Tintenpatronen für Drucker
Hm, es gibt doch auf der Deno-Seite bereits eine Rust-basierte Toolchain ... warum plötzlich Go?
Ich habe schon erlebt, dass generische Typen mit rekursivem Aufbau so langsam wurden, dass ich zu einer Ausweichlösung greifen musste. Wenn es wirklich 10-mal schneller ist, hoffe ich, dass sich auch solche Bereiche verbessern.
Der Diskussionsthread darüber, warum Go, ist interessant.
https://github.com/microsoft/typescript-go/discussions/411
Es gibt auch vieles, worüber man nachdenken muss...
Ich sehe, dass viele in Punkt 4 abrutschen, und das ist sehr bedauerlich.