Java против C#: какой язык производительнее в реальных проектах?

Меньшее количество ключевых слов != читаемость.

Статически типизируемый код самодокументирован, в отличии от

в яве нет async/awit. Это приговор)

Меньшее количество ключевых слов != читаемость.

В первую очередь в руби меньше шума.

Статически типизируемый код самодокументирован

Я бы не променял это мнимое достоинство на эффективный рефакторинг и применяемость библиотек.

Оба производительней.

ибо JIT

а вообще не от производительности зависит что предпочтут C# или Java

С# не нужно, Java нужно. </thread>

Динамичность языка позволяет эффективней разрабатывать код, легко заменяя крупные части

... и приводя к аццким затратам на последующую отладку, когда не то сунули не туда - причем происходит это в 1 случае из 100500. Плавали, знаем.

многими отмечается, что статичность языка, в основном, мешает разработчику

... совершать ошибки.

эффективный рефакторинг и применяемость библиотек.

Чем он эффективнее и они применяемее жавовых?

Если выбирать из Java и C#, то самый производительный, это пожалуй C++ :)

совершать ошибки.

Боже, какая наивность.

Возможностями языка, конечно. Разве может библиотека в яве изменить работу какого-либо метода в классе. Разве можно безболезненно изменить класс используемых объектов. Последнее конечно можно через некоторые паттерны - но вот это, пожалуй, и есть костыль.

Отсутствуют зависимости в библиотеках и тем более версионность.

Разве может библиотека в яве изменить работу какого-либо метода в классе

В скале - да. И наоборот тоже. implicit и всё остальное в помощь.

Разве можно безболезненно изменить класс используемых объектов.

Не распарсил.

Отсутствуют зависимости в библиотеках и тем более версионность.

ivy/maven? Или о чем речь?

О, специальная олимпиада производительности.. ассемблер!</win>
Во-ху!

А раньше вроде так не вбрасывал.

special-k уже не тот))

Да нет же, это когда рубисты показывают раилс, после чего глядя на свой код из глаз ява-прогеров текут кровь и слезы

java-сорец — это в 70% адское многословное месиво с 7 уровнями вложенных if'ов. Но под jvm есть куча языков и DSL, позволяющими писать приличный, короткий и читабельный код.

С чего ты взял, что это связано с оптимизацией рельс?))

Динамическая типизация — это тормоза и при разработке, и при отладке, и при выполнении на продакшене. Если бы всё устраивало, все бы давно сидели ровно на рельсах и не рыпались.

Не распарсил.

Речь главным образом о строгой типизации, и в целом о механизме замены класса объекта, ведь для этого в java необходимо использовать фабрику.

ivy/maven? Или о чем речь?

Речь о gem (и gemfile)

есть куча языков и DSL

В т.ч. jruby)

Динамическая типизация — это тормоза и при разработке, и при отладке, и при выполнении на продакшене.

Ну во-первых нет. Во-вторых js показывает, что явно нет. Быстрость языка это не главное, например рельсы работают в один поток и неасинхронно, даже если руби вдруг начнет работать очень быстро, следом все явно упрется в БД. Для моих задач скорости руби пока хватает (и я предпочитаю работать через EM асинхронно). И ситуация улучшается.

implicit

А это влияет на производительность?

а также лямбд, делегатов и экстеншн методов

Разве может библиотека в яве изменить работу какого-либо метода в классе.

легко. про aop слышал?

Лямбды? А ты скачай Java8.

там нет пока финальных лямбд. их же все пилят

Вообще такое возможно сделать и в явке, и даже иногда очень хочется, но не стоит заменять проектирование манки патчингом.

man FJP

Во-первых все это выглядит криво, то что в руби интуитивно и не вызывает вопросов, здесь порождает подобные посты http://habrahabr.ru/post/114649/ Во-вторых, я снова спрошу о производительности.

Как я и думал, с производительностью не очень http://www.ibm.com/developerworks/ru/library/j-aopwork2/

Я же сразу сказал, что производительность здесь всегда мнимая, потому что полностью статичные системы вряд ли смогут существовать в реальности, а любого рода динамичность приводит к существенному уменьшению производительности. И если программисты динамических языков осознают возможности своих инструментов, то, java разработчики, похоже, нет. Один черт, в конце оно будет работать как руби через тонны бойлерплейта и уродливых конструкций, с трудом поддерживаемое. Пусть в scala ситуация и лучше, но суть та же.

Хахаха! Дааа, тут всё сразу стало ясно.

не скажи. большие приложения на java работают быстрее C-шных.

Автор логично разделил свою статью на три части:

1. Ложь
2. Пи*шь
3. Провокация

Нормально для ГСМ, но не слишком-то и оригинально.

Я считаю, что система в целом должна писаться на руби, и только в каких-то узких ее частях переходить на более низкоуровневые вещи

почему нельзя заменить руби на Java/C#/Python/PHP?

Java 8 не существует, как минимум до 2014 года, а учитывая их факапы с седьмой джавой после релиза, то и до 2015. Итого нету в джаве лямбд.

Разные могут быть причины. Ну вот фанатизм, к примеру. Или там «синдром на букву У» какой-нибудь. Да мало ли...

Итого нету в джаве лямбд.

о да, а без лямбд нет жизни на этом свете. Это ты Линусу скажи, а то как он своё ядро без лямбд писал? Дурачок.

