Przyszły backendowiec - Java vs C#? - dylemat, przyszłość obu języków, warunki pracy

Dylemat? Większy dylemat to opieranie swojej pozycji bądź przyszłości o sam język. Ten kto szuka prostej i wygodnej drogi płynie później jak śmieci z prądem.

Ech.. jeden ze smutniejszego typu wątków, gdzie problem zawsze wraca jak bumerang, a jedyne co z tego wynika to nieodwracalna strata czasu (przede wszystkim naszego, własnego... ale jak tak teraz zerkam na frekwencję, to odnoszę lekkie wrażenie, że po drodze, także i innych, naszych drogich forumowiczów wraz ze mną xD), często połączoną z późniejszą demotywacją do robienia czegokolwiek. Także @Edelner: 'I know that feel bro'.

Które IDE? Jaki edytor tekstowy? Windows czy raczej Linuks? Spacje czy taby? Schabowe czy mielone? Odpowiedź na to ostatnie uświadomiła mi, że - a może najlepiej oba?! ;) # Podobne tematy, które zawsze powinny zapalać czerwoną lampkę: 'tracisz po prostu czas i fun z całej zabawy'.

Przyczyna? A no najprostsza. Czego to się nie zrobi, aby uciec od pracy, tym bardziej nie tak znowu lekkiej. Podoba mi się podejście w tej kwestii np. u Georga Hotza. Gdzieś tam w czeluściach internetów stwierdził, że dobry programista to przede wszystkim skille (czasem nawet nie te stricte techniczne) i umiejętność tworzenia konkretnych rzeczy (projekty). Jednym z największych błędów jaki można popełnić na początku to chłonięcie filmów/tutoriali/książek typu: jak nauczyć się programować czy jaki to język mam wybrać. Także można spytać: jakie to skille? Mówisz - wyświechtany 'Backend'? Trochę zawęża to temat, ale OK. Ktoś nawet z tego forum już podrzucał: https://github.com/kamranahmedse/developer-roadmap

Wszystko z tej listy odhaczone? Umiesz sprawnie zrobić jakiś praktyczny (chociażby szkic) projektu sklepu, systemu aukcyjnego, platformy streamingowej (Java/C# to pewnie raczej jakieś giełdowo-bankowe zabawki, systemy ubezpieczeniowe czy inne ERP, więc trzeba to sobie rozbić na jakieś małe moduły)? Przebijanie się przez duże połacie kodu i szybkie ogarnięcie OCB, debugowanie i testowanie (lokalne, zdalne), OOP & functional programming, coś na kolejkach, webservice'y, dobra znajomość jakiegoś OS (np. oskryptowywanie jakiejś żmudnej roboty, monitorowanie procesów, pamięci, ogólnie tego co tam słychać na dysku, analiza logów), sieci (uaa!), bazy danych (optymalizowanie, backupy,)... no i tak bez końca. Jak się tak temu wszystkiemu przyjrzeć to wszystkie te rzeczy nie będą się tak drastycznie różnić się w zależności od tego czy to Java, C#, Python, Ruby czy co tam wolisz (to tylko na pocieszenie, bo i tak musisz wybrać jedno :P). Co prawda graf też zawiera tam konkretne języki, ale tak to już jest u Backendowca, że na widok np. JS czy innego Python/Bash nie powinno się od razu chować pod biurko.

Plusik dla @iddqd za najważniejszą uwagę w tym wątku. Angielski powinien byc chyba pierwszym skillem jaki się ma zanim w ogóle zaczynamy zabawę w IT (to było już wiadome w 2012 wraz Awesome Java Developer - btw. jeśli wybierzesz Javę, to pozycja obowiązkowa). Na Google Translate daleko się nie zajedzie. Sam żałuję, że tak późno zacząłem z tym tematem. Dzisiaj? Ludzie to już i dwa ogarniają i się nie chwalą (nie wspominając o najmłodszych, gdzie tata Brazylijczyk, mama Włoszka, a mieszkają w PL i dzieciak chodzi dodatkowo na lekcje angielskiego i niemieckiego). Książki zbyt często nie nadążają już za szybkimi zmianami i jakikolwiek sens mają tylko te traktujące o sprawach względnie stabilnych (clean code, wzorce, algorytmy, architektura itp.). Kodowanie ze wsparciem, czy tego chcemy czy nie, najczęściej anglojęzycznej dokumentacji (jakiej kuffa dokumentacji?! - podirytowany Team Leader) to raczej kluczowa sprawa i trza się tego po prostu nauczyć. Szczególnie teraz większość cennych materiałów/opinii/postów/książek, które regularnie wyskakują z ekranu produkowane są po angielsku (nawet jeśli tworzy je Polak). A co z kolegami z pracy? Co drugie słowo chcesz 'na migi' okraszone sentencją 'well, you know...'? IMHO, brak języka to najprostsza droga do janusz softów czy innego legacy-fullannotation-spaghetti kodu. Btw. legacy i koprokod (oraz umiejętne babranie się w nim) to tez 'skill' (ba! i to nie byle jaki) i wypada coś tam wiedzieć w tym temacie by nie skończyć jak ta baletnica, której to...

**TLDR. **Dobry coach pewnie powiedziałby: 5 min. na wybór, siadaj, i koduj, koduj, koduj. Jesteś na studiach, więc już pewnie sporo wiesz i masz jakieś osobiste preferencje, więc 5 minut to zdecydowanie za długo ;)

