1) Wielowątkowość jest niezwykle trudna i niestety sposób, w jaki przedstawiłeś ten pomysł do tej pory, oznacza, że poważnie nie doceniasz jej trudności.
W tej chwili wygląda na to, że po prostu „dodajesz wątki” do języka i martwisz się, jak poprawić go i poprawić. W szczególności:
jeśli dwa zadania próbują jednocześnie uzyskać dostęp do zmiennej, zostaje ona oznaczona jako atomowa i walczą o dostęp.
...
Zgadzam się, że zmienne atomowe nie rozwiążą wszystkiego, ale moim kolejnym celem jest praca nad rozwiązaniem problemu synchronizacji.
Dodanie wątków do Javascript bez „rozwiązania problemu synchronizacji” byłoby jak dodanie liczb całkowitych do Javascript bez „rozwiązania problemu dodawania”. Jest to tak fundamentalne dla natury problemu, że w zasadzie nie ma nawet sensu dyskutować, czy wielowątkowość warto dodać bez konkretnego rozwiązania, bez względu na to, jak bardzo byśmy tego chcieli.
Co więcej, przekształcanie atomów w wszystkie zmienne to coś, co może sprawić, że program wielowątkowy będzie działał gorzej niż jego jednorzędowy odpowiednik, co sprawia, że jeszcze ważniejsze jest testowanie wydajności w bardziej realistycznych programach i sprawdzanie, czy coś zyskujesz, czy nie.
Nie jest też dla mnie jasne, czy próbujesz ukryć wątki przed programistą node.js, czy planujesz je w pewnym momencie ujawnić, tworząc nowy dialekt JavaScript dla programowania wielowątkowego. Obie opcje są potencjalnie interesujące, ale wygląda na to, że jeszcze nie zdecydowałeś, na którą celujesz.
W tej chwili prosi się programistów o rozważenie przejścia ze środowiska jedno-wątkowego na zupełnie nowe środowisko wielowątkowe, w którym nie ma rozwiązania problemu z synchronizacją i nie ma dowodów na to, że poprawia ono wydajność w świecie rzeczywistym, i pozornie nie ma planu rozwiązania tych problemów.
Prawdopodobnie dlatego ludzie nie traktują cię poważnie.
2) Prostota i niezawodność pętli pojedynczych zdarzeń jest ogromną zaletą.
Programiści Javascript wiedzą, że język JavaScript jest „bezpieczny” przed warunkami wyścigowymi i innymi wyjątkowo podstępnymi błędami, które nękają wszystkie autentycznie wielowątkowe programy. Fakt, że potrzebują silnych argumentów, aby przekonać ich do rezygnacji z bezpieczeństwa, nie czyni ich zamkniętymi, lecz czyni z nich odpowiedzialnymi.
O ile nie uda ci się w jakiś sposób zachować tego bezpieczeństwa, każdemu, kto zechce przełączyć się na wielowątkowy node.js, prawdopodobnie lepiej będzie przejść na język taki jak Go, zaprojektowany od podstaw dla aplikacji wielowątkowych.
3) JavaScript obsługuje już „wątki w tle” (WebWorkers) i programowanie asynchroniczne bez bezpośredniego udostępniania zarządzania wątkami programiście.
Te funkcje rozwiązują już wiele typowych przypadków użycia, które wpływają na programistów Javascript w prawdziwym świecie, bez rezygnacji z bezpieczeństwa pętli pojedynczych zdarzeń.
Czy masz na myśli jakieś szczególne przypadki użycia, których nie rozwiązują te funkcje i dla których programiści Javascript chcą rozwiązania? Jeśli tak, dobrym pomysłem byłoby zaprezentowanie swojego wielowątkowego node.js w kontekście tego konkretnego przypadku użycia.
PS Co przekonałoby mnie do przejścia na wielowątkową implementację node.js?
Napisz nietrywialny program w Javascript / node.js, który Twoim zdaniem mógłby skorzystać z autentycznej wielowątkowości. Wykonaj testy wydajności tego przykładowego programu w normalnym węźle i węźle wielowątkowym. Pokaż, że Twoja wersja w znacznym stopniu poprawia wydajność, czas reakcji i użycie wielu rdzeni, bez żadnych błędów i niestabilności.
Kiedy to zrobisz, myślę, że zobaczysz ludzi o wiele bardziej zainteresowanych tym pomysłem.
