привычное vs прогрессивное апи

Ясен пень феррари.

Java и жигули - некорректное сравнение, имхо.

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

Какой вариант предложить рынку: тот, который валяется на каждом углу и уже всех достал, или тот, который претендует на хоть какую-то новизну? Воистину, тяжелый выбор!

Гляди в чем неоднозначность.
Пришел человек домой после работы и решил покодить Just for fun.
Открывает код, вроде бы жава, «да не совсем жава».
И все бы хорошо, но внезапно оказывается, что вот конкретно в этом месте использовать циклы можно, но так неудобно, что хоть вешайся.
Что приводит его к необходимости загуглить мануал по Скале и прочитать конвенции, «зачем сделано так».
А там не просто конвенции, а скажем, целое эссе на двадцать страниц о рефакторинге циклов, объяснение хвостовой оптимизации итп. С одной стороны, можно попробовать принять конвенцию на веру, но тогда следование Вере будет самой меньшей из возникающих проблем.
И это уже серьезная нагрузка на моск. Пока человек продирается сквозь дебри, весь for fun может уже выветриться.
Ну, на работе-то такой проблемы нет, fun, не-fun, Господин сказал кодить под скалу - будешь кодить под скалу, куда ты денешься с подводной лодки.
Но в линуксе-то другая совсем система, люди именно что занимаются днем своей ненужной работой, а вечерами кодят for fun на остатках сил когда уже ничего не хочется.
И по идее, Java как раз отлично сдизайнена для такого применения, даже сквозь прости б-же, спринг, можно продраться на автодополнении в IDE и на копипасте из интернетов, вообще не прилагая интеллектуальных усилий на саму платформу (а направляя их на нечто более важное, типа смысла того, что ты кодишь)

Java и жигули - некорректное сравнение, имхо.

Зато mysql и жигули вполне.

Выбор делается на основании задачи, а не личных предпочтений (хотя, в соло это важнее). Например, если взять вместо мускла постгрес, то как монго решит с кривым саппортом хранимых процедур часть задач, которые удобно решаются именно таким способом? Далее по монге, как скоро ты задолбаешься писать map/reduce при выборках из нескольких коллекций сразу? Ах, у тебя памяти дофига и места на жестком диске бесконечное: дублицируй все и никакого геммора, как только выйдешь за предел в 16мб (или уже 32мб?) на запись, тогда ты подумаешь о гридфс, ага.

ЯП не играет в данном случае никакой роли, ибо оба строятся на VM. Другое дело C/C++ vs Java/Scala, или Haskell vs Java.

java+spring+hibernate+mysql
Жигули, короче.

http://localhost/home/user/да_ты_шаришь.gif

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

Чувак, новые штуки - это всегда одна головная боль. Если жизнь этому еще не научила, сейчас самое время понять.

или Haskell vs Java

в чем разница между haskell vs scala в плане апи (а не научных вычислений)? То, что в хаскеле ленивость более естественна? Да и на скале легко все это запилить, если совсем уж не офигивать, типа специально писать бесконечные циклы которые каким-то образом «не цепляются» и поэтому прога работаепт якобы-корректно на хацкеле и повиснет на чем-то другом

ИМХО креативность надо вкладывать в проект, а не в исследование инструментов. Понимаю конечно что жаба это неуклюжее нечто.

Никакой неоднозначности нет.

Если ты ищешь людей, которые мыслят в духе «В джаве есть все, что мне нужно, я к ней привык, я выучил все паттерны, я не хочу осваивать что-то еще», то задумываться о скале и не стоит.

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

И предлагая вакансию скала-разработчика

имеется в виду free/opensource community, кодящее линукс в свободное от работы дворником либо ночным сторожем время, а не fulltime job для узких корпоративных специалистов

возможно, с этим спорить не берусь =)

привычное vs прогрессивное апи

Я бы не стал противопоставлять. Так называемое «прогрессивное» очень часто оказывается таким отстоем. Я не говорю конкретно. Просто общее наблюдение.

Так все еще проще: получать фан от разработки на джаве могут только редкие мазохисты, которые и так работают явистами. Много ли среди них двойных мазохистов, желающих и после работы заниматься тем же самым? Сомневаюсь.

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

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

в чем разница между haskell vs scala в плане апи (а не научных вычислений)?

Я не об апи. А о том, что создавались языки для разных целей. И если scala это компонентно-ориентированный язык, то хаскель это чистая функциональщина. Конечно, типовые задачи решаются одинаково, но узкоспециализированные решаются особенностями ЯП. Вот для примера сравнение Haskell vs F# vs Scala.

mongo

Как можно юзать в качестве основной БД штуку, где нету никаких механизмов обеспечения целостности базы?

какие еще есть претензии к mongo? Давай сформируем список что ли)

Так-то оно так, но как же мы получим развитие, если никто не будет продвигть новые технологии? Как раз таки большинство нового привносит коммерческая разработка, а не for fun.

Без серьёзной заинтресованности разработчиков линукс так и будет топтаться на месте. Человек либо должен хотеть заработать и поэтому будет учиться, либо быть фанатиком и опять же учиться. Только так возможен прогресс.

