Przyznam szczerze, że po tej rozmowie czuję pewien niedosyt, chociaż Jarka słucha się naprawdę świetnie. Około sześć lat temu przeszedłem ścieżkę z Java do Go, głównie z powodu ograniczeń ekosystemu JVM. Deploymenty aplikacji w Javie, szczególnie z użyciem Springa, były po prostu zbyt kosztowne - prosta aplikacja wymagała minimum 256 MB RAM, podczas gdy jej odpowiednik w Go zadowalał się zaledwie 32 MB. Ciekawie byłoby dowiedzieć się, czy w tej kwestii coś się zmieniło. Co do tego, że wiele baz danych czy narzędzi, takich jak Apache Kafka, zostało napisanych w Javie - zastanawiam się, czy nie wynikało to po prostu z jej ogromnej popularności w pewnym momencie. Dla porównania, ScyllaDB, napisana w C++, jest kompatybilna z Apache Cassandra (napisaną w Javie), ale twórcy twierdzą, że ich rozwiązanie jest dziesięciokrotnie bardziej wydajne. To właśnie problemy z Garbage Collectorem były jednym z powodów stworzenia Scylli, co może sugerować, że w tym przypadku to JVM okazał się ograniczeniem. Podobnie wygląda sytuacja z Redpandą, alternatywą dla Apache Kafka. Jest kompatybilna z Kafką, ale napisana w C++. Twórcy chwalą się, że koszty deploymentu są od trzech do sześciu razy niższe niż w przypadku Kafki. Na koniec chciałbym się odnieść do powiedzenia, że warto znać jeden poziom abstrakcji poniżej tego, z którego się korzysta. W przypadku ORM-ów absolutnie zgadzam się, że dobrze jest rozumieć, jakie zapytania SQL generuje dana metoda oraz jak działa baza danych. Niemniej jednak nigdy nie miałem potrzeby głębszego zgłębiania tajników JVM - może po prostu byłem wtedy ignorantem. ;) Wracając jednak do JVM - wciąż zastanawiam się, na ile ta dodatkowa warstwa abstrakcji jest rzeczywiście potrzebna. Kod napisany w Go bez problemu działa na różnych architekturach i systemach operacyjnych, co sugeruje, że da się to osiągnąć bez JVM.
Wszystko zależy od tego co piszesz. Jak to jest aplikacja gdzie taniej jest dopłacić do mocniejszych maszyn - to Java będzie po prostu szybsza w developmencie. Java jest szybsza w zrobieniu PoC, czy dowiezienia odpowiedniego zbioru funkcjonalności. Tak na prawdę to nie tak wielkie obszary aplikacji muszą być wydajne. Cała masa kodu jest tak rzadko używana, że taniej, szybciej i mniej zawodnie zrobi się ją w językach zarządzanych. Bez ograniczeń czasowych albo finansowych to pewnie wszyscy pisalibyśmy w assemblerze. Ale te ograniczenia istnieją, więc piszemy w JavaScript ;)
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
Przyznam szczerze, że po tej rozmowie czuję pewien niedosyt, chociaż Jarka słucha się naprawdę świetnie. Około sześć lat temu przeszedłem ścieżkę z Java do Go, głównie z powodu ograniczeń ekosystemu JVM. Deploymenty aplikacji w Javie, szczególnie z użyciem Springa, były po prostu zbyt kosztowne - prosta aplikacja wymagała minimum 256 MB RAM, podczas gdy jej odpowiednik w Go zadowalał się zaledwie 32 MB. Ciekawie byłoby dowiedzieć się, czy w tej kwestii coś się zmieniło.
Co do tego, że wiele baz danych czy narzędzi, takich jak Apache Kafka, zostało napisanych w Javie - zastanawiam się, czy nie wynikało to po prostu z jej ogromnej popularności w pewnym momencie. Dla porównania, ScyllaDB, napisana w C++, jest kompatybilna z Apache Cassandra (napisaną w Javie), ale twórcy twierdzą, że ich rozwiązanie jest dziesięciokrotnie bardziej wydajne. To właśnie problemy z Garbage Collectorem były jednym z powodów stworzenia Scylli, co może sugerować, że w tym przypadku to JVM okazał się ograniczeniem.
Podobnie wygląda sytuacja z Redpandą, alternatywą dla Apache Kafka. Jest kompatybilna z Kafką, ale napisana w C++. Twórcy chwalą się, że koszty deploymentu są od trzech do sześciu razy niższe niż w przypadku Kafki.
Na koniec chciałbym się odnieść do powiedzenia, że warto znać jeden poziom abstrakcji poniżej tego, z którego się korzysta. W przypadku ORM-ów absolutnie zgadzam się, że dobrze jest rozumieć, jakie zapytania SQL generuje dana metoda oraz jak działa baza danych. Niemniej jednak nigdy nie miałem potrzeby głębszego zgłębiania tajników JVM - może po prostu byłem wtedy ignorantem. ;)
Wracając jednak do JVM - wciąż zastanawiam się, na ile ta dodatkowa warstwa abstrakcji jest rzeczywiście potrzebna. Kod napisany w Go bez problemu działa na różnych architekturach i systemach operacyjnych, co sugeruje, że da się to osiągnąć bez JVM.
Wszystko zależy od tego co piszesz. Jak to jest aplikacja gdzie taniej jest dopłacić do mocniejszych maszyn - to Java będzie po prostu szybsza w developmencie. Java jest szybsza w zrobieniu PoC, czy dowiezienia odpowiedniego zbioru funkcjonalności. Tak na prawdę to nie tak wielkie obszary aplikacji muszą być wydajne. Cała masa kodu jest tak rzadko używana, że taniej, szybciej i mniej zawodnie zrobi się ją w językach zarządzanych.
Bez ograniczeń czasowych albo finansowych to pewnie wszyscy pisalibyśmy w assemblerze. Ale te ograniczenia istnieją, więc piszemy w JavaScript ;)
Dziękuję za ten wywiad.
Fajny wywiad, naprawdę, jednak mała prośba - uczulajcie gości aby nie trzymali dłoni blisko ust, bo trochę to jednak zniekształca odbiór.