Was sind die Nachteile einer JavaScript-Laufzeitimplementierung mit mehreren Threads? [geschlossen]

51

Ich habe in der vergangenen Woche an einer JavaScript-Laufzeitimplementierung mit mehreren Threads gearbeitet. Ich habe einen in C ++ mit JavaScriptCore und Boost erstellten Proof of Concept.

Die Architektur ist einfach: Wenn die Laufzeit die Auswertung des von ihr gestarteten Hauptskripts beendet und sich einem Thread-Pool anschließt, der Aufgaben aus einer gemeinsam genutzten Prioritätswarteschlange auswählt, werden zwei Aufgaben, die versuchen, gleichzeitig auf eine Variable zuzugreifen, als atomar gekennzeichnet und konkurrieren um den Zugriff .

Arbeitet mit Multithread-Laufzeitdatei node.js

Das Problem ist, dass ich, wenn ich dieses Design einem JavaScript-Programmierer zeige, äußerst negatives Feedback bekomme und keine Ahnung habe, warum. Selbst privat sagen sie alle, dass JavaScript Single-Threading sein soll, dass vorhandene Bibliotheken neu geschrieben werden müssten und dass Gremlins jedes Lebewesen laichen und fressen werden, wenn ich weiter daran arbeite.

Ursprünglich hatte ich auch eine native Coroutine-Implementierung (unter Verwendung von Boost-Kontexten), aber ich musste darauf verzichten (JavaScriptCore ist pedantisch in Bezug auf den Stack), und ich wollte ihren Zorn nicht riskieren, also habe ich mich dagegen entschieden, es zu erwähnen.

Was denkst du? Ist JavaScript als Singlethread gedacht und sollte es in Ruhe gelassen werden? Warum ist jeder gegen die Idee einer gleichzeitigen JavaScript-Laufzeit?

Bearbeiten: Das Projekt ist jetzt auf GitHub , experimentieren Sie selbst und lassen Sie mich wissen, was Sie denken.

Das Folgende ist ein Bild von Versprechungen, die auf allen CPU-Kernen ohne Konkurrenz parallel ausgeführt werden:

Laufen verspricht gleichzeitig.

Voodooattack
quelle
7
Dies scheint eine hochmeinende Frage zu sein. Haben Sie die Leute gefragt, denen Ihre Idee anscheinend nicht gefallen hat, warum sie glauben, dass dies problematisch sein wird?
5gon12eder
26
Das Hinzufügen von Threads zu etwas, das nicht für Multithreading gedacht ist, entspricht dem Umwandeln einer einspurigen Straße in eine Schnellstraße, ohne dass der Fahrer einen Ed bereitstellt. Es wird die meiste Zeit ziemlich gut funktionieren, bis die Leute zufällig abstürzen. Mit Multithreading treten entweder subtile Timing-Fehler auf, die Sie nicht reproduzieren können, oder fehlerhafte Verhaltensweisen, die die meiste Zeit auftreten. Man muss dies berücksichtigen. Sie benötigen eine Thread-Synchronisation. Nur Variablen atomar zu machen, beseitigt nicht die Rennbedingungen.
mgw854
2
Wie wollen Sie den Multithread-Zugriff auf den gemeinsam genutzten Status handhaben? "Als atomar markiert und um Zugriff konkurrieren" erklärt nicht, wie dies Ihrer Meinung nach wirklich funktionieren würde. Ich würde vermuten, dass negative Einstellungen zu dieser Idee darin bestehen, dass die Leute keine Ahnung haben, wie Sie diese Idee tatsächlich umsetzen würden. Oder wenn Sie den Entwickler wie in Java oder C ++ mit der Verwendung geeigneter Mutexe und dergleichen belasten, überlegen sich die Leute wahrscheinlich, warum sie dieses Komplikations- und Programmierrisiko in einer Umgebung wollen, die frei davon ist.
jfriend00
17
Da das automatische Koordinieren des Zufallszustands zwischen Threads als nahezu unmögliches Problem angesehen wird, haben Sie keine Glaubwürdigkeit, dass Sie alles anbieten können, was dies automatisch tut. Und wenn Sie den Entwickler nur wie Java oder C ++ entlasten wollen, dann wollen die meisten Programmierer von node.js diese Belastung nicht - sie mögen, dass node.js sich nicht darum kümmern muss der größte Teil. Wenn Sie ein offenes Ohr haben möchten, müssen Sie erklären / zeigen, wie und was Sie in dieser Hinsicht anbieten würden und warum dies gut und nützlich wäre.
jfriend00
3
Bitte setzen Sie Ihre Arbeit fort. Ich betrachte Sprachen ohne Multithreading als Spielzeugsprachen. Ich denke, die meisten JavaScript-Entwickler arbeiten mit dem Browser, der ein Single-Thread-Modell hat.
Chloe

