Category: it

Category was added automatically. Read all entries about "it".

Ответ на бнопню по C++

Код, который напрямую зовёт std::vector{std::move(foo)} на данных в ощущениях компиляторах (gcc, clang) будет медленнее, чем construct_vector(std::move(foo)), где:

std::vector construct_vector(Foo && foo) {
    std::vector vec;
    vec.emplace_back(std::move(foo));
    return vec;
}


Почему это так случается? Из-за отсутствия оптимизации std::initializer_list. Конструкция вектора через std::vector{} создаёт initializer_list, мувает в него один элемент foo, затем копирует из initializer_list внутрь вектора. К сожалению.

construct_vector же копированием foo не занимается, а делает move construction. Значение вектора попадает в место вызова без копирования, через RVO.

Ну вот так хреново пока работаем с std::initializer_list. В стандарте C14 про это вот что есть: "the underlying array is copy-initialized". Опаньки.

Типичный C++, что ни фича, то засада. JavaScript и то без копирования передавал бы всё :)

P.S. По поводу «почему C++» (mpd) — это было не моё решение. Нам и на Эрланге с сишными вставками неплохо работалось, правда, в сервис работал в десять раз медленнее. Но если у компании есть ресурсы и время на то, чтобы создать поддерживать в тонусе команду C++-програмистов, почему бы и нет? :)

Ключевой момент тут такой: если не заниматься байтодрочерством, C++ из-за подобных недофич (чуть что — копируем! ну или не смогли понять жизненный цикл — тоже на всякий случай скопируем) будет работать не сильно быстрее остальных дефолтных языков, а то и медленнее и/или глючнее. Только если действительно понимать, что происходит, можно выжрать нетривиальный буст по производительности, и, если повезёт, не сильно потерять в безопасности. Но это если такая производительность действительно нужна. На мобилке она, за редкими исключениями, вряд ли нужна. В датацентре (если это не cuda) — уже более интересное распределение. Разница между десятью нодами и сотней нод в плане управления — колоссальна. Между сотней и тысячью — уже речь встаёт о дешевизне датацентра по сравнению с рабочим временем программиста.

Если C++ на вашем продукте позволяет обеспечить эту разницу в 10x, есть средства на программистов и время на их реализацию, почему бы и нет? У нас в MZ — есть. Компания зарабатывает несколько миллионов долларов в день. А в вашем НИИГиТ наверняка нет ни таких средств, ни таких требований к производительности, которые бы требовали кластера из более чем десятка машин, а их оптимизация явно встанет зарплатой программистов дороже, чем выгода от их сокращения.

Светлый идеал 100% покрытия тестами

Что-то я не понимаю эти вот страдания по поводу того, что покрытие кода не 100%. Ну допустим ваша тулза показывает 100%. Что это значит, можно конюшни больше не чистить? А вот и нет:

int f(int a, int b) {
  int arr[2] = { 0, 0 };
  int i = 1;

  if(a == 1) i--;

  if(b == 1) i--;

  return arr[i];
}

И что это вам дало? Покрытие по строчкам 100%, а всё падает.

По опыту, у 84% программистов какой-то blind spot, не позволяющий ощутить масштаб проблемы.

Чувствую себя капитаном, пиша этот пост. Но он нужен.

Keyless SSL™ (shameless plug)

CloudFlare анонсировал, что теперь можно не раздавать сертификаты точкам, которые терминируют SSL трафик.

[1] http://blog.cloudflare.com/announcing-keyless-ssl-all-the-benefits-of-cloudflare-without-having-to-turn-over-your-private-ssl-keys/
[2] https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/

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

В начале двухтысячных у нас в Netli (продались Akamai) появилось желание терминировать SSL, причём, чтобы наши датацентры, стоящие в Китае, Бразилии, России и ещё чёрт-те где, не имели бы приватного SSL-сертификата. Потому что несекьюрно и может утечь. Среди наших клиентов были такие компании, как Dell (dell.com), HP (hp.com), и сертификаты этих сайтов было бы очень грустно утратить в процессе обработки их на этих разнесённых датацентрах.

