LINUX.ORG.RU
ФорумTalks

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

 ,


0

3

http://dev.by/blogs/main/java-protiv-c-kakoy-yazyk-proizvoditelnee-v-realnyh-...
Поскольку я не пишу ни на одном из этих языков, своих выводов делать не буду. Но невооруженным глазом заметна «объективность» статьи. Нет? :)

Как напишешь, так и будет.

На статью забей, после того как он без буферизации из сокета читал я уже статью не смотрел

vertexua ★★★★☆ ()
Последнее исправление: vertexua (всего исправлений: 1)

Только руби! Это все языки триллиона бойлерплейта и мнимой производительности. А gui явы - просто треш.

special-k ★★★ ()
Ответ на: комментарий от special-k

А gui явы - просто треш.

Какой именно?

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

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

reserved ()
Ответ на: комментарий от ymn

Практика показывает Руби fast enough, все равно твое реальное приложение будет работать со скоростью самого узкого места, и это как раз примерно скорость руби или даже хуже. Зато, за счет динамических и синтаксических возможностей языка ты сможешь лучше прорабатывать архитектуру.

special-k ★★★ ()
Ответ на: комментарий от reserved

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

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

Потому что не замшелый?

vertexua ★★★★☆ ()

о5 говношарпик пиарят?
вердикт: закопать. Не нужно

Karapuz ★★★★★ ()
Последнее исправление: Karapuz (всего исправлений: 1)
Ответ на: комментарий от special-k

На руби прототипы хорошо писать, чтобы потом выкинуть написанное и переписать на более быстром ЯП. Как та история о твитторе, правда только немножко запоздали тогда

nerdogeek ()

Java и C# — это просто языки

Дальше не читал.

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

Под который готовые либы и программистов быстрее и проще найти.

shahid ★★★★★ ()
Последнее исправление: shahid (всего исправлений: 1)
Ответ на: комментарий от nerdogeek

На руби прототипы хорошо писать

Разработка это непрерывный процесс, твое приложение - вечный прототип.

На руби прототипы хорошо писать

Звучит как будто на непрототипе приложение каменеет и более не развивается, наверно так и есть.

Как та история о твитторе

Не более чем рекламный трюк для scala.

special-k ★★★ ()
Последнее исправление: special-k (всего исправлений: 1)
Ответ на: комментарий от shahid

Дальше не читал.

Можно сделать поблажку на оговорку. Но да, он не прав

vertexua ★★★★☆ ()
Ответ на: комментарий от nerdogeek

Успели же.

На руби прототипы хорошо писать, чтобы потом выкинуть написанное и переписать на более быстром ЯП. Как та история о твитторе, правда только немножко запоздали тогда

Мне кажется вы перепутали причину со следствием. Они не «немножко опоздали» когда ушли с Ruby, но наоборот, успели в нужный момент, когда писали первую реализацию. Быстрое создание работающего сервиса позволило занять нишу.

Camel ★★★★★ ()
Ответ на: комментарий от shahid

Либы решают.

Под который готовые либы и программистов быстрее и проще найти.

Верное суждение.

Camel ★★★★★ ()
Ответ на: комментарий от special-k

Это ваши догадки? Ведь не может же быть так что scala просто лучше решила задачу чем руби, как подсказывает вам ваш опыт запуска таких проектов как твиттер, верно?

Ну и вот теперь твиттер страдает, теряет прибыли в миллиарды долларов, чтобы использовать scala, вместо руби. Но распускает слухи что все хорошо

vertexua ★★★★☆ ()
Последнее исправление: vertexua (всего исправлений: 3)

Нет?

Ага. Что значит «пр-ть языка»? Эффективность разработки? Работоспособность прожек?

ЗЫ Статью не читал.

Deleted ()
Ответ на: комментарий от special-k

Зато, за счет динамических ... возможностей

сможешь лучше прорабатывать архитектуру.

А ты великолепен в своей упорности. Расскажи как, как динамика улучшает архитектуру? Сдаётся мне, что ничуть не улучшает, а позволяет запилить элегантные костыли

RedPossum ★★★★★ ()
Ответ на: комментарий от Deleted

Что значит «пр-ть языка»? Эффективность разработки? Работоспособность прожек?

Эффективность прожек в данном контексте

nerdogeek ()
Ответ на: комментарий от vertexua

Логика подсказывает, что от rails + jruby есть неплохой гандикап оптимизаций, включая банальный переход от jruby к mri или rubinius, а спустя немного и скорость jruby возросла http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.html. К тому же rails это все-таки тяжеловесный фрэймворк, они могли написать свой, более легковесный и характерный для них на основе rack, или на основе goliath (ведь они сделали это для scala с нуля!).

special-k ★★★ ()
Ответ на: комментарий от special-k

Если могли, то почему-же страдают и терпят такие страшные муки используя Ruby вместо Scala? Ведь вот, по вашим словам, есть же все

vertexua ★★★★☆ ()
Ответ на: комментарий от vertexua

Ведь не может же быть так что scala просто лучше решила задачу чем руби

Может по какой-то совокупности параметров очевидных для разработчиков твиттера, но не из-за производительности.

Ну и вот теперь твиттер страдает

А что, раньше он страдал? Или, ты хочешь сказать, что залог успеха именно scala? Т.е. пишем что-нибдуь на scala и обогащаемся само-собой?)

Если могли, то почему-же страдают

Кто?

special-k ★★★ ()
Ответ на: комментарий от special-k

А что, раньше он страдал? Или, ты хочешь сказать, что залог успеха именно scala? Т.е. пишем что-нибдуь на scala и обогащаемся само-собой?)

Нет, но от переписывания с руби при похожих алгоритмах, да скорее всего будет работать быстрее, выше надежность, проще в поддержке, шире доступ к существующим технологиям и библиотекам.