Antworten:

70

1) Multithreading ist extrem schwierig, und leider impliziert die Art und Weise, wie Sie diese Idee bisher präsentiert haben, dass Sie die Schwierigkeit stark unterschätzen.

Im Moment klingt es so, als würden Sie der Sprache einfach "Threads hinzufügen" und sich Gedanken darüber machen, wie Sie sie später korrekt und performant machen können. Speziell:

Wenn zwei Tasks gleichzeitig versuchen, auf eine Variable zuzugreifen, wird sie als atomar markiert und sie konkurrieren um den Zugriff.
...
Ich bin damit einverstanden, dass atomare Variablen nicht alles lösen, aber das nächste Ziel ist es, an einer Lösung für das Synchronisationsproblem zu arbeiten.

Das Hinzufügen von Threads zu Javascript ohne "Lösung für das Synchronisationsproblem" entspricht dem Hinzufügen von Ganzzahlen zu Javascript ohne "Lösung für das Additionsproblem". Es ist so grundlegend für die Natur des Problems, dass es im Grunde keinen Grund gibt, darüber zu diskutieren, ob Multithreading ohne eine bestimmte Lösung hinzugefügt werden sollte, egal wie dringend wir es wollen.

Wenn Sie alle Variablen atomar machen, ist die Leistung eines Multithread-Programms wahrscheinlich schlechter als die eines Singlethread-Programms. Umso wichtiger ist es, die Leistung in realistischeren Programmen zu testen und festzustellen, ob Sie etwas gewinnen oder nicht.

Mir ist auch nicht klar, ob Sie versuchen, Threads vor dem Programmierer von node.js zu verbergen, oder ob Sie sie irgendwann verfügbar machen möchten, um effektiv einen neuen Dialekt von Javascript für Multithread-Programmierung zu erstellen. Beide Optionen sind möglicherweise interessant, aber es scheint, als hätten Sie sich noch nicht einmal entschieden, welche Sie anstreben.

Im Moment bitten Sie Programmierer, in Erwägung zu ziehen, von einer Singlethread-Umgebung zu einer brandneuen Multithread-Umgebung zu wechseln, die keine Lösung für das Synchronisationsproblem und keine Beweise für eine Verbesserung der realen Leistung bietet und anscheinend keinen Plan zur Lösung dieser Probleme hat.

Das ist wahrscheinlich der Grund, warum die Leute dich nicht ernst nehmen.

2) Die Einfachheit und Robustheit der Einzelereignisschleife ist ein großer Vorteil.

Javascript-Programmierer wissen, dass die Javascript-Sprache vor den Rennbedingungen und anderen extrem heimtückischen Fehlern, die die gesamte Multithread-Programmierung plagen, "sicher" ist. Die Tatsache, dass sie starke Argumente brauchen, um davon zu überzeugen, dass Sicherheit aufgegeben werden muss, macht sie nicht verschlossen, sondern verantwortlich.

