Наскільки менше бібліотек для Mono, ніж для Java?

Мені не вистачає огляду на обидві альтернативи, але я маю дуже багато свободи вибору для свого наступного проекту. Я шукаю важкі технічні факти в районах Російської Федерації

• продуктивність (наприклад, мені кажуть, що Java хороша для нарізування різьби, і я чую, що оптимізація коду виконання стала дуже хорошою останнім часом для .NET)
• портативність у реальному світі (це обоє покликані бути портативними, що таке Catch-22 для кожного?)
• наявність інструменту ( CI , автоматизація побудови, налагодження, IDE)

Я особливо шукаю те, що ви насправді переживали у власній роботі, а не те, що я міг би гугл. Мій додаток - це бэк-енд-сервіс, який обробляє велику кількість даних із часових рядів.

Моєю основною цільовою платформою буде Linux.

Редагувати: Щоб більш чітко сформулювати моє запитання, мене цікавить весь пакет (сторонні бібліотеки тощо), а не лише мова. Для бібліотек це, мабуть, зводиться до питання "наскільки менше бібліотек для Mono, ніж для Java"?

FYI, з цього часу я вибрав Java для цього проекту, тому що він здавався просто більш бойовим на переносимості, і він вже деякий час був у старих системах. Мені це зовсім трохи сумно, тому що мені дуже цікаво C # і я хотів би зробити якийсь великий проект у ньому, але, можливо, наступного разу. Дякую за всі поради.

Ну .... Java насправді більш портативний. Моно не впроваджується скрізь, і значно відстає від впровадження Microsoft. Здається, SDK Java залишається в кращій синхронізації на різних платформах (і працює на більшості платформ).

Я б також сказав, що Java має більше доступності інструментів на всіх цих платформах, хоча є багато інструментів, доступних для .NET на платформах Windows.

Оновлення за 2014 рік

Я все ще дотримуюся цієї думки в 2014 році. Однак, я кваліфікую це, кажучи, що я зараз починаю приділяти деяку увагу Mono через тривалий час не дуже турботливих, тому в режимі виконання моно (або екосистемі можуть бути покращення). ) про що мені не відомо. AFAIK, досі немає підтримки WPF, WCF, WF, WIF. Моно може працювати на iOS, але, наскільки мені відомо, час роботи Java все ще працює на набагато більше платформах, ніж Mono. Крім того, Mono починає бачити деякі значно вдосконалені інструменти (Xamarin), і Microsoft, схоже, має набагато більше кроссплатформенне ставлення та готовність працювати з партнерами, щоб зробити їх безкоштовно, а не конкурентоспроможними (наприклад, Mono буде досить важлива частина майбутнього ландшафту OWIN / Helios ASP.NET). Я підозрюю, що в найближчі роки різниця в портативності швидко зменшиться,

Оновлення на 2018 рік

Мій погляд на це починає йти іншим шляхом. Я думаю, що .NET, в основному, особливо з .NET Core, почав домагатися «паритету портативності» з Java. Зараз проводяться зусилля для залучення WPF до .NET Core для деяких платформ, а сам .NET Core зараз працює на багатьох платформах. Mono (належить Xamarin, який зараз належить Microsoft) - більш зрілий і відполірований продукт, ніж будь-коли, і написання додатків, які працюють на декількох платформах, вже не є областю глибокого гнозування .NET-хакерів, а є відносно простим починанням. . Звичайно, є бібліотеки та сервіси та програми, які є лише для Windows або можуть орієнтуватися лише на певні платформи, але те саме можна сказати і про Java (широко).

Якби я в цей момент був у взутті ОП, я не можу придумати жодних причин, притаманних самим мовам або технологічним стекам, які б заважали мені вибрати .NET для будь-якої програми, що рухається вперед з цього моменту.

Mono робить кращу роботу в орієнтації на платформи, які я хочу підтримати. Крім цього, це все суб'єктивно.

Я поділяю код C # на наступні платформи: - iOS (iPhone / iPad) - Android - Web (HTML5) - Mac (OS X) - Linux - Windows

Я міг би поділитися ним ще більше місць: - Windows Phone 7 - Wii - XBox - PS3 - і т.д.

Біггі - це iOS, оскільки MonoTouch працює фантастично. Я не знаю жодного хорошого способу націлити iOS за допомогою Java. Ви не можете орієнтуватися на Windows Phone 7 за допомогою Java, тому я б сказав, що дні Яви, які є кращими для мобільних пристроїв, відстають від нас.

