Trendy technologiczne na najbliższe 5 lat

0

Chciałbym tutaj rozpocząć luźny wątek przewidywań trendów na najbliższe lata w różnych dziedzinach. Powróżmy trochę z wykresów popularności i spróbujmy oszacować co będzie popularne za kilka lat, jak możemy się przygotować na zmiany. Dla zorganizowania dyskusji chciałbym podzielić temat na poszczególne punkty. Zależy mi, żeby każdy odpowiadający umieścił odpowiednie nagłówki w swoich przewidywaniach (można dodawać swoje).

Proponowane tematy:

  1. Frontend
  2. Backend
  3. Cloud
  4. Bazy danych
  5. Data Analytics
  6. Machine Learning

Na części z tych tematów się nie znam więc będę też zadawał pytania w swoich odpowiedziach. Ja zacznę:

  1. Frontend
    W ostatnim czasie React wyparł Angulara i wygląda na to, że na długo zasiądzie na fotelu lidera. W zanadrzu jest jeszcze Vue.js, a także frameworki oparte o programowanie funkcyjne pokroju Elma. Z całą pewnością frontent jako osobna aplikacja webowa konsumująca REST API stała się dominującym trendem. Co z aplikacjami gdzie frontent jest generowany przez backend? Czy takie aplikacje zostaną przebudowane w nadchodzącej przyszłości? Czy są tańsze w produkcji czy po prostu są odziedziczonym kodem, który nie przystaje do nowych trendów? Kiedy React stanie się przestarzały i co mu może przeszkodzić? Co z frameworkami typu Phoenix_Live, gdzie frontend jest co prawda osobną aplikacją JS, która konsumuje api backendowe, natomiast sam html jest generowany po stronie backendu i wysyłany po websocketach do frontendu. Czy taka architektura jest przyszłościowa?

  2. Backend
    Java systematycznie traci na znaczeniu na rzecz języków działających na JVM. Ostatnio można zauważyć, że sporo ludzi idzie w Kotlina. Czy Scala ze swoimi topornymi typeclasses zaczyna zawodzić czy może najlepsze ma jeszcze przed sobą? Wiele osób po okresie fascynacji Scalą powraca do Javy ponieważ Java poszła do przodu z wieloma feature'ami ze świata funkcyjnego. Czy lepiej jest napisać backend webowy na JVM czy na wolniejszych technologiach typu Python, Ruby, JS dorzucając do tego load balancer? Co z DDD w tych wszystkich językach? Czy DDD oraz typesafety nie są przerostem formy nad treścią?

  3. Cloud
    Zadziwia mnie skąd te wszystkie firmy mają tyle pieniędzy do zmarnowania na cloud, który jest tak drogi. Oczywiście, administratorzy własnych klastrów oraz klastry też kosztują. Pytanie po części związane z tematem Backend. Czy przyszłością nie będą języki, które stoją bardzo blisko metalu? Tak jak zastąpiliśmy wirtualizację konteneryzacją, czy analogicznie nie zastąpimy języków pokroju Javy oraz Pythona językami takimi jak Go, Rust, Julia ze względu na to, że są bliżej metalu? Czy narzędzia pokroju Terraform są już wystarczająco dojrzałe, żebyśmy byli w stanie migrować się z clouda na inny cloud w razie podwyżek cen usług? Czy te narzędzia są napisane dobrze? Ostatnio jak patrzyłem w kod Terraforma to się przeraziłem jak bardzo na kolanie jest zaimplementowany.

  4. Bazy danych
    Czy bazy danych pokroju PostgreSQL nie stały się na tyle dobre, że są sprawdzone z ponad 90% procent przypadków?

  5. Data Analytics
    Narzędzia do data analytics zostały zmonopolizowane przez firmy będące producentami narzędzi do obliczeń, np. Databricks. Czy tutaj jeszcze coś się ruszy w najbliższych latach czy narzędzia już dostępne będą tylko zyskiwały na popularności?

  6. Machine Learning
    Zauważyłem, że bardzo ciężko dostać sensowną pracę w ML w porównaniu do innych technologii. Taka osoba zarabia też bardzo mało relatywnie do wiedzy, którą musi posiadać. Mało tego, wiele narzędzi zostało zmonopolizowanych przez frameworki za którymi stoją potężne firmy i nie bardzo da się tam wymyślić już niczego nowego jeżeli nie pracujemy na uczelni. Jeżeli pracujemy w małym dziale R&D to ciągle boimy się o pracę bo podniesienie precyzji algorytmu rekomendacji o kilka punktów procentowych jest bardzo kosztowne i rzadko kiedy się zwraca.