В районе 2003-2004 я имплементировал этот процесс в виде расширения OpenSSL (добавил туда fibers, чтобы можно было асинхронизировать запросы; изначально в OpenSSL этот процесс синхронен), и набора софта "keyserver", при котором бы ключи хранились на центральных машинах в штатах, а на краевых машинах, в левых датацентрах, терминация SSL приводила бы к асинхронному запросу на генерацию pre-master ключа. На централизованных keyservers ключи на диске хранились в зашифрованном блобе, а ключ от блоба хранился в HSM (от nCipher) в центральном сервере, и передавался кейсерверам только временно.

Процесс мы не запатентовали, потому что наши предыдущие патенты, связанные с простыми инженерными шнягами, шли туговато. Например, моя глупая аппликация US20060098645 так и не прошла.

С тех пор эта же технология безключевого SSL светилась несколько раз в разных патентных аппликациях:

http://www.google.com/patents/US20070074282 (Certeon)
http://www.google.com/patents/US20130156189 (Akamai) — это выглядит ровно как описание моей работы — ну да не мудрено, потому что Akamai купил Netli целиком вместе с её кодом и клиентами, использовавшими безключевую терминацию SSL.

Но эти апликации не прошли. А вот более поздняя апликация от CloudFlare — прошла, и превратилась в патент:

https://www.google.com/patents/US8782774 (CloudFlare)

Вывод? Молодцы, я рад за них ;) Только патент у них non-enforceable, потому что есть prior art, закреплённый в патентах от Certeon и Akamai.

Про "новые основания операционок"

Что-то бред какой-то, что с той, что с другой стороны. Как автор имплементации POSIX API для встроенной операционки ASA/PIX в Cisco Inc, прокомментирую.

> >Вместо файловой системы, очевидно, нужна база данных. По сути, файловая система это и так БД, только не реляционная, без транзакций...
>
> Современные (уже лет 15 как) файловые системы суть иерархические БД с транзакциями.

Ну-ну. Написать в файл, чтобы случайно не наткнуться на truncated файл — это эпопея с mkstemps(3) + rename(2). Чтобы гарантировать то, что fsync(2) сбросил буфера, и они дошли до пластин или флэша — это вообще по стандарту POSIX невозможно, да и кроме того на практике есть множество особенностей, от попытки качественного овладения которыми шаблон прикладного программиста не может не разорвать.

Если же требуется изменить два файла, или не изменить ни одного — это вообще просто пляска с бубном. Предложите алгоритм. А? То-то. На уровне базы все эти вопросы тривиально решаются обрамлением серии операций в транзакцию, а файлуха, которую пытаются выдать в качестве иерархической БД с транзакциями — да идите все в пень!

> >Также как гонять unbounded потоки байт по TCP малой полезности идея (в 100% случаев нужны сообщения, а не поток)
>
> Абсолютно голословное утверждение. Сообщения с проверкой доставки совершенно бесполезны при вещании потокового видео, в интерактивных играх, при передаче низкоприоритетной телеметрии и т.п. До тех пор, пока каналы передачи данных не будут гарантировать доставку данных за определенный промежуток времени, будут востребованы потоковые протоколы, позволяющие терять определенный процент данных в обмен на плавное ухудшение качества сервиса. Например, показывать вместо 48 кадров в секунду 24 лучше чем вообще прерывать трансляцию видео.

Комментатор сознательно решает не замечать логику аргумента.

Вещание потокового видео — серия относительно коротких файлов (в районе мегабайта на файл). Интерактивная игра — серия сообщений, либо HTTP (где один фетч — это по сути один мессадж), либо тот же WebSocket — где обмен сообщениями идёт через message-oriented транспорт, или тупо наверчивают фрейминг а-ля "тут пишем 4 байта длины, потом JSON". Это всё каждый факин раз изобретается заново.

Передача низкоприоритетной телеметрии, это, в лучшем случае, UDP, в среднем — line separated TCP (тот же фрейминг, но не length-prefixed, а \n-separated), а в худшем — SNMP, который суть что? Правильно, TLV.

