Mono lepiej radzi sobie z ukierunkowaniem na platformy, które chcę obsługiwać. Poza tym wszystko jest subiektywne.
Udostępniam kod C # na następujących platformach: - iOS (iPhone / iPad) - Android - Internet (HTML5) - Mac (OS X) - Linux - Windows
Mógłbym udostępnić jeszcze więcej miejsc: - Windows Phone 7 - Wii - XBox - PS3 - itd.
Największą zaletą jest iOS, ponieważ MonoTouch działa fantastycznie. Nie znam żadnego dobrego sposobu na kierowanie iOS z Javą. Nie można kierować reklamy na Windows Phone 7 za pomocą Javy, więc powiedziałbym, że czasy, gdy Java była lepsza dla urządzeń mobilnych, już za nami.
Jednak największym czynnikiem jest dla mnie osobista produktywność (i szczęście). C # jako język wyprzedza o lata Java IMHO, a korzystanie z platformy .NET jest przyjemnością. Większość tego, co jest dodawane w językach Java 7 i Java 8, jest od lat w języku C #. Języki JVM, takie jak Scala i Clojure (oba dostępne w CLR) są jednak całkiem przyjemne.
Postrzegam Mono jako platformę samą w sobie (świetną) i traktuję .NET jako implementację Mono firmy Microsoft w systemie Windows. Oznacza to, że najpierw opracowuję i testuję na Mono. To działa cudownie.
Gdyby zarówno Java, jak i .NET (powiedzmy, Mono) były projektami Open Source bez wsparcia korporacyjnego, za każdym razem wybrałbym Mono zamiast Java. Uważam, że to po prostu lepsza platforma.
Zarówno .NET / Mono, jak i JVM to świetny wybór, chociaż osobiście użyłbym innego języka niż Java w JVM.
Moje zdanie na temat niektórych innych komentarzy:
Problem: wydajność.
** Odpowiedź: Zarówno JVM, jak i CLR działają lepiej niż twierdzą krytycy. Powiedziałbym, że JVM działa lepiej. Mono jest generalnie wolniejsze niż .NET (choć nie zawsze).
Osobiście każdego dnia wziąłbym ASP.NET MVC nad J2EE zarówno jako programista, jak i użytkownik końcowy. Wsparcie dla klienta natywnego Google jest całkiem fajna. Wiem też, że słaba wydajność graficznego interfejsu użytkownika w aplikacjach Java na komputery stacjonarne należy już do przeszłości, ale wciąż znajduję powolne. Z drugiej strony mógłbym powiedzieć to samo o WPF. Jednak GTK # jest bardzo szybkie, więc nie ma powodu, żeby były wolne.
Problem: Java ma większy ekosystem dostępnych bibliotek.
Odpowiedź: Prawdopodobnie prawda, ale w praktyce nie jest to problem.
Praktycznie każda biblioteka Java (w tym JDK) działa po prostu elegancko na .NET / Mono dzięki IKVM.NET . Ta technologia to prawdziwy cud. Integracja jest niesamowita; możesz używać biblioteki Java tak, jak była natywna. Musiałem jednak używać tylko bibliotek Java w jednej aplikacji .NET. Ekosystem .NET / Mono zazwyczaj oferuje więcej, niż potrzebuję.
Problem: Java ma lepszą (szerszą) obsługę narzędzi
Odpowiedź: Nie w systemie Windows. W przeciwnym razie zgadzam się. MonoDevelop jest jednak fajny.
Chcę dać okrzyk MonoDevelop ; to jest klejnot. MonoDevelop integruje większość narzędzi, których chcę używać, w tym uzupełnianie kodu (intellisense), integrację z Git / Subversion, obsługę testów jednostkowych, integrację SQL, debugowanie, łatwą refaktoryzację i przeglądanie zestawów z dekompilacją w locie. Wspaniale jest używać tego samego środowiska do wszystkiego, od Internetu po stronie serwera po aplikacje mobilne.
Problem: kompatybilność między różnymi platformami.
Odpowiedź: Mono to jeden kod bazowy na wszystkich platformach, w tym Windows.
Najpierw opracuj dla Mono i wdróż w .NET w systemie Windows, jeśli chcesz. Jeśli porównasz .NET z MS i Javą, Java ma przewagę pod względem spójności między platformami. Zobacz następną odpowiedź ...
Problem: Mono opóźnia .NET.
Odpowiedź: Nie, nie. IMHO, to często podawane, ale błędne stwierdzenie.
Dystrybucja mono z platformy Xamarin jest dostarczana z C #, VB.NET, F #, IronPython, IronRuby i myślę, że może Boo po wyjęciu z pudełka. Kompilator Mono C # jest całkowicie aktualny z MS. Kompilator Mono VB.NET jest opóźniony w stosunku do wersji MS. Pozostałe kompilatory są takie same na obu platformach (podobnie jak inne języki .NET, takie jak Nemerle, Boo i Phalanger (PHP)).
Mono jest dostarczany z dużą ilością rzeczywistego kodu napisanego przez firmę Microsoft, w tym Dynamic Language Runtime (DLR), Managed Extensibility Framework (MEF), F # i ASP.NET MVC. Ponieważ Razor nie jest Open Source, Mono jest obecnie dostarczany z MVC2, ale MVC3 działa dobrze na Mono.
Podstawowa platforma Mono dotrzymuje kroku .NET lub od wielu lat, a kompatybilność jest imponująca. Możesz już dziś używać pełnego języka C # 4.0, a nawet niektórych funkcji C # 5.0. W rzeczywistości Mono często przewodzi .NET na wiele sposobów.
Mono implementuje części specyfikacji CLR, których nawet Microsoft nie obsługuje (jak tablice 64-bitowe). Jednym z najbardziej ekscytujących nowych elementów technologii w świecie .NET jest Rosylyn . Mono od wielu lat oferuje kompilator C # jako usługę. Niektóre z tego, co oferuje Rosylyn, są również dostępne za pośrednictwem NRefractory . Przykładem, w którym Mono jest wciąż przed nami, byłyby instrukcje SIMD, aby przyspieszyć wydajność gier.
Microsoft oferuje oprócz .NET wiele produktów, które nie są dostępne w Mono, z czego wynika błędne przekonanie o opóźnieniu Mono. Windows Presentation Foundation (WPF), Entity Framework (EF), WCF (Windows Communication Foundation) to przykłady produktów, które nie działają lub są słabo obsługiwane w trybie mono. Oczywistym rozwiązaniem jest użycie alternatyw międzyplatformowych, takich jak GTK #, NHibernate i ServiceStack.
Problem: Microsoft jest zły.
Odpowiedź: prawda. Więc co.
Wiele osób podaje następujące powody, dla których warto unikać korzystania z Mono:
1) Nie powinieneś używać Mono, ponieważ należy unikać technologii Microsoft
2) Mono jest do bani, ponieważ nie pozwala na użycie wszystkich technologii oferowanych przez Microsoft
Dla mnie jest jasne, że te stwierdzenia są niezgodne. Odrzucam pierwsze stwierdzenie, ale pominę tutaj ten argument. Drugie stwierdzenie dotyczy wszystkich alternatyw .NET.
JVM to świetna platforma, a eksplozja języków JVM jest niesamowita. Korzystaj z tego, co cię uszczęśliwia. Na razie jest to dla mnie często .NET / Mono.