Express-Autor TJ verabschiedet sich von Node.js und macht sich auf den Weg zu Go_node.js

Zuallererst ist dies ein Artikel, der aus TJs Farewell Node.js übersetzt wurde, nachdem ich diesen Artikel gelesen hatte, aber ich bin mit einigen Ansichten des Autors nicht einverstanden, zum Beispiel mit dem Paket von Node Register ist einer seiner vielen Vorteile, aber in diesem Aspekt mangelt es Go etwas. Aufgrund meiner persönlichen Einschränkungen habe ich beim Übersetzen viele Dinge nicht verstanden. Ich habe auch den Blog des Autors und Stackoverflow besucht, um einige Fragen zu stellen und Antworten zu erhalten. Es gibt immer noch viele Unvollkommenheiten in der Übersetzung, und ich hoffe, Sie können einige Hinweise bekommen.

PS. Als Neuling in Node.js möchte ich TJ für seine harte Arbeit danken und eine gute Reise wünschen.

Text:

Lebewohl Node.js

Node.js-Bereich verlassen

Ich habe lange genug mit Node.js in der Produktion gekämpft, und jetzt, da mir die Arbeit zumindest im Moment keinen Spaß mehr macht, ist dies leider mein offizieller Abschied. Noch wichtiger ist, dass ich Betreuer brauche.

Node ist in mancher Hinsicht großartig, aber es ist nicht das richtige Tool für die Art von Software, an der ich mich heutzutage interessiere. Ich habe weiterhin vor, Node für die Website zu verwenden, aber wenn Sie daran interessiert sind, Projekte zu pflegen, hinterlassen Sie einfach einen Kommentar mit Ihrem Github-Benutzernamen, npm-Benutzernamen und Projektnamen, um mir Bescheid zu geben. Normalerweise verlange ich nur, dass Sie die vorhandene API nicht vollständig ändern. Wenn Sie dies wirklich tun möchten, ist es besser, ein neues Projekt zu starten.

Koa ist ein Projekt, das ich weiterhin pflegen werde. (Mit Co und Freunden)

Die Geschichte vom Heiligen Gral

Ich habe C schon immer geliebt, aber jeder, der in der C-Entwicklung arbeitet, weiß, dass es wertvoll, aber fehleranfällig ist. Es ist schwer, die Wahl einer Sprache im Arbeitsalltag zu rechtfertigen, weil sie nicht gerade die schnellste für den Job ist. Einfachheit wird auch immer gelobt, aber ohne jede Menge Vorlagen kommt man nicht weit.

Je mehr ich mich mit der Entwicklung verteilter Systeme befasse, desto mehr frustriert mich der Trend, dass die Knotenleistung höher ist als die Verfügbarkeit und Robustheit. In der letzten Woche habe ich ein relativ großes verteiltes System in Go umgeschrieben, um es robuster, leistungsfähiger und einfacher zu warten zu machen. Da synchroner Code im Allgemeinen eleganter und einfacher zu entwickeln ist, weist er eine bessere testbare Abdeckung auf.

Ich sage nicht, dass Go der Heilige Gral ist, es ist nicht perfekt, aber für viele Sprachen, die es heute gibt, ist Go für mich eine hervorragende Antwort. Da immer mehr dieser Sprachen der „nächsten Generation“ wie Rust und Julia ihre Nische finden und ausgereift sind, bin ich sicher, dass wir weitere großartige Lösungen haben werden.

Persönlich bin ich von der GO-Sprache aufgrund ihrer Iterationsgeschwindigkeit sehr begeistert. Ich war sehr gespannt darauf, Version 2.0 zu erreichen, und laut den Nachrichten, die ich gehört habe, hatten sie keine Angst und haben das Original kaputt gemacht. Ich würde es lieben, wenn es wahr wäre, vor allem, weil ich glaube, dass es bestehende Dinge schnell zerstören sollte, wenn es wirklich gut für die Sprache ist. Aber ich bin auch kein Softwareriese, der viele Systeme betreibt. :D

Herausgeber: Ich muss einige der Einsendungen an die Mailingliste falsch interpretiert haben; sie waren zu keinem Zeitpunkt bestrebt, bahnbrechende Änderungen vorzunehmen. @enneff