SMTP — это message oriented транспорт. Один заголовок SMTP-exchange (типа EHLO) или боди целиком — это отдельные сообщения. Сейчас парсинг их осуществляется иногда поиском завершителя строки \n, иногда — поиском пустой строки (\n\n), иногда — поиском точки на пустой строке. В одном и том же факин протоколе! Нет уж, дайте нам нативный message oriented transport, дальше уж мы сами накрутим поверх этого логику, надоело парсить в телах \n-ы.

> >хранить большие бинарные блобы произвольного содержания редко кому нужно.
>
> Утверждать что большие бинарные блобы произвольного содержания никому не нужны может только тот, кто шизофренически игнорирует реальность. Реалии таковы, что средний пользователь хранит именно мультимедийные данные большого и очень большого размера. Фотографии, видео, различные документы, как с текстовым, так и с произвольным содержимым.

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

> >...с неудобным программным API и непрозрачная внутрь файлов (sed/awk чтобы поменять значение поля в конфиге? буээ).
>
> >Любое приложение почти всегда работает со структурированными данными, так зачем мучать котенка и каждого разработчика заставлять придумывать сериализатор и парсер конфигов и документов, когда это можно сделать на уровне системы.
>
> Следующая проблема, вытекающая из необходимости хранения мультимедийных данных - невозможность построения обобщенного API для доступа к их содержимому. Чтобы иметь возможность править что-либо внутри файла через предоставляемое файловой системой API, для каждого формата потребуется писать свой сериализатор и десериализатор. По факту это означает перенос существенной части кода из пространства приложения в пространство файловой подсистемы. И если плагины для работы с XML/JSON/BSON/CSV написать довольно просто, то чтобы полноценно работать со сложными документами типа Photoshop, фото или видео, придется реализовать весь функционал этих приложений внутри ФС. Это чревато ошибками и большими проблемами с безопасностью.

Тут я согласен с комментатором. Более того, такие системы были, тот же DEC VMS filesystem, в итоге разработчиков стошнило и они отложили это фпень.

> Очевидно также, что такие сложные вычисления с потреблением огромного количества памяти невозможно проводить в контексте ядра, а значит, это будет пользовательский процесс. В свою очередь это потребует большого количества переключений контекста исполнения из ядра и обратно. Что очень, очень медленно.

Не очевидно. Почему-то считается, что когда фантазируем про операционку, надо тащить за собой весь груз юниксового багажа, типа контекстов исполнения, etc. Во-первых, почему бы и не притащить это в ядро. Там какого только говна уже нет, типа "иерархических баз данных с транзакциями", и это можно впихнуть. Во-вторых, есть концепции ядерных архитектур типа L4 с их драматически более оптимальным способом переключать контекст. В-третьих, при выполнения множества ядрового кода в линуксах "переключения контекстов" (или того, что под этим подразумевается) и так не делается, ибо там делается гораздо более дешёвый mode switch.

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

Не надо этого, достаточно стандартных, встроенных в ОС/стандартную библиотеку/POSIX/whatnot фрейминга. Поверх этого можно любую проприетарщину городить уже.

Однако, исторический провал DEC VAX Files-11 говорит, что лучше таки площе, ибо концептуально проще.

> >Очевидно, современная ОС должна быть network-aware. Начиная от более толкового сетевого протокола (SCTP? ∅mq?), ориентированного на сообщения
>
> Еще раз. Сообщения мало кому нужны при передаче большого количества данных. Все эти докачки с произвольного места в протоколах FTP, HTTP и других придуманы именно для того, чтобы при потере связности на 90% передачи не повторять заново отправку сообщения в N гигабайт, а докачать только необходимое. Не говоря уже о протоколах распределенного обмена небольшими частями сообщения, например, торрентах.

Ещё раз. FTP имеет внутренний фрейминг (line-separated messages), HTTP имеет внутренний гипербредовый текстово-бинарный message framing, который одновременно и \n-separated, и "\n[␣\t]+"-unseparated, и length-separated, и connection-delimited. Да ёжкин же кот!

Именно этот фрейминг лучше отдать на уровень OS API.