Zapraszam do dyskusji. Wybierz jakiś wątek podrzuć swoje odczucia.

2

Przecież już jest taki wątek: Jak będzie w 2025?

1

Problem w tym ze Python i JS wcale nie sa wolniejsze od Dżawy. Znam kogos kto twierdzil ze w serwisach typu lambda preferowane sa wlasnie te jezyki skryptowe ze wzgledu na czas uruchomienia funkcji.

Srodowisko dzżawowcow nie bez powodu rozwija GraalVm Native Image.

2
twoj_stary_pijany napisał(a):

Czy lepiej jest napisać backend webowy na JVM czy na wolniejszych technologiach typu Python, Ruby, JS dorzucając do tego load balancer?

To pytanie nie ma sensu. Zdecydowana większość softu i tak nie wykorzysta wydajności którą oferuje dany język, więc patrzenie przez pryzmat "szybkości" technologii jest bez sensu. Już pomijając fakt, że samą wydajność systemu można rozbić na kilka mniejszych czynników - ogólna wydajność systemu, wydajność konkretnych ścieżek biznesowych, wydajność specyficznych funkcji, możliwość zrównoleglania operacji i tak dalej. Ogólnie, w większości systemów, nie trzeba się przejmować szybkością języka bo szansa na to, że to on będzie bottleneckiem jest marginalna.

twoj_stary_pijany napisał(a):

Wiele osób po okresie fascynacji Scalą powraca do Javy ponieważ Java poszła do przodu z wieloma feature'ami ze świata funkcyjnego

Dopóki Java dba o kompatybilność wsteczną to nigdy nie będzie miała featureów, które oferują języki funkcyjne. To co dodaje się do Javy to podstawowe techniki, które po prostu sprawdzają się gdzie indziej - lambdy, pattern matching czy rekordy. Tak czy siak, jeśli ktoś przechodzi z powrotem do Javy to nie dlatego, że ma tam "featurey ze świata funkcyjnego" (których tak de facto nie ma), tylko dlatego, że jest znacznie więcej ofert pracy, często równie dobrze lub lepiej płatnych niż w Scali.

3

Masz i czaruj z kryształowej kuli:

0

Z innej perspektywy, jeżeli już będę miał 1000 użytkowników w tym samym momencie to chyba wydajność języka zaczyna mieć znaczenie.

Jeszcze zależy co robi te 1000 użytkowników, ale nie powinno to stanowić problemu dla jakiegokolwiek języka.

Co jeżeli strona nagle zyska na popularności w krótkim czasie?

W takim przypadku, programiści nie pisali projektu w taki sposób, żeby to poprawnie obsłużyć - nie było to krytyczne z punktu widzenia biznesu. Dlatego, zapewne architektura leży (pod tym względem) i albo można się starać jakoś ją dostosować, albo napisać od nowa. Tak czy siak - to nie jest problem związany z językiem, a architekturą.

Java jest po prostu zbyt duża by upaść i dlatego jest w niej tyle pracy czy jest obiektywnie najlepszym/najbezpieczniejszym rozwiązaniem do rozwijania nowych stabilnych rozwiązań?

I to i to. Java jest nowym COBOLem i samo utrzymanie już istniejących projektów spowoduje, że będzie popularna na rynku. Poza tym, jeśli powstaje nowy projekt to najłatwiej go rozpocząć w Javie - bardzo dużo programistów, koszt zatrudnienia relatywnie niski czy duży wybór technologii - ogólnie, duże bezpieczeństwo dla osób wykładających pieniądze

0
vpiotr napisał(a):

Problem w tym ze Python i JS wcale nie sa wolniejsze od Dżawy. Znam kogos kto twierdzil ze w serwisach typu lambda preferowane sa wlasnie te jezyki skryptowe ze wzgledu na czas uruchomienia funkcji.

Srodowisko dzżawowcow nie bez powodu rozwija GraalVm Native Image.

  • Python i JS są wolniejsze niż Java jak aplikacja jest już w pełni załadowana.
  • Python i JS mają krótszy czas wstawania aplikacji niż Java.