Warum gehen?

Wenn Node für Sie funktioniert und Sie sich keine Sorgen machen müssen, ist es immer noch ein großartiges Tool. Aber wenn Sie etwas stört, vergessen Sie nicht, über Ihren Tellerrand hinauszugehen und zu sehen, was über den Tellerrand hinausgeht – schon in den ersten Stunden nach der Entwicklung eines Produkts mit Go war ich begeistert.

Noch einmal: Ich sage nicht, dass Go die absolut beste Sprache ist und man sie verwenden muss. Aber es ist für sein Alter sehr ausgereift und stark. (Ungefähr als ich im gleichen Alter wie Node war). Typ-Refactoring macht Spaß und ist einfach, die von Go bereitgestellten Job- und Debugging-Tools sind großartig und die Community hat sehr strenge Vorschriften zu Dokumentation, Formaten, Benchmarks und API-Design.

Da ich so sehr an die extreme Modularität von Node gewöhnt war und Rubys verrottete Standardbibliothek kennengelernt hatte, fand ich die Standardbibliothek schrecklich, als ich zum ersten Mal von Go hörte. Nachdem ich mich eingehender mit dieser Sprache beschäftigt hatte, wurde mir klar, dass die meisten Standardbibliotheken in dieser Phase sehr notwendig sind, wie z. B. Komprimierung, JSON, IO, gepufferte IO, String-Operationen usw. Die meisten dieser APIS sind gut definiert und leistungsstark. Es ist einfach, ganze Programme zu schreiben, indem man einfach diese Standardbibliotheken verwendet.

Go-Pakete von Drittanbietern

Die meisten Go-Bibliotheken sehen ähnlich aus und der Großteil des Codes von Drittanbietern, den ich bisher verwendet habe, ist von hoher Qualität, was in Node schwer zu finden ist, da JavaScript Entwickler mit unterschiedlichen Qualifikationsniveaus in den Geltungsbereich lockt.

Für Go-Pakete gibt es kein Registrierungscenter, sodass Sie normalerweise 5 oder 6 gleiche Pakete gleichzeitig sehen. Dies kann manchmal zu Verwirrung führen, hat aber den interessanten Nebeneffekt, dass Sie jedes Paket sorgfältig prüfen müssen, um zu entscheiden, welches die beste Lösung ist. Bei Node gibt es normalerweise kanonische Pakete wie „redis“, „mongodb-native“ oder „zeromq“, also bleiben Sie hier stehen und schließen einfach, dass sie die besten sind.

Wenn Sie verteilt arbeiten, werden Sie die beeindruckenden Parallelitätsbasisdatentypen von Go als sehr hilfreich empfinden. Mit Generatoren in Node können wir etwas Ähnliches erreichen, aber meiner Meinung nach sind Generatoren nur die halbe Miete. Ohne unabhängige Fehlerbehandlung ist der Berichtsstapel immer noch im besten Fall banal. Wenn diese Lösungen gut funktionieren, möchte ich nicht drei Jahre warten, bis sich die Community neu organisiert.

Meiner Meinung nach ist die Fehlerbehandlung von Go hervorragend. Node ist insofern großartig, als man jeden Fehler berücksichtigen und entscheiden muss, was zu tun ist. Der Knoten schlägt jedoch fehl bei:

Sie können Rückrufe wiederholt durchführen

Es kann sein, dass Sie überhaupt keine Rückrufe durchführen und sich in einem instabilen Zustand verlieren (wenn Sie beispielsweise vergessen, einen Fehlerbehandlungsrückruf zu übergeben, verschluckt Node den Fehler beim Auftreten eines Fehlers ohne Rückmeldung)

Möglicherweise erhalten Sie standardmäßige Fehler

Emittenten erhalten möglicherweise mehrere falsche Ereignisse

Das Vergessen der falschen Ereignisbehandlung wird alles ruinieren

Oft unsicher, was falsch gemacht werden muss

Fehlerbehandlung ist sehr überflüssig

