Kotlin+Spring - przyszłość czy feature?

0

Jak oceniacie kotlin w kontekście pisania backendu do stron internetowych, posiada on wiele funkcjonalności których tradycyjna javka nie posiada. Czy uważacie, że zostanie java zastąpiona kotlinem i właśnie on wraz ze springiem będzie ,,królował", czy może pozostanie jedynie pewnego rodzaju dodatkiem stosowanym od czasu do czasu w niektóych firmach?

1

o kotlinie dużo dobrego mówił @jarekr000000 i ja mu wierzę

0

Zdobywa coraz większą popularność ale do królowania mu jeszcze bardzo daleko

1

Kotlin to takie średnie zło (czyli w kontekście wszystkiego dookoła to nawet błyszczy na plus). Lepsze to niż frankenstein jaki się powoli robi z javy (no i obecna java nadal ssie ješli się pisze choć lekko fp kod). Pisze już prawie 2 lata w Kotlinie i nie znienawidziłem, a to naprawde nieźle.

Programistom natomiast życzę, aby jak najszybciej Spring wyleciał z mainstreamu. Z kotlinem jest on jeszcze bardziej bez sensu niż z javą.

0

To jaki framework, zamiast Springa?

Np. powiedzmy, że robię CMS na Javie.

0

Jeden CMS w miarę dobry w javie widziałem adobe aem. Masakrycznie drogi. Oparty jest o jackrabbit i apache sling i w sumie do cmsów to pasuje. Jakbym miał robić cms to pewnie bym od tego wyszedł.

0

Ok. A gdy robię tego CMS'a sam od podstaw (zamiast używać gotowego rozwiązania), to jaki framework byś wybrał?

0

posiada on wiele funkcjonalności których tradycyjna javka nie posiada

Trochę mitologia. Realnie jest tam raptem kilka elementów które faktycznie dają "nową jakość" jak np. sealed class. Reszta to syntactic sugar i oszczędność 2 linijek kodu.
Moim zdaniem Kotlin jest spoko, ale uważam, że wiele osób uzna że "nie warto", bo z jednej strony ryzyko pisania w jezyku który może umrzeć niedługo, a z drugiej strony benefity są niewielkie.

0

Od jakiegoś czasu w pracy piszę tylko w kotlinie i nie jest o jakaś duża rewolucja, ale przez dużą liczbę mały "wspomagaczy" jest całkiem wygodnie.

1
Shalom napisał(a):

Moim zdaniem Kotlin jest spoko, ale uważam, że wiele osób uzna że "nie warto", bo z jednej strony ryzyko pisania w jezyku który może umrzeć niedługo, a z drugiej strony benefity są niewielkie.

Totalnie się nie zgadzam. jak się przechodzi z javy to początkowo faktycznie może byc widać tylko mały syntax sugar.
Ale jak się już robiło dużo fp, albo się nabierze sie wprawy to robi się całkiem inny język, który naprawdę cięzko jest w javie symulować.

Przykłady:

  • function types - naturalne funkcje, nie trzeba wymyślać nazw interfejsów - całkiem zmienia styl pisania (koniec z bieda wzorcami OOP)
  • val i data classes - wszystko robimy immutable - wygodnie - całkiem inny styl pisania,
  • sealed classes, objects - mozna robić naturalnie i bezpiecznie ADT,
  • extension types
  • ...

Dla mnie dobrym przykładem jest spojrzenie jak wyglądają testy w KotlinTest (różne style testów i matcherów) - i weź zrób potem to w javie...

Generalnie kilka elementów - ale kilka z nich razem daje zupełnie inny styl (jak już się zacznie używać). Java wysiada.

0
forsberg napisał(a):

Ok. A gdy robię tego CMS'a sam od podstaw (zamiast używać gotowego rozwiązania), to jaki framework byś wybrał?

Pisałem wyżej w komentarzu.
Miałem do czynienia z kilkoma CMSami (Opencms, coremedia, Adobe AEM) nawet z PHP (joomla :-) ) i czymś na python/django.

Moja uwaga jest taka - do CMS SQL nie pasuje (dlatego tak mi się dobrze pracowało z adobe).
Ale nawet jak sie ma SQL to po prostu trzeba olać tzw. aspekt relacyjny. Wsadzamy bloby w tabelki i olewamy schematy na maxa. Strona to strona.

2
forsberg napisał(a):

Np. powiedzmy, że robię CMS na Javie.

Jak dla mnie to takie to trochę wyważanie otwartych drzwi ;)

0

Zamieńcie cms na dynamiczna stronę używajaca SQL. ;) Nie pytam stricte o cmsy, dlatego dopisałem “np.” ;)

0
forsberg napisał(a):

Zamieńcie cms na dynamiczna stronę używajaca SQL. ;) Nie pytam stricte o cmsy, dlatego dopisałem “np.” ;)

Dynamicznie to sobie wpiszesz kilka komend w fw php i masz, no chyba, że to dla zabawy to tam możesz poeksperymentować z czymś innym na luzie.

0

+1 dla Kotlina na backendzie, nie chce się wracać do Dżawy

1