Także podsumowując. O przyszły komfort ze znalezieniem pracy (jeszcze tam gdzie chcę) to bym się martwił, jakbym wybierał miedzy VHDL a Verilogiem ;) W światku Java i C# to nawet w mniejszych miastach nie powinieneś mieć większego problemu z ssaniem na programistów. Zawsze masz jeszcze opcję pracy za granicą. Wielu mówi: wybierz jedno i leć naprzód (dodam - choćby i na ścianę!). Dwa naraz, w przypadku tak dużego ekosystemu jakim jest świat oczami Javy i C# może niestety oznaczać - żadnego wcale.

Edelner napisał(a):

Co do C# to podoba mi się, to, że składnia jest trochę bardziej przejrzysta i nowoczesna, wsparcie MS i to, że .NET stał wieloplatformowy oraz to, że próbuje objąc różne dziedziny, backend, apki mobilne, gry, teraz przez tego Blazora chyba frontend też, więc C# wydaje mi się taki bardziej wszechstronny i bardziej przyszłosciowy.

W grach to chyba używa się wskaźników, no nie?

WeiXiao napisał(a):

co z tymi wskaźnikami których to używa się w bardzo specyficznym kodzie? czyt. raczej nie spotkasz ich w enterprise™

Bardzo specyficzny jest podobno C# w notorycznie zachwalanym silniku Unity (w którym tworzy się te gry), który nie jest takim modelowym C# tylko raczej takim zgwałconym i rozdeptanym dialektem a'la MISRA C czy jakiś inny Cobol.

Gry i apki mobilne tworzy się też w Javie. Android Javą stoi.

Blazor ma dwie wersje, obie ciężkie:

• Blazor Server gdzie serwer musi utrzymywać ciężką sesję, a każde pierdnięcie na froncie (np klikanie po GUI czy dynamicznie aktualizacje) to strzał do backendu
• Blazor WebAssembly gdzie rozmiar hello world dalej liczy się w megabajtach nawet po kompresji (chociaż parę miesięcy nie sprawdzałem, zmieniło się coś?)

Kiedyś była Java na frontendzie. Nazywało się to https://en.wikipedia.org/wiki/Google_Web_Toolkit i był na to hype pewnie większy niż na Blazora. Zostało jednak zjedzone przez SPA w JSie i w zasadzie słusznie. Mając jakikolwiek nietrywialny UI w końcu natrafisz na trudne zadanie przesunięcia buttona o 5px w prawo (ale takiego hardkorowego, który ma 5 konfliktujących styli CSS). Zdoktoryzujesz się we frontendach i w końcu tego buttona z dumą przesuniesz. Czy jednak to osiągnięcie jest warte czasu spędzonego na nauce dziwactw frontendu? Obstawiam że nie i że lepiej zostawić to zawodowym frontendowcom, którzy polyfille do Internet Explorera i stopień niezaimplementowania standardu CSS w przeglądarkach pamiętają nawet po pijaku.

