уповноважений по милицях в Дарницькі печери
  • Erlang — так ли он крут?

    к нам приходили ваши люди
    При этом 2 месяца фигачили 45КБ бессмысленный ген_сервер пустышку.

    Ну, у меня есть подозрения, кто это был. Люди у нас были разные. В том числе и один очень выдающийся любитель писать медленно, идеально по спецификации, но никак не даже на миллиметр за её пределами. Вероятно, ты его и видел.

    Слышал, что ты неплохой специалист, но читая тебя такого впечатления не возникает. 1000 потоков на ядро :)

    О чём именно речь про «1000 потоков на ядро»? Чего именно потоков?
    А твои наезды на чужой уровень оставь кому-то другому.

  • Erlang — так ли он крут?

    Статья правдива и адекватна более чем наполовину. С большинством описанных факторов мы столкнулись на практике.
    Структуры данных — да, они, наверно, расширились с тех времён, но всё равно для достаточно сложного состояния они сильно неудобнее аналогов.
    Память — как уже сказал рядом, каждый достаточно толстый, но слабо нагруженный процесс эрланга это чудовищное прожорство. Реальную работу надо втискивать в малое количество сильнонагруженных процессов, иначе будут проблемы. А так втискивать — значит вводить неестественность в проекцию модели на реализацию.
    JIT’а по факту нет. Иногда удаётся чуть-чуть сэкономить (процентов 20, когда ожидалось — в разы). Внутренняя VM плохо проецируется на реальные за счёт странных решений типа “а давайте у нас будет 1024 регистра”.
    Случаи типа описанных с {ok,Foo}=... у нас происходили с завидной регулярностью.
    От себя добавлю проблемы с синхронизацией нод (модуль global это аццкій адъ); с управлением входным потоком, без явного управления впадаешь в положительную обратную связь выедания всей памяти; с отсутствием приоритизации mailbox’а, приводящей к необходимости передавать срочные сообщения через ETS; и много прочего по мелочам. Плюс к тому кривизна всех имеющихся средств деплоймента, каждого по-своему.

    Разумеется, и вкусности есть — и очень много. Но мои впечатления от состоявшихся проектов — очень смешанные. Минусов в сумме где-то столько же, сколько плюсов.

  • Erlang — так ли он крут?

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

    Всё это перестаёт работать, как только начинается укладка долгоживующих, но относительно слабоактивных сущностей (например, что-то происходит раз в 2 секунды) на процессы Erlang. Тогда оказывается, что его сборка мусора что в автоматическом режиме, что при ручном форсаже неудобна — она дико тратит или память, или время.

    Столкнувшись с таким, мы вынуждены были отказаться от персонального процесса на сущность и повторить тот же «подвиг», что Erlang по отношению к pthreads — сделать несколько толстых процессов (по количеству ядер) с деревьями состояний в них. Этот вариант оказался устойчивым.

    Задачи обслуживания кратковременных соединений по вебу действительно не способны показать эту проблему — за короткоживущими процессами очистка происходит таки вовремя.

  • «С чего начать мальчугану в 13 лет...»

    Какой хтмл? Зачем? В школе-то. Школа суть есть база, фундамент.

    Фундамент всегда надо давать только на конкретных живых примерах. HTML и есть один из вариантов такого примера. Даже если детали забудутся, сама идея языка разметки стоит внимания.

    То же и с программированием.

  • Принцип выбора технологии C# vs Java заказчиком?

    В Швейцарии его заменяют на Component Pascal (наследник Оберона) — вершина творчества Н.Вирта

    «В Швейцарии» в одном отдельно взятом вузе?

    (кстати, Гослинг идею виртуальной машины «стырил» у Вирта

    UCSD Pascal это 1978 и практически без Вирта. Forth, который в прямом и косвенном шитом коде делал то же самое без громких названий, это 1968.

  • Радиофизический (компьютерная инженерия) VS кибернетический (информатика) факультет КНУ

    > радіофізик != розробник ліпстроніки.

    Все ваши красивые слова разбиваются о простой факт — топикстартер говорил о направлении “компьютерная инженерия”. Посмотрите на программу этого направления и его специальностей и прочих на РФФ и поймите, что весь ваш пафос был ни о чём. После этого (не раньше) будет иметь смысл продолжать дискуссию.

  • Радиофизический (компьютерная инженерия) VS кибернетический (информатика) факультет КНУ

    Насколько я смог понять программу и ориентацию компьютерной инженерии на РФФ, фактически там делают продвинутых сисадминов и разработчиков электроники, но не программистов. До программиста не-только-embedded придётся доработаться самому.

  • Java Платформа

    Как известно, для среды, где распределение памяти управляется рантаймом, есть две базовые стратегии опознания ненужных объектов — подсчёт ссылок (по уходу в 0) и полный GC. Подсчёт ссылок не ловит циклические зависимости, но сильно дешевле при малых объёмах данных. Проводились исследования его цены для больших систем (например, не менее 8 процессоров, память в десятки гигабайт и т.д.) и было показано, что с ростом системы цена на подсчёт ссылок растёт настолько, что использование только GC оказывается существенно дешевле. Поэтому в средах, обычно рассчитанных на более-менее «большие» применения, как та же Java, .NET, используется только GC. Ссылок не дам, но можете сами легко найти по ключевым словам.

    В случае всяких smart pointers проблема оказывается в большом количестве атомарных операций со счётчиком (которые сильно дороже простых, как бы ни исполнялись) и засорению кэша, когда часть целевого объекта вынуждена постоянно быть закэширована, даже если не читается (любое копирование такого указателя при передаче в функцию или метод уже достаточно, чтобы дёргать счётчик). Если же пытаться избавляться от этого явным заданием конкретного типа владения (own/borrow/share и тому подобное), то резко возрастает опасность получить не тот эффект из-за описок программиста.

    В сумме мы имеем тут реализацию классического «мы можем сделать быстро, дёшево, качественно — выберите любые два». Или гимор программисту, или затраты по памяти (где в 2, а где и в 10 раз), или затраты процессорного времени. Каждая реализация оптимизируется с ухудшением одного из этих факторов, смотря что менее важно.

  • Java Платформа

    непубличных

    Задумывался. Именно так и начинал делать. Но пришлось вытеснить в публичные.

    или публичных вложенных классов

    Вот это не пробовал. Насколько оно путано в использовании?

  • Java Платформа

    но и происходит расширение типа до знакового при любом вычитании (я говорю про chat в java, не знаю как у других).

    Вот это расширение и есть полная глупость при работе с данными. Для современного уровня все конверсии между знаковым и беззнаковым (кроме, разве что, констант) должны быть явными. А выражение типа b+1 должно быть или b+1u, или с автоматическим опознанием нужного типа для константы.

    (C совершает ту же глупость, но в обратном направлении — при двух операндах, где один беззнаковый, второй преобразуется в беззнаковый.)

    То есть тут нет никакой проблемы с порогом в самой по себе беззнаковой арифметике — если нет описанных Вами явных диверсий.

    Что такое «5 пальцев», я не понял. Видимо, это идиома какого-то эмпирического метода защиты от переполнений. Но я твёрдо предпочитаю не использовать такую защиту, которую слишком легко проломить не заметив, а использовать в ключевых местах что-то вроде C# «checked» (извините уж за сравнение с конкурентом, но оно само напросилось).

  • Знания vs Ответственность (или где справедливость?)

    Профсоюзу буде потрібна уніфікація — хочете бути програмістом третьої категорії?

    Ви чомусь вважаєте, що такої уніфікації зараз нема. Але той роботодавець, в якого тисячі співробітників, давно її увів до ладу, навіть якщо нікому крім найближчих не показує її. І тільки справа часу, щоб він уніфіковав її з іншими володарями. У такому випадку «зустрічна» уніфікація буде благом.

    А воно нам тре?

    Мені — ні. Так склалося, що я завжди був ззовні цеї системи, і поки що не бачу причин міняти такий стан. Вам — не вім, бо уперше бачу.

  • Знания vs Ответственность (или где справедливость?)

    гражданин Нечаев в отчаянном порыве забывает, что понятие «выше рынка» исчезнет как класс.

    Из какого пальца высосаны забывание и «отчаянный порыв»?

    Но некоторые предпочитают работать «выше рынка» и выбивать себе подобное, слабо интересуясь сколько там получает сосед.

    Очевидно, под «некоторыми» Вы имеете в виду себя и надеясь, что уж Вас-то не коснётся заведомая несправедливость. Что ж, я тут скорее на Вашей стороне (против фактов и на той же эмоциональной основе). Но наш круг узок по сравнению с тысячами наёмников нынешних комбинатов типа epam/globallogic/etc, и если фигня таки случится, то от нас ничего не будет зависеть.

  • Знания vs Ответственность (или где справедливость?)

    А какие-то аргументы кроме эмоциональных есть?

  • Java Платформа

    Наверно, мне мешает понять это мой background (как эта путет па рюски?), который даёт, что беззнаковые тривиально понятны и привычны. Здесь предпочту поверить на слово человеку с опытом обучения языку (по крайней мере пока другой такой же не возразит;))

    Но мой реальный опыт с Java, а именно, с перепиской одного из компонентов с Python показал, что основные грабли лежат в перегруппировке сущностей по объектам, которая усложняется странными явовскими ограничениями типа необходимости класса для любой отдельной логической сущности или правила, что публичный класс должен лежать в отдельном файле — что превращает код в скопище одноэкранных мелочей и банально мешает понимать всё получившееся. По сравнению с этим возможная проблема от беззнаковых выглядит ничтожной.

    Підтримали: Dmytro Sirenko, Gremlin
  • Java Платформа

    Хм... это надо было делать в 2000, а не в 2013.

  • Java Платформа

    > Лики хорошо решаются valgrind + проанализируйте владение объектами.

    Я уже написал, что valgrind не помогает. Вы как-то слишком выборочно читаете.

    > Пo поводу крашей, советую проанализировать thread-safety.

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

  • Java Платформа

    Хочу заметить что в BASIC, perl, common lisp был GC еще до появления Java.

    Начну с LISP. Не Common LISP, это только одна из реализаций, а все LISP, включая Scheme и несколько других более экзотических веток, в принципе не могут обойтись без GC за счёт конструкции языка. То же самое касается Prolog (ещё 70-е), Erlang (с конца 80-х), всё семейство ML и прочих ФЯ и вокруг. Но контект обсуждения автоматически предполагает домен императивных языков, а не функционально-декларативных.

    Далее, Perl есть 5 и 6 (которого, считаем, нет). В Perl5 нет GC при его обычном выполнении, несмотря на все рекламные агитки. При обычной работе интерпретатора там работает только подсчёт ссылок. GC включается только между циклами вызова интерпретации кода, что может быть достигнуто только в embedded perl, но не при standalone (/usr/bin/perl). Соответственно, до завершения такого цикла всё с циклическими ссылками «творчески» игнорируется рантаймом. Такого упрощения нет в аналогах (как минимум Python и Ruby имеют полноценный GC).

    Упоминая Basic, надо указывать конкретную версию. Для дообъектных версий про GC говорить не приходится. Объектные же были резко ограничены в авторстве (считаем, одна MS) и применении (за пределами Office оно было неизвестно).

    Так что Java действительно стала первым широко распространённым языком общего назначения с GC. Разумеется, это не так, как предыдущий комментатор сказал, что она была вообще первой; но ширнармассы (tm) узнали про GC только начиная с Явы. И Ваше замечание верно в общем принципе, но страдает в фактах.

  • Java Платформа

    Эту нишу сейчас отъедают D, Go, Rust и ещё десяток аналогов.

  • Java Платформа

    А как второе мешает первому?

  • Java Платформа

    > Думаю, так же можно делать и с беззнаковыми.

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

← Сtrl 1... 395396397398399...407 Ctrl →