mysle ze bardziej feature. dla konserwatywnych korpo-seniorow kotlin to kolejny wybryk natury, dla fp-neofitow to jednak troche za malo ;)

0

Kotlin + Spring zdecydowanie na plus. Nie wiem, czy się przyjmie, ale pracowałem jakiś czas w takim tandemie i pisało się bardzo dobrze. Teraz pracuję w tandemie Java (11, to jeszcze nie tak źle jak mogłoby być!) + Spring i pisze mi się w tym odczuwalnie gorzej. Przede wszystkim - może te "2 linijki mniej" w Kotlinie wydają się nic nieznaczącym pierdnięciem a nie ficzerem, ale mimo wszystko kod napisany w Kotlinie jest dla mnie zauważalnie bardziej zwięzły i bardziej czytelny, niż jego odpowiednik w Javie.

No i dochodzi jeszcze to, że Kotlin jako język z grubsza próbuje pomagać w pisaniu tak, żeby miało ręce i nogi i chociaż jako-tako się trzymało kupy. Masz data classy, masz null safety zaszyte w typach, masz te wszystkie lety i wheny o których ktoś już wspomniał, nie musisz się wydurniać z konwertowaniem listy, setu itp do strumienia i z powrotem by go sobie zmapować bo ups, framework może rzucić domyślnego nulla bo tak. W Javie trochę mnie wpienia, że muszę trzymać sobie w schowku null-check i szpachlować nim wszystko, żeby nie wybuchało NPE przy każdej okazji. Że muszę używać Lomboka, bo vanilla Java byłaby zawalona po brzegi getterami i setterami. Że trzeba odmieniać słowo Builder przez wszystkie przypadki, bo default/named parameters są dla frajerów, a Java jest dla gitów i tam musisz albo zaimplementować builder albo jak idiota rzeźbić 20 przeładowań konstruktora...

1

W uproszczeniu:
Jeśli piszemy projekt, w którym chcemy jak najbardziej zaoszczędzić na koszcie infrastruktury (high load, każda oszczędność CPU się liczy), wybieramy Javę
W przeciwnym wypadku Kotlin będzie przyjemniejszy dla całego zespołu.

Dochodzi też fakt, że developerów Java jest znacznie więcej niż Kotlina - może to być kluczowe kryterium w korpo. Wiadomo, że jak umiesz w Javę, to w kotlina będzie łatwo więc to kryterium jest słabe... choć nie do końca bo znam kilka przypadków, które konsekwentnie stosują Javowe podejście w kotlinie...

0

Kotlin i Spring to całkiem przyjemne połączenie (przynajmniej dla prostych przykładów). Kotlin usprawnia pewne elementy na poziomie samego języka, a Spring ułatwia na poziomie tworzenia aplikacji, liczę na dłuższą znajomość i ustabilizowanie się Kotlina w tej materii.

Mam takie śmieszne wrażenie, że wszyscy "hurr durr Spring zły!". Jestem ciekawy alternatyw z równie niską liczbą "vulnerabilities", z tak dużym community oraz szybkością tworzenia aplikacji. Czas start, liczę, że mnie zaskoczycie ;)
(Jest Micronaut, ale jeszcze zbyt świeży na prawdziwe projekty, I guess)

0
Burdzi0 napisał(a):

Kotlin i Spring to całkiem przyjemne połączenie (przynajmniej dla prostych przykładów). Kotlin usprawnia pewne elementy na poziomie samego języka, a Spring ułatwia na poziomie tworzenia aplikacji, liczę na dłuższą znajomość i ustabilizowanie się Kotlina w tej materii.

Mam takie śmieszne wrażenie, że wszyscy "hurr durr Spring zły!". Jestem ciekawy alternatyw z równie niską liczbą "vulnerabilities", z tak dużym community oraz szybkością tworzenia aplikacji. Czas start, liczę, że mnie zaskoczycie ;)
(Jest Micronaut, ale jeszcze zbyt świeży na prawdziwe projekty, I guess)

Nie da się zaskoczyć bo technologię wybiera się do problemu ;) Spring jest często nadużywany i dodawany "bo tak trzeba" nawet jeśli jedynym featurem którego się użyje w całym projekcie to kontener DI (który jest zupełnie niepotrzebny.

Co do technologii (co prawda nie Java czy Kotlin, a Scala) to fajnym rozwiązaniem jest na przykład http4s. Ładny DSL, promuje pisanie w FP, zbudowany jest na fs2 więc oferuje bardzo duże możliwości związane ze streamami i kilka innych ciekawych do poczytania możliwości :) Wszelkie brakujące funkcjonalności pewnie dodałbym innymi, małymi biblioteczkami bez dodawania żadnego framework'u.

0

@Burdzi0: jw. zależy co chcesz zrobić. Jeśli proste api które czyta cos z bazy to javalin/ratpack + jooq starcza całkowicie (i nagle okazuje się, że apka może startować w 300ms zamiast 4 sekund)

0