vertexua ★★★★☆ ()
Ответ на: комментарий от nerdogeek

Подпишусь. Вчера писал себе качалку субтитров с addic7ed, как только код на руби расползся на поэкрана, появилось стойкое желание плеваться. Пришлось переписывать на джаве, и, хоть и вышло слегка многословно, но зато а) httpclient & jsoup - удобные и простые, б) алгоритмы перекладывать в код на статически типизируемых языках (и рефакторить, я капитаню) в разы проще.

cdshines ★★★★ ()
Ответ на: комментарий от special-k

от rails + jruby есть неплохой гандикап оптимизаций

Рожденный ползать летать не может. Да и зачем оно нужно, если есть play-framework со stateless и асинхронностями?

shahid ★★★★★ ()
Ответ на: комментарий от special-k

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

cdshines ★★★★ ()
Ответ на: комментарий от RedPossum

Да в контексте архитектуры вообще насрать, потому что (мы про ООП, да?) архитектурой занимаются ДО выбора языка программирования. А если кто-то пишет код в надежде, что «вот тут мы можем иногда сравнивать число с датой, а иногда - со строкой (иногда число может быть nil, но дальше по коду воткнем костыль и для этого)», это верный признак, что пора раскошеиться на архитектора))

cdshines ★★★★ ()
Ответ на: комментарий от vertexua

скорее всего будет

Ну и где же более быстрый, надежный, простой и широкий rails на scala, тогда.. Нет и не будет.

special-k ★★★ ()
Ответ на: комментарий от shahid

play-framework

чей код хостится на проекте, написанном на руби https://github.com/playframework/play20

Да и зачем оно нужно, если есть play-framework со stateless и асинхронностями?

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

special-k ★★★ ()
Последнее исправление: special-k (всего исправлений: 1)

тот, на котором писать под целевую платформу быстрее.

aiqu6Ait ★★ ()
Ответ на: комментарий от shahid

Я считаю, что система в целом должна писаться на руби, и только в каких-то узких ее частях переходить на более низкоуровневые вещи (если в том будет смысл), причем можно это делать путем запуска другого приложения, пусть даже на том же play. Ты же не имеешь ввиду, что кроме play больше ничего не нужно и это такая панацея.

special-k ★★★ ()
Ответ на: комментарий от special-k

Извините, я хоть и новичок, но вы опрометчиво несете ересь — с каких-таких пор Java низкоуровневый язык?

NiceForce ()
Ответ на: комментарий от vertexua

Я понимаю, что с этим трудно смириться, но да, основное преимущество руби это всяческое удобство в написании кода (от фрэймворков тестирования до установки библиотек) при вполне сносной скорости выполнения. Это язык архитектуры системы.

special-k ★★★ ()
Ответ на: комментарий от cdshines

алгоритмы перекладывать в код на статически типизируемых языках (и рефакторить, я капитаню) в разы проще.

Ты забыл ещё один факт - при условии нормальной модели в статической типизации, компилятор производит 75% отладки :-)

no-dashi ★★★★★ ()
Ответ на: комментарий от no-dashi

Нормальная модель - это такая, которая не в С и крестах, так?

RedPossum ★★★★★ ()
Ответ на: комментарий от special-k

Ты же не имеешь ввиду, что кроме play больше ничего не нужно и это такая панацея.

Не, я имел ввиду, что play и прочие чикагобоссы рождаются, когда любителям RoR совсем надоедает «оптимизировать», и они садятся и переписывают любимый веб-фреймворк на скаложабах и иных языках, попутно исправляя кучу архитектурных косяков.

И потом оказывается, что перепись пишется быстрее, окупается лучше и работает быстрее, чем бесконечная оптимизация рубей, даже завернутых в jvm.

Также, ниже по треду появится комментарий от пользователя Bioreactor со ссылками на длинные списки вакансий java-программистов и сравнительно короткие для ruby.

shahid ★★★★★ ()
Ответ на: комментарий от special-k

Даже если вм делает Java (условно) низкоуровневым, то в таком ключе руби логично назвать — сверхвысокоуровневым, благодаря абстракции.

NiceForce ()
Ответ на: комментарий от vertexua

Их finagle все-таки покруче

Для своих задач удобен и местами незаменим. Но у нас тут про руби, рельсы и их аналоги-заменители.

shahid ★★★★★ ()
Ответ на: комментарий от special-k

чей код хостится на проекте, написанном на руби https://github.com/

Жидхаб — это там где поиск весь на жабе через elasticsearch, некоторые куски на эрланге, git-сервер на сях, а без этого всего сайт малополезен?

shahid ★★★★★ ()
Последнее исправление: shahid (всего исправлений: 1)
Ответ на: комментарий от vertexua

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

Да и куда лучшая читаемость кода очевидна.

Даже для тестов здесь http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=y... на java и scala нужно писать в 3-4 раза больше кода. 100к кода, или 400к .. На подобном уровне основную роль будет играть грамотность архитектурных решений, а не платформа.

Динамичность языка позволяет эффективней разрабатывать код, легко заменяя крупные части (и делать это тривиально, библиотеками!), чему помешает, во-первых, типизация в статических языках.

Вывод, шансы лучше проработать архитектуру в руби выше.

special-k ★★★ ()
Ответ на: комментарий от special-k

Не совсем. ) Хотел было написать про твиттер, но во время понял, что разговор выйдет за рамки моей компетенции.

NiceForce ()
Ответ на: комментарий от shahid

а без этого всего сайт малополезен?

Я где-то сказал, что все на свете нужно переписать на руби? Низкоуровневым языкам компактные задачи - и это unixway.

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

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

special-k ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.