Sofern Sie diese Sicherheit nicht irgendwie aufrechterhalten können, ist es für alle, die auf einen Multithread-Node.js umsteigen möchten, wahrscheinlich besser, auf eine Sprache wie Go umzuschalten, die von Grund auf für Multithread-Anwendungen entwickelt wurde.

3) Javascript unterstützt bereits "Hintergrundthreads" (WebWorkers) und asynchrone Programmierung, ohne das Thread-Management direkt dem Programmierer zugänglich zu machen.

Diese Funktionen lösen bereits viele der üblichen Anwendungsfälle, die JavaScript-Programmierer in der realen Welt betreffen, ohne die Sicherheit der Einzelereignisschleife aufzugeben.

Haben Sie spezielle Anwendungsfälle, für die diese Funktionen keine Lösung bieten und für die Javascript-Programmierer eine Lösung suchen? In diesem Fall ist es eine gute Idee, die Datei node.js mit mehreren Threads im Kontext dieses speziellen Anwendungsfalls zu präsentieren.


PS Was würde mich überzeugen , auf eine Multithread-Implementierung von node.js umzusteigen?

Schreiben Sie ein nicht triviales Programm in Javascript / node.js, von dem Sie glauben, dass es von echtem Multithreading profitiert. Führen Sie Leistungstests für dieses Beispielprogramm auf dem normalen Knoten und Ihrem Multithread-Knoten durch. Zeigen Sie mir, dass Ihre Version die Laufzeitleistung, die Reaktionsfähigkeit und die Verwendung mehrerer Kerne erheblich verbessert, ohne dass Fehler oder Instabilitäten auftreten.

Sobald Sie das getan haben, werden Sie wahrscheinlich Leute sehen, die sich viel mehr für diese Idee interessieren.

Ixrec
quelle
1
1) Okay, ich gebe zu, dass ich das Problem der Synchronisation schon eine Weile aufgeschoben habe. Wenn ich sage, dass "zwei Aufgaben miteinander konkurrieren", ist das nicht mein Entwurf, sondern hauptsächlich eine Beobachtung: dl.dropboxusercontent.com/u/27714141/… - Ich bin nicht sicher, welche Art von Hexerei JavaScriptCore hier ausführt, sollte es aber nicht. Wird diese Zeichenfolge beschädigt, wenn sie nicht von Natur aus atomar ist? 2) Ich stimme überhaupt nicht zu. Aus diesem Grund wird JS als Spielzeugsprache angesehen. 3) ES6-Versprechen wären viel leistungsfähiger, wenn sie mit einem Thread-Pool-Scheduler implementiert würden.
Voodooattack
13
@voodooattack "Dies ist der Grund, warum JS als Spielzeugsprache angesehen wird." Nein, aus diesem Grund halten Sie es für eine Spielzeugsprache. Millionen von Menschen nutzen JS jeden Tag und sind vollkommen zufrieden damit, mit Mängeln und allem. Stellen Sie sicher, dass Sie ein Problem lösen, das genug andere Menschen haben und das nicht besser durch einfaches Ändern der Sprache gelöst werden kann.
Chris Hayes
@ChrisHayes Die Frage ist, warum man seine Mängel in Kauf nimmt, wenn ich sie beheben kann. Würde die Parallelität als Feature JavaScript verbessern?
Voodooattack
1
@voodooattack Das ist die Frage. Würde die Parallelität als Feature Javascript verbessern? Wenn Sie eine Community-Antwort erhalten, die nicht "nein" ist, dann sind Sie vielleicht auf etwas eingestellt. Es scheint jedoch, als ob die Ereignisschleife und die native Delegierung des Knotens an Arbeitsthreads zum Blockieren von Ereignissen für die meisten Aufgaben ausreichen. Ich denke, wenn Leute wirklich JavaScript mit Threads benötigen, werden sie Javascript-Worker verwenden. Wenn Sie jedoch eine Möglichkeit finden, Worker dazu zu bringen, mit erstklassigen Funktionen anstelle von JS-Dateien zu arbeiten, dann könnten Sie wirklich auf etwas aus sein.
lunchmeat317
7
@voodooattack Leute, die JavaScript als Spielzeugsprache bezeichnen, wissen nicht, wovon sie sprechen. Ist es die Sprache für alles? Natürlich nicht, aber entlassen ihn so ist sicherlich ein Fehler. Wenn Sie den Gedanken zerstreuen möchten, dass JS eine Spielzeugsprache ist, erstellen Sie eine nicht triviale Produktionsanwendung oder verweisen Sie auf eine vorhandene. Das Hinzufügen von Parallelität ändert sowieso nicht die Meinung dieser Leute.
jpmc26
16