Znakomita większość roboty zarówno w Javie jak i C# to backend wystawiający REST API. Java i C# kopiują od siebie i prowadzą wyścigi kto więcej nawali refleksji (do porzygu). Kiedyś była stronka wyśmiewająca adnotacje, ale teraz szukam "java annotation mania" i nic znalazłem (może firewall firmowy mi blokuje).

Wieloplatformowość .NET jest do pewnego stopnia ograniczona (zależy na czym komu zależy), bo WinFormsów, WPF i innych oficjalnych GUI wchodzących w skład .NETa nie ma na platformach innych niż Windows.

Co do trudności wbicia się w rynek Javowy (czy też niejavowy) to podstawą do życia jest przede wszystkim nieprzespanie stażów dla studentów. Trzeba walić na staże wakacyjne (+ nawet więcej jak się uda) jak najwcześniej, by podczas rekrutacji mieć kartę przetargową (w postaci doświadczenia komercyjnego) i lepszy wybór ofert. Ja to byłem stażystą 10 lat temu, więc to zupełnie inne dzieje były, ale z tego co pamiętam to na staż dostawali się i zostawali później przyjmowani na stałe nawet dość kiepscy programiści. Najwięcej żalu mają absolwenci studiów, którzy ominęli wszystkie staże w korpo, a po obronie magisterki obudzili się z ręką w nocniku i dziwią się, że z pustym CV nie mogą dostać pracy na cały etat.

scibi92 napisał(a):

@somekind: to jest Twój punkt widzenia. Jeśli dla Ciebie to że musisz napisac stream przed map jest robi taką różnice że nawet o tym piszesz to cóż...

Dla niektórych problemem jest zaczynanie używania wielkich liter w nazwach metod, albo układ klamerek.
Ten stream po prostu moim skromnym zdaniem wygląda dziwnie zbędnie.

Mnie w Kotlinie zainteresowały elementy których nie było kilka lat temu w C# a i nadal nie ma. C# 9 ma rekordy, a Kotlin miał kilka lat temu. Kotlin ma val, C# i Java mają tylko var. W C# nie ma sealed class itp.

C# nie ma wielu fajnych rzeczy. Wiele ma słabych. Ale ani ja nie twierdzę, że to jest język doskonały, ani go nie polecam, ani z Kotlinem nie porównuję. Po prostu C# jest wystarczająco dobry do rozwiązywania dość szerokiej klasy problemów, a do tego używanie go nie sprawia aż takiego bólu, aby istniała powszechna potrzeba stworzenia jakiejś alternatywy. Na JVM najwyraźniej taka potrzeba była, skoro alternatywy powstały. Nie rozumiem co jest takiego strasznego w stwierdzeniu tego.

A tak w ogóle, to czy ktoś tu o Kotlina pyta?
Bo skoro nie, to to wygląda na jakiś syndrom studenta prawa. :P

scibi92 napisał(a):

Słowo kluczowe: raczej. Niepotrzebny element jeśli język ma być wysokopoziomowy.

Język powstał 20 lat temu i pierwotnie służył m.in. do integracji z kodem w C/C++, więc te wskaźniki były chyba przydatne. 99,5% programistów pewnie nigdy tych wskaźników nie użyła, podobnie jak wielu innych mechanizmów języka. I myślę, że z wieloma (jeżeli nie wszystkimi) językami jest podobnie - pewnych elementów używa się na co dzień, innych ekstremalnie rzadko, ale zazwyczaj nie jest to powodem do usuwania tych niepopularnych elementów z języka.