> >а не на поток байт (поверх которого все равно все придумывают сообщения)
>
> Кто - все? Вообще, откуда эта категоричность? Всем якобы нужны сообщения, всем нужна гарантия доставки и т.п.

Да все, все. tonsky прав. Действительно, сложно сказать, кто не придумывает!

> >продолжая более соответствующими современной обстановке буферами (16Kb default TCP write buffer? SRSLY?)
>
> Да, SRSLY. Если сделать буфер большим, а еще лучше - нелимитируемым, это кончится тем, что сделать DDoS сервису не сможет только ленивый.

Игнорамусы оба, откуда 16kb взялось-то? Давно уже минимум на порядок больше, часто на два. Никита, ты RFC 793 прочитал только, и ни документом больше? Андрей, ты просто защищаешь предполагаемый статус кво по инерции, из принципа, очевидно не отдавая себе отчёта, что на самом деле там всё гораздо иначе. Чума!

Всё нормально с буферами у TCP, на практике сейчас в них ничего почти никогда не упирается. В протоколы error recovery — упирается. Но не в буфера или их недостаточный размер.

> >и минимальными возможностями роутинга (message broker вполне хорошо бы смотрелся в качестве системного компонента, и востребованность ∅mq это подтверждает), заканчивая cluster awareness.
>
> Роутинг в качестве системного компонента каждого сервера заставит хранить огромную карту маршрутов. Это ресурсоемко и крайне небезопасно.

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

> >Было бы круто, если бы я мог системными средствами видеть, где, кто и сколько машин вокруг, как-то разумно распределять по ним запросы, следить за их доступностью, броадкастить и общаться между ними.
>
> Вообще говоря, любой, кто читал учебник по стеку TCP/IP умеет посредством использования системного API видеть, сколько машин вокруг, следить за их доступностью, броадкастить их и общаться между ними.

В какой-то степени это так. Broadcast datagrams или даже RAW sockets с одного конца, rpc(3) — с другого. Только речь о том, что это некомфортно низкий уровень. Иначе ZeroConf бы не существовал, например. И даже он слишком низкий. Какой именно уровень нужен: одним, например, API-коллом зарегистрировать себя, свои капабилити, и коллбек, а с другой тачки тоже одним же коллом послать в любую тачку в локальной сети, которая имеет такой-то капабилити, JSON, и получить ответ.

Нет такого. Очень много программить надо, и, если оно даже сверху rpc(3), оно реализовано "на отцепись" и неэффективно для больших нагрузок.

> >Далее, модель процессов. Она построена вокруг предполагаемой интерактивности: stdin, stdout, string arguments, return value, это всё для работы в sh придумано.
>
> Ну, кроме этого есть и процессы, лишенные управляющего терминала, man setsid.

Опять, подозреваю, каждый о своём тут. Сложно комментировать.

> >То что каждый процесс может максимум что вернуть 1 целое число проходит по категории тяжелого детства и деревянных игрушек. Может показаться что это круто и как раз и принесло UNIX модели бешеную популярность, но на деле это заставляет каждый процесс городить парсер на входе и сериализатор на выходе.
>
> Ничто не мешает использовать другие методы межпроцессного взаимодействия. Если автор не в курсе, могу напомнить о существовании каналов, доступа к разделяемой памяти, отображении файла в память, работе через inet/unix socket, системных очередях сообщений, семафорах и многом другом.

Да, именно так, есть некоторое количество средств.

С другой стороны, как только уходим от файлов и пайпов, shell перестаёт быть помощником, и мы получаем закрытую систему, которую не проинтроспектируешь mmap или семафор из шелла?..

> >Программа принимает на вход путь до файла. Зачем? Почему не содержимое файла?
>
> Видимо, автор не знает о существовании pipes. Это печально.

Опять каждый о своём. Речь о application programming paradigm, где ты в argv[], скажем, получаешь структурированный блоб, например, а не char * до файла.

Впрочем, чтобы такое было удобным, надо достаточно развесистый API делать (иногда аргумент это просто аргумент, то есть, строка), и в итоге будет всё сосать. Как сейчас ОК.