Ich rate hier nur, um ein Problem in Ihrem Ansatz zu demonstrieren. Ich kann es nicht gegen die reale Implementierung testen, da es nirgendwo einen Link gibt ...

Ich würde sagen, das liegt daran, dass Invarianten nicht immer durch den Wert einer Variablen ausgedrückt werden und dass 'eine Variable' im allgemeinen Fall nicht ausreicht, um den Gültigkeitsbereich einer Sperre zu bestimmen. Stellen Sie sich zum Beispiel vor, wir haben eine Invariante a+b = 0(Kontostand einer Bank mit zwei Konten). Die beiden folgenden Funktionen stellen sicher, dass die Invariante immer am Ende jeder Funktion gehalten wird (die Ausführungseinheit in Single-Threaded-JS).

function withdraw(v) {
  a -= v;
  b += v;
}
function deposit(v) {
  b -= v;
  a += v;
}

Jetzt, in Ihrer multithreaded Welt, was passiert , wenn zwei Threads ausführen withdrawund depositzugleich? Danke, Murphy ...

(Möglicherweise haben Sie Code, der + = und - = speziell behandelt, aber das ist keine Hilfe. Irgendwann haben Sie einen lokalen Status in einer Funktion, und ohne die Möglichkeit, zwei Variablen gleichzeitig zu sperren, wird dies Ihre Invariante tun verletzt werden.)


BEARBEITEN: Wenn Ihr Code semantisch dem Go-Code unter https://gist.github.com/thriqon/f94c10a45b7e0bf656781b0f4a07292a entspricht , ist mein Kommentar korrekt ;-)

Thriqon
quelle
Dieser Kommentar ist irrelevant, aber die Philosophen sind in der Lage, mehrere Objekte zu sperren, aber sie verhungern, weil sie sie in einer inkonsistenten Reihenfolge sperren.
Dietrich Epp
3
@voodooattack "Ich habe gerade getestet ..." Sind Sie noch nie auf eine inkonsistente Ausführungsreihenfolge bei der Thread-Planung gestoßen? Es variiert von Lauf zu Lauf, von Maschine zu Maschine. Sich hinzusetzen und einen einzelnen Test (oder sogar hundert Tests!) Durchzuführen, ohne den Mechanismus für die Planung von Vorgängen zu ermitteln, ist sinnlos.
jpmc26
4
@voodooattack Das Problem ist, dass ein einfaches Testen der Parallelität nicht sinnvoll ist. Sie müssen in der Lage sein zu beweisen, dass die Invariante Bestand hat, oder der Mechanismus kann in der Produktion niemals als vertrauenswürdig eingestuft werden.
Sapi
1
Sie haben dem Benutzer jedoch keine Tools zum "verantwortungsvollen Umgang mit dem System" zur Verfügung gestellt, da es absolut keinen Verriegelungsmechanismus gibt. Wenn Sie alles atomar machen, entsteht eine Illusion von Threadsicherheit (und Sie sehen den Performance-Hit darin, dass alles atomar ist, auch wenn Sie keinen atomaren Zugriff benötigen), aber die meisten Parallelitätsprobleme, wie sie Thriqon hier vorschlägt, werden dadurch nicht gelöst. Versuchen Sie in einem anderen Beispiel, ein Array in einem Thread zu durchlaufen, während ein anderer Thread Elemente zum Array hinzufügt oder daraus entfernt. Was lässt Sie davon ausgehen, dass die Implementierung von Array durch die Engine sogar threadsicher ist?
Zach Lipton
2
@voodooattack Wenn Benutzer Ihre Threads also nur für Funktionen ohne gemeinsame Daten oder Nebenwirkungen verwenden können (und sie sie besser nicht für andere Zwecke verwenden, da es, wie wir hier gesehen haben, keine Möglichkeit gibt, die Threadsicherheit zu gewährleisten), Welchen Wert bieten Sie dann gegenüber Web Workern (oder einer der vielen Bibliotheken, die eine benutzerfreundlichere API für Web Worker bereitstellen)? Und Web Worker sind viel sicherer, weil sie es dem Benutzer unmöglich machen, das System "verantwortungslos" zu nutzen.
Zach Lipton
15