@somekind pokazywał jak można rozwalić generyki w Javie przez stosowanie raw Collection, i jakoś go nie obchodziło że nikt tego nie robi.

Ale ja nie próbowałem udowodnić, że ktoś tak robi, tylko że kompilator nie rozumie systemu typów i nie ma żadnej godności. Porządny kompilator by do tego nie dopuścił. Gdybym był kompilatorem Javy, to po czymś takim bałbym się matce w oczy spojrzeć.

Nie chce mi się kłócić czy Java czy C# są lepsze, po prostu śmieszy mnie podejście niektórych osób w nim piszących.

Mnie z kolei śmieszy podejście ludzi, którzy zawsze bronili kontenerów IoC konfigurowanych w XMLu jak zakonnice dziewictwa, a ostatnio coś się im odmieniło i twierdzą, że najlepiej w ogóle kontenerów IoC nie używać. Albo tych, co się śmiali od 2007 do 2013 roku, że LINQ w C# to zbędny cukier składniowy i nie ma nic lepszego niż pętla, a potem zaczęli się podniecać rewolucyjną nowością, jaką są streamy w Javie.
Ale już to, że ktoś wszędzi widzą jakieś zagrożenie i ataki na swoje ulubione technologii oraz polecanie konkurencji tam, gdzie tego nie ma, to już mnie nie śmieszy tylko smuci.

@somekind: Scala na przykład powstała i na JVM i na CLR, tylko że były problemy z utrzymaniem jej na CLR, więc ten argument jest inwalida.
Dodatkowo pomijasz fakt że przez długi czas CLR działał tylko na Windowsie, więc to raczej nie zachęcało do tworzenia języków opartych na tą maszynę wirtualną. A ja w 2007 ani nawet 2013 nie wiedziałem co to kontener IOC, możesz powiedzieć kto więc zachwalał kontenery IOC w XML a teraz mówi że wszystkie kontenery są złe?

Ale ja nie próbowałem udowodnić, że ktoś tak robi, tylko że kompilator nie rozumie systemu typów i nie ma żadnej godności. Porządny kompilator by do tego nie dopuścił. Gdybym był kompilatorem Javy, to po czymś takim bałbym się matce w oczy spojrzeć.

Jak chcesz żeby nie dopuścił to trzeba zajrzeć do helpa. javac -Xlint:unchecked -Werror sprawdza problemy z generykami i przerywa kompilację jak znajdzie. Oczywiście, jak ktoś się uprze to obejdzie i te zabezpieczenia, ale to nie moja wina, że ktoś bardzo chce strzelić sobie w stopę. Chcieć to móc (w każdym języku można pożegnać się ze stopą).

Z doświadczenia to taki NullPointerException zdarza się co najmniej 100x częściej niż te wydumane problemy z generykami, więc jak dla mnie wywalenie nulla z domyślnego typu referencji byłoby znacznie większym postępem niż generyczne wariacje a'la Java vs C#.

scibi92 napisał(a):

@somekind: Scala na przykład powstała i na JVM i na CLR, tylko że były problemy z utrzymaniem jej na CLR, więc ten argument jest inwalida.

Ale argument nie brzmi, że na CLR nie ma ani nie było innych języków (bo jest całkiem sporo), tylko że nie było ani nie ma dużej potrzeby tworzenia zamiennika dla flagowego języka tej platformy.

Dodatkowo pomijasz fakt że przez długi czas CLR działał tylko na Windowsie, więc to raczej nie zachęcało do tworzenia języków opartych na tą maszynę wirtualną.

Jakoś niespecjalnie widzę związek. Kogo zniechęcało? Czy teraz ktoś jest zachęcony?
Gdyby C# był okropny, to albo ludzie przesiedliby się na inny dostępny (VB, F#), albo powstałby dla niego zamiennik, albo platforma zostałaby porzucona. Żadne z tych jakoś nie zaszło.

A ja w 2007 ani nawet 2013 nie wiedziałem co to kontener IOC, możesz powiedzieć kto więc zachwalał kontenery IOC w XML a teraz mówi że wszystkie kontenery są złe?