> >Если я хочу состыковать ее с другой программой, мне придется научить их разговаривать через файл. Спрашивать на stdout вопрос, а на stdin ждать ответа (привет, ssh)?
>
> По сути своей, это ничем не отличается от работы с так любимой автором 0mq. Там те же самые вызовы read/write/poll.

Очень даже отличается, ибо 1) message oriented, 2) асинхронные запросы можно посылать.

> >Это низ composability, ниже некуда. Ориентированность на использование в sh рождает целую кучу бредовых паттернов (как вернуть из процесса строку, например?), о которых в обычных PL никогда не слышали.
>
> Куда конкретно требуется вернуть строку? В зависимости от конкретных условий есть множество вариантов. Суть *nix в том, что нет одного единственно правильного метода взаимодействия, всегда можно выбрать наиболее оптимальное решение.

Мне тоже нравится unix programming model, она показала свою жизнеспособность.

> >Есть целая индустрия command-line arg parsers, считаете это хороший знак? Понятно, что программа на Java не передаст программе на Perl в качестве return value свой объект, но вот json может, и это будет куда лучше хрен-пойми-как-tab-space-and-comma-delimited вывода какой-нибудь утилиты типа ls, который еще и на stdout уйдет. Как это могло бы работать: TermKit и мой пост про смерть терминала.
>
> Так и сейчас программа на java может передать json программе на Perl. Не совсем понятна суть претензии.

Именно. Проблема формулируется так: давайте уже наконец сделаем универсальный формат данных и во все языки вставим поддержку оного.

Придумали.

Восхитились.

Заиспользовали.

Протошнило, стало легче. В итоге, от XML сейчас рожки да ножки. А теперь JSON на коне. Всё это время flat array of bytes продолжал рулить и бибикать, поддерживая любой очередной конъюнктурный форматный бред.

Кстати, в JSON нельзя передать просто тупо набор байтов, у него нет этого в модели данных. Приходится или конвертировать в base64, или эскейпить, а потом out of band передавать информацию о том, как оно там лежит, другим программистам. В MessagePack нельзя передать строку, только последовательность байтов.

> >Можно еще больше расфантазироваться, предложить делать каждый запускаемый процесс network addressable и приделать к нему mailbox (место, куда кто угодно может положить сообщение, а процесс прочитать).
>
> Нельзя давать возможность писать кому угодно куда угодно. Рано или поздно это кончится DDoS или утечкой критически важных данных. Чтобы все это работало, необходимо разработать службы авторизации и аутентификации, а к ним - систему мандатного доступа. Кроме того, необходимы ACL, отсекающие доступ без каких-либо сложных проверок (например - только по маске сети).

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

> >Модель украдена у Эрленга, но так ведь не зря — только Эрленгу пока и удается делать массивные кластерные приложения разумным количеством усилий.
>
> Опять голословное утверждение. Ну вот почтовый сервис на 1.5 петабайта данных с несколькими сотнями нод в кластере - это массивное кластерное приложение или нет? Исходя из своей практики, межпроцессное взаимодействие - самая простая часть задачи. Гораздо затратнее написать быстрый и качественный парзер того же MIME.

Как ни странно, message-oriented транспорт и соответствующий стандартный структурированный формат данных помог бы с этой задачей. Нахрена парсить MIME? Потому что тупо его писали слой за слоем поверх text-oriented протоколов, в которых концепции messages не было. tonsky как раз за то, чтобы эту концепцию первазивно внедрить, и перестать хернёй маяться, наконец. HTTP 2.0 добавляет её поверх HTTP 1.x, кстати.

> >Интеграция чего угодно с чем угодно внезапно становится тривиальной вещью.
>
> Интеграция чего угодно с чем угодно и сейчас тривиальна, см про средства IPC.

О да, конечно.

> >Логично, если бы в ОС была встроенная time series database в которую логировалось бы всё происходящее внутри этой же системы и можно было бы прямо зайдя на http://host:17801/ посмотреть на графики.
>
> Сейчас любой может зайти по ssh на хост и посмотреть все необходимые метрики. Ну да, при этом надо сделать запрос не вид "GET /... HTTP/X.X", а "ps -axw" или "sockstat -4", но суть от этого не меняется никак.