@danek: Okej załóżmy że taki stack wybieram (mimo, że ratpacka ani javalina na produkcję bym nie wziął skoro mam webfluxa i jetty, a jOOQ mnie odstrasza składnią, nie do końca z ich strony wynika jaki poziom abstrakcji oferuje - moja opinia). Potrzebuję security - co wybierzesz? Potrzebuję mailowego API oraz coś na wzór open feigna. Zobacz że składasz taki stack, że w trakcie szybkiego rozwoju nagle masz 20 najróżniejszych zależności (które możesz dostać w jednym frameworku). Co do JSONa? (Pewnie Jackson). Co mi wygeneruje tak sprawnie repozytoria? Czym będę to testować jeśli mam testy integracyjne? Gołym HTTP klientem?

2

Jako osoba pracująca w firmie, gdzie część zespołów używa Javy, a część Scali wolałbym aby ci od Javy przenieśli się na Kotlina - zawsze to krok w dobrym kierunku.

Natomiast dla mojego zespołu, który robi w Scali, Kotlin jest zupełnie nieatrakcyjny. Ma parę fajnych drobiazgów, ale brakuje w nim tych rzeczy, które przenoszą kod na zupełnie inny poziom abstrakcji jak implicit objects, HK types czy makra.

No i jeszcze klasyczne powody używania Kotlina już nie są aktualne:

  • Narzędzia: IDE / edytory do Scali są równie dobre co do Kotlina i jest ich więcej (nie tylko IJ), a do tego Scala wspiera standard LSP a Kotlin nie i nie ma w planach
  • Szybkość kompilacji: Scala z Bloopem miażdży szybkością kompilacji nawet... Javę z Gradlem. Kotlin nie ma niczego porównywalnego.
  • Scala 2.12 używa lambd z Java 8, więc kompatybilność Java - Scala jest na tym samym poziomie co Java - Kotlin
1

Po pierwsze @Krolik : czemu Cie nie ma na scalaworld? a jest godnie

20190902_201853.jpg

Faktycznie, szybkość kompilacja Scali w ostatnich latach stała się znośna, dzięki otymalizacjom i narzedziom (hydra), ale raczej bym nie ścigał się na milisekundy z kotlinem. Jedno z założeń Kotlina to szybka kompilacja, dlatego jest (i bedzie) bardziej prymitywny. Z gradlem też zresztą ładnie działa i to w ciągłym buildzie (tyle, że jak sie pracuje w Intellij to już i tak jest w zasadzie kompilacja jest natychmiastowa).

Co do kompatybilności - ze scali wywołasz bez problemu każdy kod w javie, oczywiście w kotlinie tożsamo.
Problem jest w drugą stronę - w scali jeśli chcesz zrobić sensowne API javowe to prawie zawsze musisz napisać wrappera (inaczej to API nie będzie efektywne w Scali). Z kolei ponad 90% tego co robisz w kotlinie od razu działa z javą (dla 100% trzeba minimum uwagi zachować).

@Burdzi0
Po pierwsze to wcale nie jest tak dobrze mieć jedną zaleźność... Jak mam 20 bibliotek od różnych rzeczy to wymiana jednej z nich zwykle nie boli bardzo (np. jak zrobimy sobie lepszą perzystencję). W Springu czy takim Java EE migracje to często bolesny process - musisz często zrobić pełen skok całym kodem(*). I nawet jeśli masz ładnie opisane kroki to potrafi boleć.
(przechodzenie ze Spring 3 na 4 pamietam jako niezły koszmar w kilku projektach, a zależało nam tylko na jakimś małym kawałku ze Spring4).
(*)Ze Spring4 do Spring5 udało sie w jednym projekcie zrobić Frankensteina, który miał trochę bibliotek ze Spring4 a troche ze Spring5, ale to raczej cud, że to działało.
Migracja do innej platformy to już w ogóle masakra.

Bezpieczeństwo Springa jest ułudne, mając security oparte na magii w zasadzie nie możesz ufać, że to zawsze zadziała, jeden fałszywy ruch i nic nie jest sprawdzane. Ale fakt, że sam spring jako projekt jest wysokiej jakości.
Dla mnie to troche jak jquery czy dom (web) - dziur mają mało, ale programowanie z ich użyciem (bezpośrednio) to spacer po polu minowym.
Przeżyłem kilka integracji Springa i Java EE z rozwiązaniami LDAPopodobnymi i kerboropodobnymi klientów. Jak masz standardowy LDAP to podłączasz moduł i jest prosto, ale jak klient ma coś dziwacznego - nagle okazuje się, że musisz się napisać strasznie dużo dziwnego kodu () - dużo więcej niż gdyby po prostu wywoływać odpowiednie API.

Jest duży promyk nadziei jakkolwiek, - dzięki webflux i czyszczeniu springa (moduły springa na szczęście wewnętrznie już prawie nie używają springa) coraz więcej ze spring da sie wykorzystywać jako funkcje - bez magii. Dla mnie to idealnie: duża biblioteka gotowych rozwiązań dla biznesu. Problem, że obecne dokumentacje i przykłady nie pokazują tego typu rozwiązań i trzeba sobie w kodzie Spring poszukać klas, (albo dopytać autorów).
(Nawet SpringData da się wykorzystywać be skanowania klas i beanów - chociaż SpringData to zuoooo :-) ).

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