вот именно, что синдром на У во все поля.

Разве может библиотека в яве изменить работу какого-либо метода в классе

Слава создателям явы - нет.

java-сорец — это в 70% адское многословное месиво с 7 уровнями вложенных if'ов

7иуровневые ифы любой анализатор на раз завернёт. А многословность на читабельность не влияет.

Динамическая типизация — это тормоза и при разработке, и при отладке, и при выполнении на продакшене

Не согласен, на первичную разработку не влияет. А вот время на тестирование и отладку увеличивает.

А вот время на тестирование и отладку увеличивает.

И почему же?

невооруженным глазом заметна «объективность» статьи

Ну раз сам это понимаешь зачем тогда создал эту ветку? Статья по ссылке - бездоказательная и некомпетентная в своей постановке чушь...Производительность - мягко говоря не самая сильная черта что Java что С#, но даже если и задаться целью её сравнить то нужно множество тестов с кодом, графиками, указанием целевой платформы и так далее...Ничего этого в статье нет...

functional java project что ли? так я его использую.

Все равно там нет async/await в смысле C#: http://habrahabr.ru/post/139734/

даже если будут всякая встроенная функциональщина и анонимные блоки, придется выделять блок _руками_. А тут блок выделяет сам компилятор, «блок без блока».

плюс, т.к. _сейчас_ жава не умеет функциональщину, все что юзает functionaljava и totallylazy выглядит как говно, с этими отрвратительными анонимными классами, растянувшимися на километры по вертикали :((

как сказано в документации по Guava:

Excessive use of Guava's functional programming idioms can lead to verbose, confusing, unreadable, and inefficient code. These are by far the most easily (and most commonly) abused parts of Guava, and when you go to preposterous lengths to make your code «a one-liner,» the Guava team weeps.

Please be sure, when using Guava's functional utilities, that the traditional imperative way of doing things isn't more readable. Try writing it out. Was that so bad? Was that more readable than the preposterously awkward functional approach you were about to try?

У C# больше инструментов для написания производительного кода. В реальных проектах, думаю, разницы особенной нет.

Оба тормозные, выбирай C/C++.

Fork Join Pool. Там используется work stealing и задачи могут выполняться внутри вызова join другой задачи. Получается почти как continuation, но без особой уличной магии

в том-то и дело, что «уличная магия» и «синтаксический сахарок» позволяет простому быдлокодеру фигачить continuations почти не задумываясь, как это работает. Просто такое слово «чтобы подождать». Хоть на каждой строчке пиши столбиками. А как там будет трахаться CLR чтобы всё это разрулить - его ни в малейшей степени не волнует. Сейчас чуваки на .NET'е так весь гуй пишут, и когда заглядывают в этот наш свинг, делают 16-угольные глаза, типа «а што эта за херня такая, какие-та лиснеры столбиком?»

ну или я не понял и приведи пример кода, где легко и просто можно «ждать» не задумываясь над технической реализацией этого действия.

(Эххх, вот не был бы clojure таким сложным, можно было бы гордиться им, типа у нас в JVM-мире еще круче...)

Эххх, вот не был бы clojure таким сложным, можно было бы гордиться им, типа у нас в JVM-мире еще круче...

У нас весь код проекта в монаде Future на scala. Ни одной блокирующей операции в бизнес-логике, включая СУБД, закачки с других серверов, отдача файлов.

ну или я не понял и приведи пример кода, где легко и просто можно «ждать» не задумываясь над технической реализацией этого действия.

Не уверен что так можно, особенно со ThreadLocal, которыми кишат гибернейты и подобные. И в C# тоже. Но что в async/await, что в FJP, в нормальных сценариях ожидание достаточно прозрачно

И почему же?

Потому, что когда тебе в очередь какого-нибудь потока засунут строку вместо объекта, или узел списка вместо содержимого узла (или наоборот), ты узнаешь об этом только по падению потока в эксепшн. Или (если напишешь 100500 проверок везде и всюду), то по падению потока, вызвавшего метод/свойство с неправильными параметрами. И в любом случае это произойдет только в рантайме.

А при использовании статической типизации тебя обматерит компилятор. При использовании нормальной модели, 75% отладки производит компилятор, проверяющий чтобы в каждый метод и свойство передавались и ложились только данные и аргументы, совместимые по типу.

Swing и SWT - оба тормозные и замшелые, оба смердят, правда, каждый по-своему.

А JavaFX - вполне себе айс.

Аргументация на уровне маркетоида

Ага, и проведи вечность, решая проблемы, которые не должны тебя касаться

Кстати, вот работаю на play 2 на scala... У тебя не остается впечатления что это куча какого-то беспорядка, склеенного скотчем, написаного школьниками? Прямо штырит рельсами и прочим шлаком от него. Или я просто травмирован миром Spring/JavaEE?

Нам большими потугами удалось сделать модульный, тестируемый и красивый код. Но во всех туториалах куча синглтонов, все завязано на друг-друге и похоже это мало кого волнует. Рубисты и пыхопешники добрались до мира Java. И да, тестируйте HTTP запросами. «Собрать и поделить» как говорил Шариков

Если Lift - вот, то Play 2 - вот

Как один язык может быть производительнее другого ? Бред какой-то