Найбільшим фактором для мене є особиста продуктивність (і щастя). C # як мова на багато років випереджає Java IMHO, і .NET-фреймворк радісно використовувати. Більшість того, що додається в Java 7 та Java 8, є у C # роками. Мови JVM, такі як Scala та Clojure (обидва доступні в CLR), дуже приємні.

Я бачу Mono як платформу сама по собі (чудова) і трактую .NET як реалізацію Mono в Microsoft для Windows. Це означає, що я першим розробляю і тестую Mono. Це чудово працює.

Якщо і Java, і .NET (скажімо моно) були проектами з відкритим кодом без будь-якої корпоративної підтримки, я б обирала Mono над Java кожен раз. Я вважаю, що це просто краща платформа.

І .NET / Mono, і JVM - чудовий вибір, хоча я особисто використовую іншу мову, ніж Java, на JVM.

Я приймаю деякі інші коментарі:

Випуск: Продуктивність.

** Відповідь: І JVM, і CLR працюють краще, ніж недоброзичливці кажуть. Я б сказав, що СВМ працює краще. Моно звичайно повільніше, ніж .NET (хоча не завжди).

Я особисто брав ASP.NET MVC над J2EE будь-який день як розробник і кінцевий користувач. Підтримка Google Native Client теж досить крута. Крім того, я знаю, що низька продуктивність графічного інтерфейсу для настільних додатків Java повинна бути минулим, але я все одно знаходжу повільні. Потім я знову можу сказати те саме для WPF. GTK # досить швидкий, хоча тому немає причини, щоб вони були повільними.

Проблема: у Java є більш широка екосистема бібліотек.

Відповідь: Мабуть, правда, але це не питання на практиці.

Практично кожна бібліотека Java (включаючи JDK) працює просто у форматі .NET / Mono завдяки IKVM.NET . Цей фрагмент технології - справжнє диво. Інтеграція дивовижна; ви можете використовувати бібліотеку Java так, як це було рідною. Мені довелося використовувати лише бібліотеки Java в одному додатку .NET. Екосистема .NET / Mono загалом пропонує більше, ніж мені потрібно.

Проблема: Java має кращу підтримку (ширші) інструменти

Відповідь: Не в Windows. Інакше я згоден. Хоча MonoDevelop приємний.

Я хочу дати кричати MonoDevelop ; це коштовність. MonoDevelop інтегрує більшість інструментів, які я хочу використовувати, включаючи завершення коду (intellisense), інтеграцію Git / Subversion, підтримку тестування одиниць, інтеграцію SQL, налагодження, простий рефакторинг та перегляд збірок за допомогою декомпіляції на ходу. Чудово використовувати те саме середовище для всього, від веб-сервера до мобільних додатків.

Проблема: Сумісність між платформами.

Відповідь: Mono - це єдина база коду на всіх платформах, включаючи Windows.

Спочатку розробляйте для Mono та розгортайте в .NET на Windows, якщо хочете. Якщо ви порівнюєте .NET від MS до Java, тоді Java має перевагу в плані узгодженості на різних платформах. Дивіться наступну відповідь ...

Випуск: Моно відстає .NET.

Відповідь: Ні, це не так. ІМХО, це часто заявлене, але неправильне твердження.

Поширення Mono від Xamarin поставляється з C #, VB.NET, F #, IronPython, IronRuby, і я думаю, що, можливо, Бу вийшов з коробки. Компілятор Mono C # повністю в курсі MS. Компілятор Mono VB.NET затримує версію MS. Інші компілятори однакові на обох платформах (як і інші мови .NET, такі як Nemerle, Boo та Phalanger (PHP)).

Моно постачається з великою кількістю фактичного письмового коду Microsoft, включаючи динамічну мову виконання (DLR), керовану рамку розширення (MEF), F # та ASP.NET MVC. Оскільки Razor не є відкритим кодом, Mono в даний час постачається з MVC2, але MVC3 працює на Mono просто чудово.

Основна платформа Mono йшла в ногу з .NET або багато років, і сумісність вражає. Сьогодні ви можете використовувати повну мову C # 4.0 та навіть деякі функції C # 5.0. Насправді Mono часто веде .NET багато в чому.

Mono реалізує частини специфікації CLR, які навіть Microsoft не підтримує (як 64-бітні масиви). Один з найбільш захоплюючих нових технологій у світі .NET - Розилін . Mono пропонував компілятор C # як послугу протягом багатьох років. Деякі з пропозицій Rosylyn доступні і через NRefractory . Прикладом того, як Mono ще випереджає, будуть інструкції SIMD для прискорення ігрових можливостей.

