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?
Kotlin 
Java 
- Rejestracja:prawie 10 lat
- Ostatnio:ponad 4 lata
- Lokalizacja:Piwnica
- Postów:7697
1
o kotlinie dużo dobrego mówił @jarekr000000 i ja mu wierzę
- Rejestracja:ponad 8 lat
- Ostatnio:około 4 godziny
- Lokalizacja:U krasnoludów - pod górą
- Postów:4707
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ą.
edytowany 3x, ostatnio: jarekr000000
- Rejestracja:ponad 8 lat
- Ostatnio:około 4 godziny
- Lokalizacja:U krasnoludów - pod górą
- Postów:4707
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ł.
edytowany 1x, ostatnio: jarekr000000
- Rejestracja:około 21 lat
- Ostatnio:prawie 3 lata
- Lokalizacja:Space: the final frontier
- Postów:26433
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.
Zobacz pozostałe 7 komentarzy
No chyba jasne ze chodzi o skladnie
A jesli to sie nie liczy to rownie dobrze mozna pisac w assemblerze, hah
Dobra, nie chce mi się https://media.tenor.com/images/36e2f86ffaa3d8140a6ea33d864e3914/tenor.gif
Idz juz sie schowaj z Twoimi madrosciami :D
- Rejestracja:ponad 8 lat
- Ostatnio:około 4 godziny
- Lokalizacja:U krasnoludów - pod górą
- Postów:4707
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.
edytowany 1x, ostatnio: jarekr000000
- Rejestracja:ponad 8 lat
- Ostatnio:około 4 godziny
- Lokalizacja:U krasnoludów - pod górą
- Postów:4707
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.
edytowany 1x, ostatnio: jarekr000000
Zobacz pozostały 1 komentarz
Primo - to raczej w SQL proste rzeczy zajmują dużo czasu. Po drugie: https://www.thoughtworks.com/radar/platforms/cms-as-a-platform to jest antypattern. W momencie jak widać, że przestajemy robić CMS to trzeba zmienić technologię i praktyki. Inaczej kupa (widziałem to w praniu).
Tak to rzeczywiście teoretycznie wygląda. Mówisz inwestorowi / właścicielowi: dobra, wy chcecie zrobić to i to, ale trzymanie CMS nie ma sensu w takim wypadku! Musicie zrobić to na frameworku, polecam X! I słyszysz w odpowiedzi: no wiesz, my do tego podchodzimy czysto biznesowo, a poza tym jesteśmy przywiązani bardzo do modułu Y i sposobu obsługi Z, a ten admin w tym twoim frameworku wygląda gorzej :P Widziałem to w praniu, walczyłem długo, ostatecznie szkoda było zachodu...
Czytaj: w 99% prawdopodobnie jesteś skazany na SQL. BTW dzięki za link, pokażę go przy najbliższej okazji :D (Wątpię jednak, czy przyniesie sukces :D ).
"skazany na SQL" - najczęściej z powodu cieżkości umysłowej tylko. Ale ostatnio u jednego klienta zrobiłem patent taki, że najpierw zrobiłem tool bez bazy (event sourcing domowy), a jak trochę pochodził i wyszło, że ktoś będzie chciał raporty to przemigrowałem się częsciowo na SQL (tylko statystyki) (ale przez to klient jest już przyzwyczaja się, że nie zawsze będzie SQL :-) ).
Gratuluję w takim razie zdolności przekonywania. Z doświadczenia, zazwyczaj jest tak, że gdy się okazuje, że trzeba podejmować decyzje co do technologii, klient zakłada, że wybierzesz "najlepszą". :) A gdy pytam: najlepsza zależy od punktu widzenia, i tego co planujecie - a więc co planujecie? To słyszę: tego jeszcze nie wiemy, dlatego może pozostańmy przy obecnej technologii, przy okazji nie będzie trzeba dużo zmieniać! :P (wg. zleceniodawcy)
- Rejestracja:prawie 10 lat
- Ostatnio:ponad 4 lata
- Lokalizacja:Piwnica
- Postów:7697
2
forsberg napisał(a):
Np. powiedzmy, że robię CMS na Javie.
Jak dla mnie to takie to trochę wyważanie otwartych drzwi ;)
Ale w javie:-) więc przynajmniej hosting będzie drogi.
- Rejestracja:prawie 10 lat
- Ostatnio:ponad 4 lata
- Lokalizacja:Piwnica
- Postów:7697
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.
Mądrala, który marnuje czas sobie i innym ;)
- Rejestracja:około 17 lat
- Ostatnio:około 15 godzin
- Postów:1874
0
+1 dla Kotlina na backendzie, nie chce się wracać do Dżawy
Czemu nie chce?
Dużo usprawnień, szybciej się pisze i czytelnie to wygląda. Data classy, expression function, instrukcja „when”, „let”, ... można by wymieniać.
To chyba podobne uczucie, jak ja miałem, kiedy na studiach wreszcie zakończyłem etap c/c++ i rozpocząłem javę. I tylko raz wróciłem do tego pierwszego, przy 1 małym projekcie: od razu zrozumiałem, jakim kamieniem milowym była java, gdy powstała.
- Rejestracja:prawie 7 lat
- Ostatnio:2 dni
- Lokalizacja:Kraków
- Postów:1999
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...
edytowany 1x, ostatnio: superdurszlak
Zobacz pozostałe 3 komentarze
Po prostu pisałem w jednym, piszę w drugim i odczuwam różnicę na niekorzyść Javy.
szczególnie jak spojrzy się z perspektywy C, C++ to java jest do kitu z deszczu pod rynne :]
Ja bardzo przepraszam, ale jak się spojrzy z perspektywy LLVM IR czy assemblera platform RISC-owych to C/C++ jest żałosną abominacją :v
To na czerwono to cytat :p
Wiem, po prostu przeoczyłem oryginał jak odpowiadałem za pierwszym razem :D
- Rejestracja:prawie 10 lat
- Ostatnio:około 14 godzin
- Lokalizacja:Lublin
- Postów:171
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...
edytowany 5x, ostatnio: qbns
Zobacz pozostały 1 komentarz
Proponuje zawsze wybierać PHP. Developerów PHP jest wiecej niž javy. No i język spoko.
@baant odpowiedź brzmi chyba, jak zwykle, "to zależy" - wykopane z komentarzy na SO: https://sites.google.com/a/athaydes.com/renato-athaydes/posts/kotlinshiddencosts-benchmarks
Martwienie się wydajnością jako jedno z głównych kryteriów wyboru języka, tak powstają najfajniejsze projekty :)
Heh, jak przeczytałem mojego posta to rzeczywiście brzmi pro-javowo choć nie do końca było to moim zamiarem. Co do korpo-kryterium o którym wspomniałem - jest ono faktem, niewygodnym dla devów, ale często jest traktowane przez management jako ryzyko - spotykane u lepiej płacących pracodawców, więc nie zawsze argument "to znajdź pracę w innej firmie" będzie tak oczywisty :D
- Rejestracja:prawie 9 lat
- Ostatnio:5 miesięcy
- Lokalizacja:Futurama
- Postów:887
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)
edytowany 1x, ostatnio: Burdzi0
- Rejestracja:prawie 10 lat
- Ostatnio:6 miesięcy
- Postów:141
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.
Technologia jest często wybierana, bo... zwyczajnie brakuje ludzi do innej. Z pkt. widzenia HR: zrobisz projekt w jakimś niszowym systemie, a później okaże się, że pół roku na próżno szukasz ludzi do niego. Takie są fakty zaobserwowane przynajmniej w mojej okolicy, bez względu na język.
- Rejestracja:prawie 9 lat
- Ostatnio:5 miesięcy
- Lokalizacja:Futurama
- Postów:887
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
edytowany 5x, ostatnio: Krolik
- Rejestracja:ponad 8 lat
- Ostatnio:około 4 godziny
- Lokalizacja:U krasnoludów - pod górą
- Postów:4707
1
Po pierwsze @Krolik : czemu Cie nie ma na scalaworld? a jest godnie
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 :-) ).
- 20190902_201853.jpg (4 MB) - ściągnięć: 78
edytowany 4x, ostatnio: jarekr000000
Nasze doswiadczenia z szybkością kompilacji czystej Javy w Gradle są dość negatywne. Zapewne kwestia wielkości projektu. Ten sam projekt Javowy (!) stackiem Scali kompiluje się od 3x szybciej (całość, bez kompilacji przyrostowej) do 150x szybciej (kompilacja przyrostowa) od Gradle. Faktycznie, może na milisekundy nie ma się co ścigać, ale po prostu czas kompilacji Scala nie jest już żadnym problemem w praktyce, pod warunkiem zastosowania dobrych narzędzi. W czystym Gradle jest tragedia, w Bloopie jest poezja. Uczucie jest takie, jakbym pracował w Pythonie :)
"czemu Cie nie ma na scalaworld?" Bo tak jakoś w Javie ostatnio klepię i boję się, że by mnie pogonili :D
@Krolik - ja już w Scali od kilku miesięcy linjki nie napisałem (kotlin). Do tego jest tu kilku programistów Haskella, którzy co chwila opowiadają jaki to mają fantastyczny dzień, bo nie piszą w scali.
niesmak pozostał