Vor ungefähr einem Jahrzehnt schrieb Brendan Eich (der Erfinder von JavaScript) einen Aufsatz mit dem Titel Threads Suck , der definitiv eines der wenigen kanonischen Dokumente der JavaScript-Designmythologie ist.

Ob es richtig ist, ist eine andere Frage, aber ich denke, es hat einen großen Einfluss darauf, wie die JavaScript-Community über Parallelität denkt.

Erik Pukinskis
quelle
31
Die letzte Person, von der ich Ratschläge erhalten würde, ist Brendan Eich. Seine ganze Karriere basiert auf der Erstellung von JavaScript, was so schlimm ist, dass wir eine Menge Tools haben, die erstellt wurden, um die angeborene Scheiße zu umgehen. Denken Sie daran, wie viele Entwicklerstunden durch ihn auf der Welt verschwendet wurden.
Phil Wright
12
Ich verstehe zwar, warum Sie seine Meinung im Allgemeinen und sogar Ihre Verachtung für JavaScript herabsetzen würden, aber ich verstehe nicht, wie Ihre Perspektive es erlauben würde, seine Fachkenntnisse auf dem Gebiet zu ignorieren.
Billy Cravens
4
@BillyCravens haha, sogar das kanonische Buch über Javascript: "Javascript the good parts " von Crockford verrät das Spiel im Titel. Behandle Eichs Einstellungen genauso,
halte dich
13
@PhilWright: Seine erste Implementierung von Javascript war eine Lisp-Variante. Was mir großen Respekt einbringt. Die Entscheidung seines Chefs, ihn zu zwingen, die Lisp-Syntax durch eine C-ähnliche Syntax zu ersetzen, ist nicht seine Schuld. Javascript ist im Kern noch eine Lisp-Laufzeit.
Slebetman
7
@PhilWright: Du solltest Eich nicht für die Scheiße der Sprache verantwortlich machen. Es sind Fehler in frühen Implementierungen und die Notwendigkeit der Abwärtskompatibilität für eine Web-Sprache, die verhindert hat, dass JS ausgereift ist. Die Kernkonzepte bilden immer noch eine wunderbare Sprache.
Bergi
8

Atomarer Zugriff führt nicht zu threadsicherem Verhalten.

Ein Beispiel ist, wenn eine globale Datenstruktur während einer Aktualisierung ungültig sein muss, z. B. beim erneuten Aufbereiten einer Hashmap (z. B. beim Hinzufügen einer Eigenschaft zu einem Objekt) oder beim Sortieren eines globalen Arrays. Während dieser Zeit können Sie keinem anderen Thread erlauben, auf die Variable zuzugreifen. Dies bedeutet im Grunde, dass Sie die gesamten Lese-Update-Schreibzyklen erkennen und darüber hinwegsperren müssen. Wenn das Update nicht trivial ist, führt dies dazu, dass das Problemgebiet gestoppt wird.