Корпорація Майкрософт пропонує ряд продуктів на додаток до .NET, які не доступні в Mono, і це неправильне уявлення про відставання Mono. Фонд презентацій Windows (WPF), Entity Framework (EF), WCF (Windows Communication Foundation) - приклади продуктів, які не працюють або погано підтримуються в Mono. Очевидним рішенням є натомість використовувати альтернативи між платформами, такі як GTK #, NHibernate та ServiceStack.

Проблема: Microsoft зла.

Відповідь: Правда. І що.

Багато людей пропонують такі причини, щоб не використовувати Mono:

1) Не слід використовувати Mono, оскільки слід уникати технологій Microsoft

2) Mono смокче, тому що не дозволяє використовувати всі технології, які пропонує Microsoft

Мені зрозуміло, що ці твердження несумісні. Я відкидаю перше твердження, але пропущу це аргумент тут. Друге твердження стосується всіх альтернатив .NET.

JVM - це чудова платформа, і вибух мов JVM є приголомшливим. Використовуйте те, що робить вас щасливими. Поки що це часто .NET / Mono для мене.

Я фактично розвиваюся в .NET, запускаю всі свої тести спочатку на Mono, а потім на Windows. Таким чином я знаю, що мої програми є кросплатформенними. Я зробив це дуже успішно і в додатках ASP.NET, і в Winforms.

Я не дуже впевнений, звідки у когось складається враження, що Моно настільки жахливе, але це, безумовно, зробило свою роботу в моїх справах і думках. Правда, у вас буде трохи відставання щодо останніх і найбільших винаходів у .NET світу. Але поки що .NET 2.0 для Windows та Linux для мене дуже солідний.

Майте на увазі, що, очевидно, є багато примх до цього, але більшість з них походить від того, щоб ви писали переносний код. У той час як рамки роблять велику роботу, щоб абстрагувати ОС, на якій ви працюєте, такі дрібниці, як чутливість регістру Linux у шляхах та іменах файлів, трохи звикають, як і такі речі, як дозволи.

.NET, безумовно, дуже кросова платформа завдяки Mono на основі мого досвіду.

Java насправді настільки ж кросплатформна, як всі кажуть. Існує реалізація JVM для майже будь-якої основної ОС там (навіть Mac OS X, нарешті), і всі вони працюють дуже добре. І є багато інструментів з відкритим кодом, які є настільки ж крос-платформою.

Єдина уловка полягає в тому, що є певні нативні операції, які ви не можете зробити на Java без написання деяких DLL або SO. Дуже рідко вони трапляються на практиці. Однак у всіх цих випадках мені вдалося обійти його, нерестуючи рідні процеси та закресливши результати.

Я вважаю, що питання поставлено неправильно. C # vs. Java набагато менш цікавий з точки зору використання крос-платформ, ніж (a) які платформи вам потрібно підтримувати, і (b) враховуючи основні бібліотеки та доступні сторонні бібліотеки. Мова є чи не найменш важливою частиною процесу прийняття рішень.

Java - кращий вибір для розвитку кросплатформ.

• Продуктивність. Java та .Net мають аналогічний рівень продуктивності завдяки віртуальній машині, але JVM, як правило, має кращі показники роботи через роки та роки оптимізації.

• Бібліотека. Хоча це залежить від вашого завдання, Java має набагато більше бібліотек з відкритим кодом або сторонніми бібліотеками. Для серверних додатків, J2EE, Spring, Struts тощо для GUI, хоча .Net надає API рівня Win32, але це спричиняє проблеми сумісності. У Java є Swing, SWT, AWT тощо. Це працює в більшості випадків.

• Сумісність. Це ключові питання, які необхідно враховувати при розробці міжплатформної програми. Два питання: по-перше, сумісність платформи. Java все ще перемагає, оскільки JDK добре підтримується однією та оригінальною компанією Sun. MS не підтримує Mono, тому у вас поки немає гарантії на сумісність оновлення. 2. Зворотна сумісність. Sun підтримує хорошу репутацію щодо їх відсталої сумісності, хоча іноді це здається занадто жорстким і уповільнює темп.

• Інструменти. У Java є хороші міжплатформні IDE. Netbeans, Eclipse тощо. Більшість з них є безкоштовними. VS Studio хороший, але тільки в Windows, і не коштує мало. Вони обидва забезпечують хороші одиничні тести, налагодження, профілі тощо.