Największe sławy i idole Javowego świata. :)

@somekind:
No cóż ja jestem pewien że jakbym programował w C# to bym się F# zainteresował.
Java też nie jest porzucana, a innymi językami interesują się głównie młodzi ludzie otwarci m.in bardziej na FP.

Imho projekt Loom bedzie kolejnym przełomem w Javie, Kotlinowe corutines moga sie schowac a wszystkie frameworki RFP beda sie musialy zaaktualizowac, wlacznie z serwerwowymi libkami albo odejda w zapomnienie. Juz mamy system aktorowy oparty o Loom https://github.com/lucav76/Fibry
Valhalla, record i sealed classy tez juz na horyzoncie :P Inna sprawa jest ofc, wdrozenie tego na produkcje w wiekszosci firm ;)

somekind napisał(a):

scibi92 napisał(a):

@somekind: Scala na przykład powstała i na JVM i na CLR, tylko że były problemy z utrzymaniem jej na CLR, więc ten argument jest inwalida.

Ale argument nie brzmi, że na CLR nie ma ani nie było innych języków (bo jest całkiem sporo), tylko że nie było ani nie ma dużej potrzeby tworzenia zamiennika dla flagowego języka tej platformy.

Oracle też nie widzi potrzeby tworzenia zamiennika (albo przynajmniej o tym nie mówią). To nie Oracle tworzy te "zamienniki". Scala nie powstała z namaszczenia twórców Javy. Bardziej dlatego, że Odersky nie wepchałby do Javy wszystkich swoich pomysłów i dlatego stworzył nowy język (historia: https://en.wikipedia.org/wiki/Pizza_(programming_language) ). Potem zatrybiło i Scala jest w miarę znana. Kotlin powstał jako "bardziej praktyczna" (albo bardziej przyjazna dla noobków?) alternatywa dla Scali stworzona przez JetBrainsów (czyli też nie Oracle czy Sun) + były oczywiście inne powody. Na .NETa też powstawały jakieś niezależne języki, np Nemerle, ale to niespecjalnie zatrybiło i w konsekwencji zdechło. F# (aka OCaml#) niby żyje, ale co to za życie? :P

C# ma bardzo dużo bajerów, więc wielu osobom coś się spodoba. To ma jednak tę wadę, że język staje się przesadnie złożony, bo C# ma nacisk na utrzymywanie wstecznej kompatybilności i to daleko wstecz. Java rozwija się wolno, ale za to dalej jest prosta (pomijając generyki: "We simply cannot afford another wildcards" - Joshua Bloch). Scala rozwija się szybko, ale dzięki ograniczonej kompatybilności wstecznej zbędne czy nietrafione pomysły z przeszłości są wyrzucane.

@Wibowit:
Java rozwijała się wolno ale już teraz rozwija się dużo szybciej dzięki wydaniom co 6 miesięcy.

scibi92 napisał(a):

No cóż ja jestem pewien że jakbym programował w C# to bym się F# zainteresował.

F# to taki trochę poligon dla rzeczy, które potem wchodzą do C#, jeśli są wystarczająco mainstreamowe.

innymi językami interesują się głównie młodzi ludzie otwarci m.in bardziej na FP.

Czy ta opinia bazuje na tym, że znasz takich ludzi i są to Twoi rówieśnicy?

Wibowit napisał(a):

C# ma bardzo dużo bajerów, więc wielu osobom coś się spodoba. To ma jednak tę wadę, że język staje się przesadnie złożony

Owszem, pisałem o tym już wiele razy. C# już jest przesadnie złożony i zaczynanie w nim to objaw lekkiego masochizmu, bo trzeba się nauczyć, czego nie używać, a czego używać, a tych nieprzydatnych rzeczy jest jakieś 2 razy więcej.

Taaaak, przypuszczam gramatyka (analiza syntaktyczna) C# jest ze 3x większa niż Javy, do każdej nowej rzeczy nowy sytnax.
W Javie wiele zmian ma formalny charakter kropka-metoda (np lambdy).

Co do analizy syntaktycznej Javy, z mojego punktu widzenia (który zależy jak wiadomo ... ) najbardziej zniechęca brak syntaxu i koncept "property by convention". I byle biblioteka do teplejtowania stringów dokonuje rozpaczliwych prób "a może poszli do lasu" 1) a to po getXxxxx, a to po isXxxx, a to po polu którego ochronę się osłabia refleksją itd ...
Wyraziste property C# są zbawieniem.
grooovy troszkę poszedł w dobrą stronę, ale generalnie nie zaszalał, bo przymus kompatybilności