Rückrufe sind scheiße
Wenn in Go mein Code endet, endet er und Sie können die Anweisung nicht erneut ausführen. In Node ist dies undefiniert. Man könnte annehmen, dass ein Programm vollständig ausgeführt wird, bis eine Bibliothek versehentlich mehrmals einen Rückruf aufruft oder die Handler nicht ordnungsgemäß löscht und eine erneute Ausführung des Codes verursacht. Es ist ziemlich schwierig, diese Gründe im tatsächlichen Produktionscode zu finden. Warum also sollte man sich die Mühe machen? Andere Sprachen bereiten einem diesen Schmerz nicht.

Knoten der Zukunft

Ich hoffe immer noch, dass Node gut abschneidet und viele Leute viel in es investieren, es hat wirklich großes Potenzial. Ich denke, Joyent und das Team müssen sich auf die Benutzerfreundlichkeit konzentrieren – Leistung ist bedeutungslos, wenn Ihre Anwendung fragil und schwierig zu debuggen, umzugestalten und zu entwickeln ist.

Die Tatsache, dass wir in 4-5 Jahren immer noch diesen vagen Fehler „Fehler: getaddrinfo EADDRINFO“ haben werden, verrät uns, wo die Entwicklungsprioritäten von Node liegen. Verständlicherweise übersieht man diese Dinge leicht, wenn man sich auf den Aufbau des Kerns des Systems konzentriert. Ich denke, dass Benutzer immer wieder ihre Meinung zu solchen Dingen geäußert haben, ohne irgendwelche Ergebnisse zu sehen. Normalerweise erhalten wir eine Handvoll Antworten auf Behauptungen, dass das, was wir haben, bereits perfekt ist. In der Praxis ist dies nicht der Fall.

Streams werden unterbrochen, Rückrufe sind nicht einfach zu verwenden, Fehler sind unklar und Tools sind nicht einfach zu verwenden. Es gibt Community-Vorschriften, aber diese fehlen im Vergleich zu Go. Trotzdem verwende ich Node möglicherweise weiterhin für einige spezifische Aufgaben, wie zum Beispiel das Erstellen von Webseiten oder einige verstreute APIs oder Prototypen. Wenn Node einige seiner grundlegenden Probleme beheben kann, hat es eine Chance, relevant zu bleiben, aber das Argument für Leistung statt Verfügbarkeit geht nicht weit, wenn es eine Alternative gibt, die sowohl höhere Leistung als auch höhere Verfügbarkeit bietet.

Wenn die Node-Community beschließt, Generatoren zu übernehmen und sie in einem sehr zentralen Teil von Node zu implementieren und Fehler ordnungsgemäß zu verbreiten, besteht die Möglichkeit, dass darauf verwiesen werden kann. Dies wird die Verfügbarkeit und Robustheit von Node drastisch verbessern.

Die gute Nachricht ist, dass ich vor einiger Zeit mit den tollen und talentierten Leuten gesprochen habe, die den Kerncode zu StrongLoop beisteuern. Sie verfolgen einen klaren Ansatz, indem sie auf die Reaktionen der Entwickler auf die Plattform hören und planen, den richtigen Weg zur Behebung dieser Probleme zu finden, um die Zusammenarbeit mit Node in Zukunft einfacher zu gestalten. Ich bin mir nicht sicher, wie der Konflikt um die gleichzeitige Entwicklung von Kernteilen durch mehrere Unternehmen enden wird, aber ich hoffe, dass sich die entwicklerorientierte Seite durchsetzen wird.

Dies soll kein persönlicher Angriff sein, es gibt viele wirklich talentierte Leute, die mit oder an der Spitze von Node arbeiten, aber das interessiert mich nicht mehr. Ich hatte eine tolle Zeit in der Node-Community und habe einige wirklich interessante Leute kennengelernt.

Die Moral der Geschichte lautet: Lassen Sie sich nicht von Ihrem eigenen Kreis einschränken! Sehen Sie, was anderswo verfügbar ist, und vielleicht haben Sie wieder Spaß am Programmieren. Es gibt so viele großartige Lösungen, dass ich den Fehler gemacht habe, zu lange damit zu warten, sie auszuprobieren!