Тому я б припустив, що Java - кращий вибір. Як показовий випадок, є кілька відомих настільних кросплатформних додатків, розроблених Java: Vuze, Limewire, BlogBridge, CrossFTP, не кажучи вже про ці IDE. Щодо .Net, я маю обмежені знання про такі програми успіху.

Я задаю те саме питання із запізненням і IMHO,. NET / Mono, здається, є кращим варіантом просто тому, що Mono має чудовий досвід для багатоплатформних настільних додатків (на відміну від Java) і, звичайно, Mono поліпшення стрибків у ці дні.

Я також скажу Java. Якщо ви подивитесь на це з точки зору зрілості, Sun (та інші) витратили набагато більше часу та зусиль на те, щоб JVM працював на платформах, які не є Windows.

Навпаки, Mono, безумовно, є громадянином другого класу в екосистемі .NET.

Залежно від того, хто є вашими цільовими клієнтами, ви також можете виявити, що існує реальна відмова від використання Mono - чи Novell пропонує такий самий тип підтримки для Mono для постачальників Mono, який ви отримаєте для Java або .NET в Windows?

Якщо ви орієнтувались головним чином на розміщення свого сервісу в Windows, було б доцільно розглянути цей вибір, але, оскільки ви орієнтуєтесь в першу чергу на Linux, це здається мені неначе модним.

Java була розроблена як кросплатформна; C # /. Чистий не був. Коли ви сумніваєтесь, використовуйте інструмент, який був розроблений для ваших цілей.

EDIT: Справедливо кажучи, .NET був розроблений для роботи у вбудованому середовищі / ПК / сервер, так що це SORT крос-платформи. Але він не був розроблений для Linux.

Я думаю, що відповідь "це залежить". Java працює майже будь-що, але .NET / Mono є (IMHO) кращою основою для робочого столу. Тож я думаю, що відповідь дійсно залежить від платформ, які ви плануєте орієнтувати.

Щоб додати трохи більше до розмови, Java є більш портативною, якщо ви залишитесь на одній версії позаду - у Java 5 все ще є багато відмінних функцій, тому ви можете чекати на Java 6 і все ще має широкий діапазон щодо мови та бібліотек для розвитку. з. Mac - це основна платформа, яка може зайняти деякий час, щоб догнати останню версію Java.

Java також має чудовий орган зі стандартів, який інтелектуально розвиває платформу, базуючись на вкладах різних компаній. Це часто недооцінена функція, але вона підтримує навіть нові функції, які добре працюють на різних платформах, і надає широкий спектр підтримки бібліотеки для деяких езотеричних речей (як додаткові розширення).

Я б голосував за те, щоб Java була більш портативною, ніж C #. У Java також є дуже багатий набір стандартних бібліотек. Існує також широкий набір сторонних бібліотек з відкритим кодом, таких як ті, які надає проект Джакарта ( http://jakarta.apache.org/ ).

Усі звичайні підозрювані існують також для ІС, тестування одиниць тощо. Підтримка крос-платформи IDE також дуже хороша, як у Eclipse, Netbeans, IntelliJ IDEA тощо.

Є й інші варіанти вибору мови. Я дуже захопився Python, який добре працює в Windows, Linux та Mac, і має багатий набір бібліотек.

Поки Моно має свою частку проблем я думаю, що він має кращу історію сумісності між платформами, особливо якщо ви покладаєтесь на виклик рідної платформи.

На Stack Overflow недостатньо слів, щоб підкреслити, наскільки плавніше отримати щось, що називається та виконується в .NET / Mono на (принаймні, за моїм досвідом 3 ...) декількох платформах, порівняно з рівноцінними зусиллями Java.

Gatorhall у вас є якісь дані, щоб підкріпити це?

Продуктивність. Java та .Net мають аналогічний рівень продуктивності завдяки віртуальній машині, але JVM, як правило, має кращі показники роботи через роки та роки оптимізації.

Передумови: я хлопець Windows з Windows 3.1 та на даний момент користувач Linux (все ще працює Windows 7, чудова ОС, в VM для Visual Studio 2010 та інших інструментів).

Справа: я та багато користувачів (Windows, Linux та ін.), Яких я знаю, можуть не погодитися з вами. Java, як правило, працює повільніше навіть на настільному додатку Linux, ASP.NET виконує швидше, ніж сторінки сервера Java у багато разів. Деякі можуть погодитись, що навіть некомпільований PHP працює краще в декількох сценаріях.

Java - більше кросплатформна? У мене немає жодних сумнівів з цього приводу (історія назад), але швидше (не кажу.