BTW jak byście nazwali w Javie metodę biorącą coś, ale żeby żadna biblioteka nie mniemała w tym read-only property?

1. z dowcpiu o radzieckich partyzantach

Java Kotlin oczywiście. W tej chwili JVM wiedzie prym jeśli chodzi o technologie chmurowe. Można znaleźć wiele ciekawych ofert. Jeżeli bardziej Ci zależy na pracy w korpo i spokojnym żywocie programisty to istotnie C# będzie lepszym wyborem.

Ja polecam JVM'a bo:

• Linux first (nie dajmy się otumanić M$ .NET niby cross platform ale gui już nie, w java'ie wszystko jest cross platform, JavaFX nawet na raspberry pi odpalisz, o tym że java chodzi na smartcart/javacart/sim nie wspomnę)
• Większa i bardziej aktywna społeczność, duża gama żywych języków alternatywnych (Kotlin, Scala, Clojure, Groovy) vs samotny F# w .NET
• FAANG vs M$, co prawda w warszawskim Google C# też używają ale firma Javą stoi (i C++)
• Lepszy system buildów (gradle, maven) vs ubogi MS-Build

Innymi słowy C#+MS ecosystem = proste rzeczy są naprawdę proste, trudne są nie możliwe; do tego dyktatura jedynej prawilnej korporacji:

• https://keivan.io/the-day-appget-died/
• MyGET - słyszał ktoś? Pewnie niewielu bo M$ natychmiast wypuścił swoje rozwiązanie (NuGet). Nie ma tu miejsca na alternatywne biblioteki i podejścia. Jeden wódz, jedna partia, jeden naród...

Do tego masa spamu i crap-postów na blogach MVP:
https://tomaszwisniewski.com/thoughts/2020/09/15/why-the-microsoft-mvp-program-is-broken.html

0xmarcin napisał(a):

• MyGET - słyszał ktoś? Pewnie niewielu bo M$ natychmiast wypuścił swoje rozwiązanie (NuGet). Nie ma tu miejsca na alternatywne biblioteki i podejścia. Jeden wódz, jedna partia, jeden naród..

A o Artifactory słyszałeś? Pytam, bo z posta, to od razu widać, że byłeś w jakimś bardzo ciemnym miejscu i niewiele tam widziałeś.
Artifactory razem z MyGetem to de facto standardy. Dla hipsterów jest Paket. A NuGet to faktycznie była nowość, jakąś dekadę temu.

Może jeszcze napisz, że TeamCity i Gita się nie używa, bo Microsoft ma swoje zamienniki. :D

Chyba mnie niektóre osoby źle zrozumiały z MyGET'em, chodziło mi o to że jak firma ma monopol na biblioteki/środowisko to może łatwo podkradać pomysły. Jako przykład podałem appget'a i MyGET'a.

Jako inny przykład można dać Newtonsoft.Json, autor pracuje teraz, co prawda w M$ ale domyślam się że ultimatum było takie: "pracuj dla nas albo napiszemy własną bibliotekę". Jeszcze inny przykład to frameworki do DI (Ninject, Windsor), MS zrobił własne rozwiązanie - ok mogli? mogli, jest też opcja żeby użyć własnego DI? jest - ale i tak jest to spory cios dla alternatywnych frameworków DI.

W JVM'ie idzie to trochę innym torem - zazwyczaj standaryzuje się interfejs np. https://jcp.org/en/jsr/detail?id=330 plus często wspomina się referencyjną implementację, wybór biblioteki pozostawia się dla użytkownika. Chyba najbardziej znanym przykładem jest tutaj JPA: https://www.vogella.com/tutorials/JavaPersistenceAPI/article.html - próba (nie do końca udana, bo jednak do czasu do czasu trzeba użyć adnotacji (atrybut w C#) z użytej biblioteki) ustandaryzowania intefejsu ORM'ów. W teorii można dzięki temu przejść łatwo między np. Hibernate a np. EclipseLink. Nikt nie narzuca jedynego prawilnego rozwiązania (EntityFramework).

0xmarcin napisał(a):

Chyba mnie niektóre osoby źle zrozumiały z MyGET'em, chodziło mi o to że jak firma ma monopol na biblioteki/środowisko to może łatwo podkradać pomysły. Jako przykład podałem appget'a i MyGET'a.

Że Microsoft ma monopol na biblioteki i środowisko? Ty kiedyś programowałeś w dotnecie? Microsoft długo nie potrafił nawet zrobić porządnego IDE, trzeba było zawsze instalować wtyczkę od JetBrains, a do bilbiotek jakieś Teleriki.

0xmarcin napisał(a):

Jako inny przykład można dać Newtonsoft.Json, autor pracuje teraz, co prawda w M$ ale domyślam się że ultimatum było takie: "pracuj dla nas albo napiszemy własną bibliotekę".

No przecież MS napisał własną bibliotekę. Coś się Twoja teoria nie klei.
No i jeżeli myślisz, że zmusiliby gościa do pracy w MS jako principal, bo napisał fajną biblioteczkę open source, to ciekawi mnie, ile rekrutacji do big techa przeszedłeś, że masz takie pomysły. To tak nie działa. No i chwilę wcześniej napisałeś, że "łatwo podkradać pomysły", to dlaczego MS po prostu nie podkradł pomysłu, tylko "zmuszał" autora do współpracy?

0xmarcin napisał(a):

Jeszcze inny przykład to frameworki do DI (Ninject, Windsor), MS zrobił własne rozwiązanie - ok mogli? mogli, jest też opcja żeby użyć własnego DI? jest - ale i tak jest to spory cios dla alternatywnych frameworków DI.

Ale cios w tym, że jest konkurencja? Przecież Microsoft miał też wcześniej rozwiązanie do DI, które umarło, to najwyraźniej było słabsze od konkurencji.

0xmarcin napisał(a):

W JVM'ie idzie to trochę innym torem - zazwyczaj standaryzuje się interfejs np. https://jcp.org/en/jsr/detail?id=330 plus często wspomina się referencyjną implementację, wybór biblioteki pozostawia się dla użytkownika. Chyba najbardziej znanym przykładem jest tutaj JPA: https://www.vogella.com/tutorials/JavaPersistenceAPI/article.html - próba (nie do końca udana, bo jednak do czasu do czasu trzeba użyć adnotacji (atrybut w C#) z użytej biblioteki) ustandaryzowania intefejsu ORM'ów. W teorii można dzięki temu przejść łatwo między np. Hibernate a np. EclipseLink. Nikt nie narzuca jedynego prawilnego rozwiązania (EntityFramework).

W dotnecie nikt nie zmusza do używania DI czy innych bibliotek od MS, jest sporo alternatyw do wyboru. Jeżeli uważasz EntityFramework za jedyne prawilne rozwiązanie, to niespecjalnie znasz dotnet.

ako inny przykład można dać Newtonsoft.Json, autor pracuje teraz, co prawda w M$ ale domyślam się że ultimatum było takie: "pracuj dla nas albo napiszemy własną bibliotekę"

No i jakoś słabe to ultimatum, bo u nich pracuje ORAZ napisali własną bibliotekę (System.Text.Json).

Nikt nie narzuca jedynego prawilnego rozwiązania (EntityFramework).

IMO tutaj nie ma że ktoś narzuca. Robią swój projekt, i ci wiele osób idzie za tym "bo przecież oficjalnie", a wiele idzie w inną stronę (patrz np. Dapper, NHIbernate). Albo nawet jak mają własny produkt (MSTest) to i tak wszyscy używają czegoś innego - i potem nawet oni zaczynają (xUnit).

@0xmarcin: osobiście nie sądzę żeby w Javie samej była dużo większą różnica odnośnie wyboru.
Ok, np. jest teoretycznie wybór implementacji JPA, ale w praktyce to i tak Hibernate w jakiś 90%0"przypadków.

0xmarcin napisał(a):

Jako inny przykład można dać Newtonsoft.Json, autor pracuje teraz, co prawda w M$ ale domyślam się że ultimatum było takie: "pracuj dla nas albo napiszemy własną bibliotekę".

A rano znalazł w łóżku odciętą głowę konia.

Jeszcze inny przykład to frameworki do DI (Ninject, Windsor), MS zrobił własne rozwiązanie - ok mogli? mogli, jest też opcja żeby użyć własnego DI? jest - ale i tak jest to spory cios dla alternatywnych frameworków DI.

Microsoftowy framework DI powstał mniej więcej w tych samych czasach co Windsor i Ninject.
Jeśli zaś chodzi Ci o wbudowane w ASP.NET Core rozwiązanie to poza tym, że jest ono niezbyt dojrzałe, to na dodatek cała idea jest bezsensowna, bo ujednolicanie sprawia, że ogranicza się funkcjonalność. Zysk z obcięcia funkcjonalności kontenera X to tego, co oferuje MS jest ujemny, więc raczej stosuje się kontener X.

W JVM'ie idzie to trochę innym torem - zazwyczaj standaryzuje się interfejs np. https://jcp.org/en/jsr/detail?id=330 plus często wspomina się referencyjną implementację, wybór biblioteki pozostawia się dla użytkownika.

No i w Javie ten standaryzowany interfejs nie ogranicza możliwości dawanych przez twórców bibliotek?
Hmm, może po to wprowadzili to dynamiczne typowanie razem z generykami, aby fantazji nie dało się ograniczać. :P

Nikt nie narzuca jedynego prawilnego rozwiązania (EntityFramework).

Ale którego Entity Frameworka? Bo teraz brute-forcem robią od nowa chyba już czwartą wersję, a cały czas nie ma połowy możliwości konkurencji, skutkiem czego często nie jest wybierany jeśli ktoś robi coś więcej niż CRUD.

To, że jakieś rozwiązanie jest popularniejsze, to jest oczywistość. Czasem jest to coś, co dostarcza M$, czasem nie. Wybór jest na tyle duży, że na kilkanaście projektów nie udało mi się być jeszcze w dwóch z takim samym stosem technologicznym, a od znajomych Javowców słyszy się, że pracę zmieniają, ale ciągle w Springu siedzą. To gdzie w końcu jest ten "monopol"?

1. Powinno sie zabornić takich tematów na tym forum :D 7
2. Już ktoś o tym pisal i ja tak zrobiłem. Napisz tą samą aplikacje w Javie i C#. I porównaj. Ja wybrałem C#
3. Kotlin, Scala, Java, C# kazdy ma swoje wady i zalety. Każdy wywiązuje sie ze swoich zadań. Każdy z jakiegoś powodu wybrał cos dal siebie. Po co bić piane?

Na zachodzie ostatnio eksperymentują z językami podobnymi do Go, czyli Elixir, Nim, Crystal, Idris, D które posiadają GC ale mogą go wyłączyć, gdy potrzebna jest większa systemowa wydajność. Jak ktoś lubi prostą składnie Pythona i Ruby, ale wydajność wyższą niż w Javie i C# to warto się nad tymi językami zastanowić. Ich nauka jest dużo szybsza niż tych kombajnów Javy i C#.
https://github.com/kostya/benchmarks
https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=query