Это уже application/userland level, это неинтересно.

> >С интерактивностью у меня вообще давние счеты. Мне кажется правильным строго забанить ходить по ssh на сервера, потому что куча бед и усилий у людей тратится на то, чтобы сделать себе удобный dev environment на удаленном сервере. Чувак, ты что там забыл, сервером надо управлять с пульта, а не сидеть на нём, настраивая тему в vim-е. Запускать процессы, инспектировать ФС (SELECT) и редактировать конфиги (UPDATE по БД), мониторить метрики можно по сети. Заметьте, что все перечисленные вверху средства network friendly. Плюсом будет огромное количество сэкономленных усилий, когда станет понятно, что sh-like интерактивность большинству программ не очень-то и нужна.
>
> Ну так и пульт должен как-то ходить на сервер и делать все те вещи что делаются через ssh. Канал связи должен быть защищенным. В итоге получится тот же ssh, но с другими именами команд. Мне, если честно, непонятно, какой смысл менять одно на другое.

Мне тоже непонятно, ssh ok. Плюс керберос или LDAP.

<бессмысленный обмен репликами поскипан>

Serendipities in Silicon Valley

Когда я переехал в Долину, столкнулся здесь с одной из необычных забав в разговорах. Люди вспоминают, кого куда "звали", а они решили туда не пойти, потом жалели. Один из первых запомнившихся мне разговоров был чем-то вроде «Тут ко мне подходит чувак, говорит что он Джерри, и у них наклёвывается такая клёвая новая конторка и нужен сисадмин. Я ему говорю, нет, мол, работа есть уже. Этой конторкой оказалось Yahoo и я был бы сотрудником номер 5, и мог бы купить остров.»

Я теперь тоже могу участвовать в таких разговорах ;)

лева привет

меня зовут ян.

you probably don't now me. i am CEO and co-founder of WhatsApp. i see you done some erlang/server stuff work in the past which is pretty amazing.

[...]

-- jan


2011 год. Блин.

P. S. 19 миллиардов долларов. Я рад за них! :)

Куда катится клиентская разработка

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

Яков-зачинатель: http://jakobz.livejournal.com/236681.html
Ваня-продолжатель: http://gliv.livejournal.com/125078.html
Никита-тролль: http://tonsky.livejournal.com/285722.html

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

1. Очень разнятся скиллы тех, кто приходит в отрасль. От учителей истории, которые переучились на курсах (если повезёт), до дизайнеров и программистов на коболе. У них всех очень разные представления о том, что такое программирование. Очень разная толерантность к крутизне кривых обучения. Очень разные задачи. Поэтому будет продолжаться наблюдаться множество локальных оптимумов языков, фреймворков, и их комбинаций.
2. Веб-программирование как ниша развивается очень быстро. Ещё недавно SPA не было и JS использовался в качестве свистелок и перделок для статического сайта. Теперь на нём и SPA, и мобайл, и энтерпрайз. Пока эта область развивается (а она всё ещё развивается, краёв почти не видно), будет постоянный импеданс между возможностями, предоставляемыми подходами к программированию (нарисуйте и продолжите вектор от jquery как энхансер до Flight как фреймворк, и далее), и требованиями очередного витка развития.
3. Интерплей между языками программирования и фреймворками очевидно, порождает "косые" решения и неоптимальности, когда замечательный язык не имеет хорошего сопряжения с замечательным фреймворком (Roy/Elm + React?), и наоборот. Придётся страдать.
4. Некоторые подходы в программировании, такие как в FP, требуют отдельной фазы погружения программиста в них. Желательно, через что-нибудь чистое, типа хаскеля. Немногие хьюманы смогут пройти этот энергетически-временной барьер, поэтому объективно более лёгкие в использовании и развитии (при наличии в голове уже готовой и прогретой FP-парадигмы и, скажем, STM) фреймворки не смогут набрать себе критическую массу пользователей, а значит, будут всё время отставать с точки зрения развитости фреймворков и способности на них быстро набросать какой-нибудь state of the art интерфейс.
5. Разговор о языках и фреймворках остаётся не более чем вкусовщиной вплоть до тех пор, пока не начинает влиять на бизнес. Разговор об интересных языках и фреймворках сам по себе может усиливать вероятность успеха компании, потому что компания будет иметь возможность легче привлекать интересных людей. Или снижать вероятность успеха, потому что вместо практичных людей будет набирать черт-знает кого, кто понапихает в проект каких-нибудь скобок, потом хрен с ними разберёшься, хоть индусам раздавай переписывать всё нафиг. В любом случае не исключена парадоксальная ситуация, когда 1) компания наняла умных людей; 2) у компании таки будет успех; 3) но при этом те инструменты, которые они используют, являются энергетически даже менее оптимальными, более проблемными, чем обычнейшая связка из традиционнейших инструментов типа JS+Bootstrap.

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