позволяющие делать красивую магию.

Я бы сказал наоборот. Как раз работу NoSQL решений, имхо, проще понять и там гораздо меньше магии. Это не трёхэтажные sql-запросы городить и скрывать ими просчёты в схеме таблиц.

нету никаких механизмов обеспечения целостности базы?

Под этим подразумеваются транзакции? Ручками :) http://docs.mongodb.org/manual/tutorial/perform-two-phase-commits/

какие еще есть претензии к mongo?

стрёмный язык запросов :) Эдакий лисп для SQL.

Под этим подразумеваются транзакции?

Не только. Хотя бы банальный NOT NULL там есть? Отслеживание foreign key? Каскадное удаление? Триггера?

Какой вариант привлечет больше новых кодеров?

Тут следует поднять еще другой вопрос - в каком варианте кодеры будут грамотными специалистами, а не формошлепами, продирающимися сквозь Spring на автодополнении?

Да в принципе никаких претензий у меня больше нет. Просто как-то привык хранить структурированные данные в чем-то, что хоть как-то может гарантировать сохранность их структуры. А монго, получается, просто свалка json-документов произвольной структуры.

Хотя бы банальный NOT NULL там есть? Отслеживание foreign key? Каскадное удаление? Триггера?

Ты хочешь sql и думаешь в терминах sql. Как раз от этого nosql и уходит. Вместо этого предлагается использовать простые хранилища с ограниченным функционалом. Плюсы — достаточно легко прогнозируемая скорость, хороше масштабирование, лёгкое обслуживание и поддержка.

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

а кому нужно хранилище без транзакций и триггеров

Я сказал не так, а «кому нужно такое хранилище в качестве основной БД». Хотя надо было сказать не «основной», а «единственной». Я вполне за то, чтоб использовать несколько СУБД в одном проекте, разделяя четко структурированные табличные данные, и данные к которым не предъявляются такие жесткие требования по структуре.

Шняжку можно реализовать

...да на чем угодно - всем пофиг.

ну если взять искаробочный линукс, то у нас вообще конфиги хранятся плейнтекстом в /etc/**.conf в непонятном формате, какой уж тут acid

Конфиги по большей части не являются структурированными данными со сложными взаимосвязями. Для них базоданновое понятие целостности вообще неприменимо.

У монго безусловно есть своя ниша. Просто я б ее юзал все-таки второстепенной БД для оптимизации, а не основной. Хотя, с удовольствием бы послушал аргументированные мнения, отличные от моего.

у нас вообще конфиги хранятся плейнтекстом в /etc/**.conf в непонятном формате

Они очень редко меняются и в большинстве случаев руками и неконсистентность/опечатки в большинстве случаев легче обнаружить.

Это не то же самое что потерять платёжную информацию, например, когда юзер в одной вкладке жмёт «оплатить», а в другой «очистить корзину» :)

Вот, например: http://habrahabr.ru/post/149047/

Лично меня даже больше волнует не консистентность данных силами ДБ, а как их не потерять в случае того что свет моргнёт/сервер повиснет или вообще сдохнет.

Лучше бери кложуру - это модно, молодежно, прогрессивно.

Ну вот оттуда цитата:

Всегда будьте готовы к нецелостной информации.

А дальше там идет предложение написать собственные костыли для обеспечения целостности. Зачем, если они уже один раз реализованы и отлажены в реляционных СУБД?

Угу. Конкретно mondodb не обладает развитыми средствами обеспечения консистентности. Это не значит nosql == «no transactions». Гугловая база (big table или то что поверх), например, транзакционна.

Но в целом, имхо, надо менять подход к проектированию. Вот тут есть некоторые мысли: http://stackoverflow.com/questions/2212230/transactions-in-nosql

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

красивую

scala

в чем разница между haskell vs scala

В том, что даже хаскель читабельнее скалы

ты точно не путаешь с clojure? ))))))) ((там в скобках можно потеряться)). Какие конкретно претензии к скале? (олсо, ты, надеюсь юзаешь IDE, а не блокнот? В блокноте действительно тяжко, но блокнотоюзеры должны страдать :-)

Много буков же

Первый вариант. Но только не mongo!

У монго особенность - она лочит всю бд целиком при записи. Раньше лочился весь сервер.

кто нибудь терял в производительности из за этого?

1

почему не просто golang?

А я писал тебе в гугл+, а ты проигнорил. А еще координаты в профиле оставил, как приличный.

Пиши на скале, у них ржачный чятик. Вот уже полчаса сидят и пинают чатбота по поводу выражений в xml: https://dl.dropboxusercontent.com/u/12869350/snapshot93.png

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

Ээээ знаешь, я даже на сотовый не отвечаю уже недели две) И почту не читаю - вначале автоматически жал «отметить всё как прочитанное», потому понял, что ее можно просто не открывать. И скайп в инвизе, итп. Не обижайся, пожалуйста.

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

Но только не mongo!

А что?

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