Javascript wurde von Anfang an mit einem einzigen Thread und einer Sandbox erstellt, und der gesamte Code wird unter Berücksichtigung dieser Annahmen geschrieben.

Dies hat einen großen Vorteil in Bezug auf isolierte Kontexte und das Ausführen von zwei separaten Kontexten in verschiedenen Threads. Ich meine auch, dass Leute, die Javascript schreiben, nicht wissen müssen, wie sie mit Rennbedingungen und verschiedenen anderen Multithread-Pitfals umgehen sollen.

Ratschenfreak
quelle
Aus diesem Grund denke ich, dass die Scheduler-API weiter fortgeschritten sein sollte und intern für Versprechungen und Funktionen verwendet werden sollte, die keine Nebenwirkungen haben.
Voodooattack
6

Wird Ihr Ansatz die Leistung erheblich verbessern?

Zweifelhaft. Sie müssen das wirklich beweisen.

Wird Ihr Ansatz das Schreiben von Code erleichtern / beschleunigen?

Auf keinen Fall, Multithread-Code ist um ein Vielfaches schwieriger zu finden als Single-Thread-Code.

Wird Ihr Ansatz robuster sein?

Deadlocks, Rennbedingungen usw. sind ein Albtraum.

Phil Wright
quelle
2
Versuchen Sie, einen Raytracer mit node.js zu erstellen. Versuchen Sie es jetzt erneut mit Threads. Multiprozess ist nicht alles.
Voodooattack
8
@voodooattack, niemand, der bei Verstand ist, würde einen Ray-Tracer mit Javascript schreiben, mit oder ohne Threading, da es sich um einen relativ einfachen, aber rechenintensiven Algorithmus handelt, der besser in einer vollständig kompilierten Sprache geschrieben ist, vorzugsweise mit SIMD-Unterstützung . Für die Art von Problemen, für die Javascript verwendet wird, ist Multiprozess mehr als genug.
Jan Hudec
@JanHudec: Heh, JS wird auch SIMD-Unterstützung bekommen :-) hacks.mozilla.org/2014/10/introducing-simd-js
Bergi
2
@voodooattack Wenn Sie sich dessen nicht bewusst sind, werfen Sie einen Blick auf SharedArrayBuffers . JavaScript erhält immer mehr Parallelitätskonstruktionen, diese werden jedoch äußerst vorsichtig hinzugefügt, um bestimmte Schwachstellen zu beheben und das Treffen von schlechten Entwurfsentscheidungen, mit denen wir jahrelang zu kämpfen haben, so gering wie möglich zu halten.
MONICA WIEDERHERSTELLEN
2

Bei Ihrer Implementierung geht es nicht nur um die Einführung der Parallelität, sondern auch um die Einführung einer bestimmten Methode zur Implementierung der Parallelität, dh der Parallelität nach gemeinsamem veränderlichen Status. Im Laufe der Geschichte haben die Menschen diese Art der Parallelität verwendet und dies hat zu vielen Arten von Problemen geführt. Natürlich können Sie einfache Programme erstellen, die perfekt mit der Verwendung von gemeinsam genutzten veränderlichen Zuständen zusammenarbeiten, aber der eigentliche Test eines Mechanismus ist nicht das, was er kann, sondern kann skaliert werden, wenn das Programm komplex wird und dem Programm immer mehr Funktionen hinzugefügt werden. Denken Sie daran, dass Software keine statische Sache ist, die Sie einmal erstellt haben und mit der Sie fertig sind, sondern sich im Laufe der Zeit weiterentwickelt und ob irgendein Mechanismus oder Konzept dies kann. '

Sie können sich auch andere Modelle der Parallelität ansehen (z. B. Nachrichtenübermittlung), um herauszufinden, welche Vorteile diese Modelle bieten.

