Cześć,
Mam projekt, który ma architekturę jak Jenkins. Mam Master Node i do niego będą podłączone Worker Node'y.
Master jest napisany w Javie, ale chciałbym innego języka się pouczyć i chciałbym projekt workera napisać w Go.
Czy to jest błąd czy dopuszczalna decyzja?
0
2
@NeutrinoSpinZero: a to jest projekt komercyjny z pracy czy nie? W jaki sposób się te Worker Node'y integrują?
1
@NeutrinoSpinZero: z tego co wiem, to w architekturze mikroserwisowej (a taka jest chyba twoja), to każdy z serwisów może być napisany w innym języku - istotne aby się komunikowały ze sobą.
4
Co nie znaczy że dla zabawy na produkcji powinniśmy tak robić. Bo
- Dany język może nie być najlepszym wyborem do danego serwisu
- Produkcja to nie piaskownica dla duzych chłopaków developerów
- Bo ktoś to musi utrzymać.
1
Jeżeli w firmie jest kilka zespołów do różnych technologii, to czasami lepiej zrobić daną część w innym języku.
No i podsumowując:
Czy to jest błąd czy dopuszczalna decyzja?
To zależy ;) Jeżeli do utrzymania będzie jedna osoba w firmie, to taka średnia decyzja, jeżeli np. jest cały zespół od tego to czemu nie?
2
Jeżeli w firmie jest kilka zespołów do różnych technologii, to czasami lepiej zrobić daną część w innym języku.
Oczywiście że tak, np. do serwisu związanego z jakimś BigData Scala będzie lepsza. Tylko że ten wybór nie powinien być za zasadzie "chciałbym się nauczyć Go to go walne na produkcji choć pasuje jak pięść do nosa"
6
Pracowałem w firmie gdzie połowa systemu była w Javie/Scali/Groovim/Kotlinie, druga połowa w Erlangu/Elixirze a reszta w Node. Utrzymywanie tego i modyfikacja to była tragedia. Jak odchodziłem to próbowali do tego bajzlu dodać Go
Podsumowując jak nie musisz to tak nie rób
0
@KamilAdam: dzięki, chyba zostanę przy Javie :(
@scibi_92: nie to tylko mój projekt domowy, ale robię go tak, żeby był moją pracą dzięki której będę się wyróżniał i to takie moje podsumowanie rozwoju.
Serwisy będą się komunikować tylko po WebSocketach.
1
@KamilAdam: no właśnie wszystko z umiarem i rozsądkiem.
nie to tylko mój projekt domowy, ale robię go tak, żeby był moją pracą dzięki której będę się wyróżniał i to takie moje podsumowanie rozwoju.
W takim razie czemu nie? ;)
0
W swoich projektach warto eksperymentować, bo to jedyna szansa, gdzie możesz robić wszystko i się uczyć w ten sposób.
W projektach zespołowych miałoby to słaby sens, bo byś odszedł z firmy, a potem ludzie by mówili "no, tu jest taki moduł, napisany w Go, więc musisz się nauczyć Go, żeby go obsługiwać" (co prawda Go jest tak proste, że da się je ogarnąć jako tako w kilka godzin, ale mniejsza o to).
Chociaż np. niektóre moduły w Linuksie mają być pisane w przyszłości w Rust, więc może nie musi to być zawsze zły pomysł, żeby robić tak i w projektach zespołowych? Poliglotyzm programistyczny też może być adekwatny (zresztą i tak zwykle na frontendzie jest JavaScript, a na backendzie co innego (chyba, że ktoś pisze w NodeJS), więc daje to radę).
2
A masz do tego jakiś powód, poza zajawką na Go?
Czy inne osoby w zespole mają jakąś wiedzę o Go, czy jak odejdziesz z firmy to zostanie taka kupa, której nikt nie ruszy?
0
@NeutrinoSpinZero: zależy. Najlepiej trzymać się jednego języka, ale są sytuacje, gdy ma to sens, zwłaszcza w przypadku wymagań niefunkcjonalnych. Go buduje się szybko, jest proste do ogarnięcia dla osób z zewnątrz, binarki można deployować bez dockera, zużycie pamięci małej apki to 2MB a nie 0.5 GB jak w javie, GC jest dużo mniej wymagające, jeśli chodzi o tunowanie. Oczywiście ważne jest też otoczenie: jak masz w teamie samych JVMowych świrów, to będą kręcić nosem niezależnie od tego czego byś nie użył