Zunächst einmal ist dies ein Artikel, der aus dem Abschiedsnoten von TJ übersetzt wurde. Nach dem Lesen dieses Artikels habe ich in der Tat einige Auswirkungen erlitten, aber ich stimme einigen Ansichten des Autors nicht zu. Zum Beispiel denke ich, dass das Paketregister von Node.js einer der vielen Vorteile ist, aber in dieser Hinsicht fehlt es leicht. Aufgrund der persönlichen Ebene verstehe ich bei der Übersetzung nicht viele Dinge. Ich ging auch zum Blog und Stackoverflow des Autors, um einige Fragen zu stellen, um Antworten zu erhalten. Es gibt immer noch viele Dinge, die in der Übersetzung nicht vorhanden sind, und ich hoffe, einen Standpunkt zu bekommen.
Ps. Als Anfänger von Node.js, dank TJ für seine Bemühungen und den ganzen Weg gehen.
Text:
Verabschieden Sie sich von node.js
Verlassen des Reiches node.js
Ich habe lange genug in Produktion gekämpft. Noch wichtiger ist, ich brauche einen Betreuer.
Node ist in gewisser Weise wirklich großartig, aber es ist schließlich kein geeignetes Tool für die Art von Software, an der ich mich in letzter Zeit interessiert habe. Ich habe immer noch vor, Node als Website zu verwenden. Wenn Sie jedoch an einem Projekt interessiert sind, hinterlassen Sie einfach eine Nachricht, um Ihren Github -Benutzernamen, den NPM -Benutzernamen und den Projektnamen aufzuschreiben, um mich mitzuteilen. Normalerweise frage ich nur, dass Sie Ihre 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 aufrechterhalten werde. (Mit CO und Freunden)
Die Geschichte des Heiligen Grals
Ich habe C immer geliebt, aber jeder, der in der C -Entwicklung arbeitet, weiß, dass es wertvoll ist, aber anfällig für Fehler. Es ist schwierig, die Auswahl der Sprache in der täglichen Arbeit zu beweisen, da es nicht gerade der schnellste Job ist. Einfachheit ist auch der Grund, warum es immer gelobt wurde, aber Sie werden ohne viele Vorlagen nicht weit gehen.
Da mehr Menschen an der Entwicklung verteilter Systeme teilnehmen, hat mich der Entwicklungstrend der Knotenleistung über Benutzerfreundlichkeit und Robustheit frustrierter gemacht. In der vergangenen Woche habe ich ein relativ großes verteiltes System in GO umgeschrieben, das robust ist, besser abschneidet und leicht zu warten ist und aufgrund der allgemeinen Schönheit und einfacher zu entwickelner Synchroncode eine bessere Testabdeckung hat.
Ich sage nicht, dass Go ist ein heiliger Gral, es ist nicht perfekt, aber Go ist eine hervorragende Antwort für mich für viele Sprachen, die heute existieren. Da immer mehr dieser Sprachen der nächsten Generation wie Rust und Julia ihren eigenen Platz finden und reif sind, werden wir sicher mehr großartige Lösungen haben.
Persönlich bin ich sehr aufgeregt über Go wegen seiner Iterationsgeschwindigkeit. Ich freue mich sehr zu sehen, dass sie unbedingt Version 2.0 erreichen möchten, und laut den Nachrichten, die ich gehört habe, haben sie keine Angst davor, die ursprünglichen großartigen Dinge zu brechen. Wenn es wahr ist, bin ich glücklich, mehr, weil ich glaube, dass ich, wenn es für diese Sprache wirklich von Vorteil ist, schnell aufschlüsseln sollte, was bereits da ist. Aber ich bin auch kein Software -Riese, der viele Systeme ausführt. :D
Bearbeitet von: Ich muss einige Versandlisten für Einreichung falsch interpretiert haben, und sie sind nicht bestrebt, zu jeder Zeit einige destruktive Änderungen vorzunehmen. @enneff
Warum gehen?
Wenn der Knoten für Sie funktioniert und Sie sich keine Sorgen machen müssen, ist dies immer noch ein großartiges Werkzeug. Aber wenn Sie etwas stört, vergessen Sie nicht, aus Ihrer Schachtel zu springen und zu sehen, was noch außerhalb des Tellerrands liegt - ich habe mich innerhalb weniger Stunden nach dem Erstellen des Produkts innerhalb weniger Stunden davon angezogen.
Ich bin wieder nicht da, um zu sagen, dass Go definitiv die beste Sprache ist und Sie damit gehen müssen. Aber für sein Alter ist es sehr reif und robust. (Im gleichen Alter wie Knoten). Der Typ -Rekonstruktion ist lustig und einfach, die von GO bereitgestellten Hausaufgaben und Debugging -Tools sind großartig, und die Community hat sehr starke Vorschriften für Dokumentation, Formate, Benchmarks und API -Design.
Als ich mich so an den extrem modularen Knoten gewöhnt und Rubys verrottende Standardbibliothek erlebt hatte, hörte ich, als ich zum ersten Mal von Go hörte, seine Standardbibliothek sei schrecklich. Nachdem ich in diese Sprache eingetaucht war, wurde mir klar, dass die meisten Standardbibliotheken in dieser Phase erforderlich sind, wie die Komprimierung, JSON, IO, gepufferte IO, String -Operationen usw. Die meisten dieser APIs sind gut definiert und leistungsfähig. Es ist einfach, das gesamte Programm mit diesen Standardbibliotheken zu schreiben.
GO-Pakete von Drittanbietern
Die meisten Go-Bibliotheken sehen ähnlich aus, der größte Teil des Code von Drittanbietern, den ich bisher verwendet habe, ist von hoher Qualität, und es ist schwierig, diese im Knoten zu finden, da JavaScript Entwickler in unterschiedlichen Fähigkeiten anzieht.
Es gibt keine Registrierung für Go -Pakete, sodass Sie normalerweise 5 oder 6 gleiche Pakete gleichzeitig sehen. Irgendwann kann dies zu Verwirrung führen, hat jedoch einen interessanten Nebeneffekt, und Sie müssen entscheiden, welche die beste Option ist, indem Sie jedes Paket sorgfältig überprüfen. Durch den Knoten gibt es normalerweise Spezifikationspakete wie "Redis", "MongoDB-nativer" oder "Zeromq", sodass Sie dort aufhören und schließen, dass sie die besten sind.
Wenn Sie verteilte Arbeiten ausführen, finden Sie die beeindruckende gleichzeitige zugrunde liegende Datentypen als sehr hilfreich. Wir können von Generatoren im Knoten etwas Ähnliches bekommen, aber meiner Meinung nach sind die Generatoren nur die Hälfte fertig. Ohne unabhängige Fehlerbehandlung ist der Berichtsstapel immer noch gewöhnlich, auch wenn dies am besten ist. Wenn diese Lösungen gut funktionieren, möchte ich nicht darauf warten, dass die Community drei Jahre neu organisiert.
Meiner Meinung nach ist Go's Fehlerbehebung hervorragend. Der Knoten ist großartig in Bezug auf das, was Sie über jeden Fehler nachdenken und entscheiden, wie es geht. Der Knoten scheitert jedoch in:
Sie können den Rückruf wiederholen
Sie dürfen überhaupt keinen Rückruf tätigen und sich in einem instabilen Zustand verlaufen (z. B. vergessen Sie, einen Fehler zu übergeben, um den Rückruf zu verarbeiten. Wenn ein Fehler auftritt, schluckt der Knoten den Fehler ohne Rückmeldung).
Möglicherweise erhalten Sie den Fehler beim Mitnehmen
Emitter erhalten möglicherweise mehrere falsche Ereignisse
Ich habe das falsche Ereignis vergessen, um damit umzugehen, wird alles ruinieren
Oft nicht sicher, was benötigt wird, um Fehler zu behandeln
Die Fehlerbehandlung ist sehr überflüssig
Der Rückruf ist schrecklich
Wenn mein Code endet, endet er und Sie können ihn in einer Erklärung nicht erneut ausführen. Dies ist im Knoten ungewiss. Sie werden denken, dass ein Programm vollständig ausgeführt wird, bis eine Bibliothek einen Rückruf mehrmals aufruft oder Handler nicht richtig löscht und dann den Code erneut ausgeführt wird. Es ist ziemlich schwierig, diese Gründe im tatsächlichen Produktionscode zu finden. Warum sollten Sie sich darum kümmern? Andere Sprachen lassen Sie diese Schmerzen nicht erleben.
Der Knoten der Zukunft
Ich hoffe immer noch, dass Knoten gute Arbeit leistet, viele Menschen investieren enorm in ihn und es hat dieses Potenzial. Ich denke, Joyent und das Team müssen sich auf die Benutzerfreundlichkeit konzentrieren - wenn Ihre Anwendung fragil und schwer zu debuggen, refaktor und sich zu entwickeln ist, ist die Leistung bedeutungslos.
In 4-5 Jahren werden wir immer noch diesen vagen Fehler "Fehler: Getaddrinfo eaddrinfo" haben, und diese Tatsache sagt uns, wo sich die Entwicklungsprioritäten des Knotens befinden. Verständlicherweise ist es, wenn Sie sich auf den Aufbau des Kerns des Systems konzentrieren, leicht diese Dinge zu übersehen. Ich denke, Benutzer haben immer wieder ihre Meinung zu solchen Dingen geäußert, aber keine Ergebnisse gesehen. Normalerweise erhalten wir ein paar Antworten, um zu behaupten, 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 bedienen, Fehler sind unklar, Tools sind nicht einfach zu bedienen, es gibt Community -Vorschriften, aber sie scheinen im Vergleich zu GO zu fehlen. Trotzdem kann ich den Knoten weiterhin für bestimmte Aufgaben verwenden, z. B. für das Erstellen von Webseiten oder einige fragmentierte APIs oder Prototypen. Wenn der Knoten einige seiner grundlegenden Probleme beheben kann, hat er die Möglichkeit, relevant zu bleiben. Wenn es jedoch eine andere Lösung gibt, die eine höhere Leistung als die Verfügbarkeit erfolgt, wenn eine höhere Leistung und höhere Verfügbarkeitsargumente nicht zu weit gehen.
Wenn die Knotengemeinschaft beschließt, Generatoren zu akzeptieren und in einem Kernknoten zu implementieren und Fehler angemessen zu übergeben, besteht die Möglichkeit, diese Referenzierung zu machen. Dies wird die Benutzerfreundlichkeit und Robustheit des Knotens vollständig verbessern.
Die gute Nachricht ist, dass ich mit einem großartigen und talentierten Typ, der vor kurzem in Strongloop in Strongloop beigetragen habe, gesprochen habe. Sie übernehmen ausdrücklich den richtigen Weg, um diese Probleme zu beheben, um zukünftige Knoten zu erleichtern, indem sie die Antworten der Entwickler auf die Plattform anhören und planen, den richtigen Weg zu finden, um diese Probleme zu beheben. Ich bin mir nicht sicher, wie der Konflikt zwischen mehreren Unternehmen über die gleichzeitige Entwicklung des Kernteils enden wird, aber ich hoffe, der Entwicklerfahrer wird gewinnen.
Dies bedeutet nicht, dass es sich um einen Angriff auf Einzelpersonen handelt. Viele wirklich talentierte Leute arbeiten mit oder auf dem Knoten, aber das ist nicht mehr etwas, an dem ich interessiert bin. Ich hatte eine tolle Zeit in der Knotengemeinschaft und traf einige wirklich interessante Leute.
Die Bedeutung der Geschichte ist, dass Sie nicht durch Ihren eigenen Kreis eingeschränkt werden sollten! Sehen Sie, was anderswo und Sie könnten wieder programmieren. Es gibt viele erstaunliche Lösungen außerhalb davon, und der Fehler, den ich gemacht habe, ist, dass ich zu lange gewartet habe, um mit ihnen zu spielen!