Clojure at Echo

Originally posted by tonsky at Clojure at Echo
Провел в команде опрос на тему Кложи. Опрошено три респондента с 4-5 месячным опытом использования (основные разработчики нашего clojure-driven продукта) и двое с 1-2 месячным (переключились на другой проект). Результаты анонимизированы и подсокращены до смысловой части.

Насколько сложно читать?

— Несложно, дело привычки
— Читать сложнее Эрленга
— Python (2,3) < Java, Erlang (4) < Clojure(6,7)
— Примерно Ruby (без Rails)
— Очень зависит от автора

Насколько сложно писать?

— Очень легко
— Легче, чем в ООП языках
— Меньше кода, только суть
— Упирается в понимание кода
— Проблем с отладкой не возникает (отладочная печать она и в Африке отладочная печать)

Как быстро начинает получаться писать что-то полезное?

— Неделя
— Недели две
— От недели и больше
— С учетом, что есть опыт в ФП

Наиболее сложные области

— Concurrency примитивы
— Двухсторонний interop
— Meta параметры
— Идеология

Стала ли Clojure естественным, «своим» языком?

Все: Пока нет, но потенциально да.

Полезно

— Гибкость, лаконичность
— Особенно чувствуется при переключении на другой язык
— Скорость написания кода («опа-опа и готово»)
— Java—библиотеки
— Синтаксис удобен для файлов конфигурации

Раздражает

— Скобки (1 чел.)
— Привязанность к Java (2 чел.)
— Непрозрачность кода из-за макросов (2 чел.)
— Медленный старт, тяжеловесность платформы (2 чел.)

Общее впечатление

— Писать на Clojure очень легко. Видимо поэтому мы так много пишем и переписываем то, что пишем.

— Большая неограниченная свобода. Можно писать как угодно и в любом стиле. Код становится зеркалом разработчика.

— Clojure идеально подходит для соло проектов и достаточно плохо подходит для командной разработки.

Наиболее полезные ресурсы

clojure.org
clojuredocs.org
— The Joy of Clojure
— Clojure Programming
— Programming Clojure


От себя (lionet). Вот этот пункт — ключевой:

— Clojure идеально подходит для соло проектов и достаточно плохо подходит для командной разработки.

Именно из-за особенностей влияния среды на командную работу, в Echo на серверной стороне использует в основном Erlang, и только в тех местах, где активный народ принципиально прётся от какой-то альтернативной технологии (i.e., OCaml, Clojure) написано на них.

Erlang Курсы 2013 Киев средина апреля

Originally posted by maxim at Erlang Курсы 2013 Киев средина апреля
Приуроченый анонс к Erlang Factory SF Bay Area 2013

Обзор функциональных языков программирования, место Эрланга в мире ФП, чем руководствовались разработчики языка, как использовать Erlang в промышленности, какие выгоды это несет, что такое ASN.1, современные приложения GProc, Nitrogen, RabbitMQ, Riak и и.д. Лекция + Практическое занятие. Четыре академических часа с перерывом. Первая сессия будет в средине апреля в субботу. Количество сессий 2-3 (две-три субботы). Зал уточняется и будет выбираться в зависимости от количества зарегистрированных участников.



Подробнее: http://maxim.livejournal.com/404745.html