To są dwie zupełnie różnie rzeczy i nie powinieneś ich mieszać

0

Nawiązując do szybkości języków, ale już w temacie webdevelopmentu to wygląda na to, że JS wygrywa [1] w scenariuszu w którym liczymy ile maksymalnie zapytań możemy obsłużyć bez wykonywania skomplikowanych zapytań po stronie backendu. Przewaga ta na chwilę obecną wynika głównie ze stosowania asynców gdzie się da. Można więc przypuszczać szybką śmierć frameworków, które podchodzą do tego tematu inaczej. Z drugiej strony zasoby wykorzystywane na interpretowanie JavaScriptu mogłyby zostać użyte na bazę danych i jakieś obliczenia w locie. No bo przecież wyższą wartość dla biznesu ma 100 użytkowników, którzy mogą sobie przeglądać produkty w koszyku niż 10000 użytkowników, którzy co prawda mogliby zostać obsłużeni przez serwer http, ale ich zapytanie i tak jest zamulane przez bazę danych.

Moje odczucie trendów jest następujące. Skoro koszty clouda rosną tak szybko to być może rozsądniejszym byłoby po prostu optymalne używanie istniejących maszyn. Skoro dzisiaj i tak wszystkie aplikacje webowe stoją na linuksach to być może maszyna wirtualna jest niepotrzebna i takie języki jak Go, stworzone dla sieciowych rozwiązań, w przyszłości wyprą współczesne języki do webdevelopmentu?

Również aws lambdy wychodzą taniej kiedy są używane z Go na pokładzie [2].

Największy problem jaki widzę z Go jest taki, że ten język po prostu jest brzydki, przez co wygląda na skomplikowany.

[1] https://github.com/the-benchmarker/web-frameworks
[2] https://hackernoon.com/aws-lambda-go-vs-node-js-performance-benchmark-1c8898341982

1
vpiotr napisał(a):

Srodowisko dzżawowcow nie bez powodu rozwija GraalVm Native Image.

Oprócz wspomnianego GraalVM Native Image w planach jest jeszcze Project Leyden, który ma być standardem dla kompilacji AOT dostępnym także w zwykłym OpenJDKu. Ponadto w Javie 9+ jest dostępne narzędzie jaotc opisane w JEP 295: Ahead-of-Time Compilation, które działa na Linuksie/x64. Ogólnie jest coraz więcej opcji do przyspieszania startu.

0

Przyszłość jest już dziś, ale niestety nie jest ona pisana wszystkim.

Rich Hickey w jednej ze prezentacji "The Value of Values" żartobliwie NoSQL określił zdaniem "Twoja baza jest lepsza niż ta, która nam dałeś", chciał tu podkreślić ile wartościowych rzeczy biznes może wyciągnąć z logów.

Logi są interesujące, ale w dużej mierze mogą być niespójne, bo jeśli wycofałeś swoją transakcję? Co jeśli część danych jakie zapisałeś w logach to już tylko fikcja? Z datomic takie rzeczy nie mają miejsca.

Datomic bardzo przypomina topologię master-slave jaką znamy w PostgreSQL, ale jednoczesnie oferuje dostęp API do danych historycznych, to też łatwo pozwala odtwarzać sytuacje z produkcji. Zapytania łatwiej się pisze (nie ma problemu N+1, nie ma potrzeby stosowania blokad tak w PostgreSQL a mimo to masz spójne transakcje, do tego zapytania są utrzymywalne bo opisujesz w nim reguły, które możesz ze sobą składąć).

Obecnie używanie Datomic wiąże się z nie małym ryzykiem. Licencja jest droga 5000$ na rok (chociaż to nie tak dużo zestawiając to z programistycznymi rocznymi zarobkami), oprogramowanie ma zamknięty dostęp do źródła, i ostatecznie człowiek nie ma pewności czy taki amazon nie wykupi datomica. Akurat storage w postaci dynamodb fajnie zgrywa się z datomic więc kto wie czy tak nie będzie :-)

Myślę, że za 5 lat będzie taka podobna baza do datomic na znacznie szerszą skalę i spodziewam się, ze ona w znacznym stopniu zmieni sposób programowania backendu.

1 użytkowników online, w tym zalogowanych: 0, gości: 1