Ankur
quelle
1
Ich denke, dass ES6-Versprechen von dem Modell meiner Implementierung profitieren würden, da sie nicht um den Zugriff konkurrieren.
Voodooattack
Schauen Sie sich die WebWorkers-Spezifikation an. Es gibt npm-Pakete, die ihre Implementierung bereitstellen, aber Sie können sie eher als Kern Ihrer Engine als Paket implementieren
Ankur,
JavaScriptCore (die Webkit-Implementierung von JS, die ich verwende) implementiert sie bereits, es ist nur ein Kompilierungsflag.
Voodooattack
Okay. WebWorker laufen parallel zur Nachrichtenübermittlung. Sie können Ihr Raytracer-Beispiel damit ausprobieren und es mit dem Ansatz des veränderlichen Zustands vergleichen.
Ankur
4
Die Nachrichtenübergabe wird immer über dem veränderlichen Status implementiert, was bedeutet, dass sie langsamer ist. Ich verstehe deinen Standpunkt hier nicht. : - /
Voodooattack
1

Das ist nötig. Das Fehlen eines Nebenläufigkeitsmechanismus auf niedriger Ebene in Knoten js schränkt seine Anwendungen in Bereichen wie Mathematik und Bioinformatik usw. ein. Außerdem steht die Nebenläufigkeit mit Threads nicht notwendigerweise in Konflikt mit dem in Knoten verwendeten Standard-Gleichzeitigkeitsmodell. Es gibt wohlbekannte Semantiken für das Threading in einer Umgebung mit einer Hauptereignisschleife, wie z. B. UI-Frameworks (und Nodejs), und sie sind definitiv zu komplex für die meisten Situationen, in denen sie noch gültige Verwendungen haben.

Sicherlich erfordert Ihre durchschnittliche Web-App keine Threads, aber versuchen Sie, etwas weniger Konventionelles zu tun, und das Fehlen eines soliden Grundelements mit niedriger Nebenläufigkeit wird Sie schnell dazu bringen, etwas anderes zu finden, das dies anbietet.

dryajov
quelle
4
Aber "Mathematik und Bioinformatik" wäre besser in C #, JAVA oder C ++ geschrieben
Ian
Tatsächlich sind Python und Perl die dominierenden Sprachen in diesen Bereichen.
Dryajov
1
Der Hauptgrund, warum ich dies implementiere, sind maschinelle Lernanwendungen. Sie haben also Recht.
Voodooattack
@dryajov Seien Sie froh, dass Sie nicht wissen, wie groß FORTRAN in einigen Bereichen der Informatik ist ...
cmaster
@dryajov Weil sie für Menschen, die vielleicht keine Vollzeitprogrammierer sind, zugänglicher sind, nicht, weil sie von Natur aus besser in der Genomsequenzierung sind - wir haben zweckgebundene Sprachen wie R und dafür wissenschaftliche Langsamkeiten wie Fortran kompiliert.
Katze
0

Ich glaube wirklich, dass es eine andere und mächtige Idee ist. Du gehst gegen Glaubenssysteme. Sachen werden akzeptiert oder populär durch Netzwerkeffekte, die nicht auf dem Verdienst beruhen. Auch will sich niemand an einen neuen Stack anpassen. Menschen lehnen automatisch Dinge ab, die zu unterschiedlich sind.

Wenn Sie einen Weg finden, wie Sie es zu einem normalen npm-Modul machen können, was unwahrscheinlich klingt, werden Sie möglicherweise einige Leute dazu bringen, es zu benutzen.

Jason Livesay
quelle
Meinen Sie damit, dass JS-Programmierer an npm gebunden sind?
Voodooattack
3
Die Frage ist nach einem neuen Laufzeitsystem und nicht nach einem npm-Modul und auch nach einer veränderlichen Parallelität von gemeinsam genutzten Zuständen ist eine alte Idee.
Ankur
1
@voodooattack Ich meine, sie sind auf den Ansatz fixiert, der bereits populär ist, und es wird so gut wie unmöglich sein, den Status Quo Bias zu überwinden.
Jason Livesay