Статья правдива и адекватна более чем наполовину. С большинством описанных факторов мы столкнулись на практике.
Структуры данных — да, они, наверно, расширились с тех времён, но всё равно для достаточно сложного состояния они сильно неудобнее аналогов.
Память — как уже сказал рядом, каждый достаточно толстый, но слабо нагруженный процесс эрланга это чудовищное прожорство. Реальную работу надо втискивать в малое количество сильнонагруженных процессов, иначе будут проблемы. А так втискивать — значит вводить неестественность в проекцию модели на реализацию.
JIT’а по факту нет. Иногда удаётся чуть-чуть сэкономить (процентов 20, когда ожидалось — в разы). Внутренняя VM плохо проецируется на реальные за счёт странных решений типа “а давайте у нас будет 1024 регистра”.
Случаи типа описанных с {ok,Foo}=... у нас происходили с завидной регулярностью.
От себя добавлю проблемы с синхронизацией нод (модуль global это аццкій адъ); с управлением входным потоком, без явного управления впадаешь в положительную обратную связь выедания всей памяти; с отсутствием приоритизации mailbox’а, приводящей к необходимости передавать срочные сообщения через ETS; и много прочего по мелочам. Плюс к тому кривизна всех имеющихся средств деплоймента, каждого по-своему.
Разумеется, и вкусности есть — и очень много. Но мои впечатления от состоявшихся проектов — очень смешанные. Минусов в сумме где-то столько же, сколько плюсов.
не только мягкое планирование, но и плавная сборка мусора всегда.
Всё это перестаёт работать, как только начинается укладка долгоживующих, но относительно слабоактивных сущностей (например, что-то происходит раз в 2 секунды) на процессы Erlang. Тогда оказывается, что его сборка мусора что в автоматическом режиме, что при ручном форсаже неудобна — она дико тратит или память, или время.
Столкнувшись с таким, мы вынуждены были отказаться от персонального процесса на сущность и повторить тот же «подвиг», что Erlang по отношению к pthreads — сделать несколько толстых процессов (по количеству ядер) с деревьями состояний в них. Этот вариант оказался устойчивым.
Задачи обслуживания кратковременных соединений по вебу действительно не способны показать эту проблему — за короткоживущими процессами очистка происходит таки вовремя.
Какой хтмл? Зачем? В школе-то. Школа суть есть база, фундамент.
Фундамент всегда надо давать только на конкретных живых примерах. HTML и есть один из вариантов такого примера. Даже если детали забудутся, сама идея языка разметки стоит внимания.
То же и с программированием.
В Швейцарии его заменяют на Component Pascal (наследник Оберона) — вершина творчества Н.Вирта
«В Швейцарии» в одном отдельно взятом вузе?
(кстати, Гослинг идею виртуальной машины «стырил» у Вирта
UCSD Pascal это 1978 и практически без Вирта. Forth, который в прямом и косвенном шитом коде делал то же самое без громких названий, это 1968.
> радіофізик != розробник ліпстроніки.
Все ваши красивые слова разбиваются о простой факт — топикстартер говорил о направлении “компьютерная инженерия”. Посмотрите на программу этого направления и его специальностей и прочих на РФФ и поймите, что весь ваш пафос был ни о чём. После этого (не раньше) будет иметь смысл продолжать дискуссию.
Насколько я смог понять программу и ориентацию компьютерной инженерии на РФФ, фактически там делают продвинутых сисадминов и разработчиков электроники, но не программистов. До программиста не-только-embedded придётся доработаться самому.
Как известно, для среды, где распределение памяти управляется рантаймом, есть две базовые стратегии опознания ненужных объектов — подсчёт ссылок (по уходу в 0) и полный GC. Подсчёт ссылок не ловит циклические зависимости, но сильно дешевле при малых объёмах данных. Проводились исследования его цены для больших систем (например, не менее 8 процессоров, память в десятки гигабайт и т.д.) и было показано, что с ростом системы цена на подсчёт ссылок растёт настолько, что использование только GC оказывается существенно дешевле. Поэтому в средах, обычно рассчитанных на более-менее «большие» применения, как та же Java, .NET, используется только GC. Ссылок не дам, но можете сами легко найти по ключевым словам.
В случае всяких smart pointers проблема оказывается в большом количестве атомарных операций со счётчиком (которые сильно дороже простых, как бы ни исполнялись) и засорению кэша, когда часть целевого объекта вынуждена постоянно быть закэширована, даже если не читается (любое копирование такого указателя при передаче в функцию или метод уже достаточно, чтобы дёргать счётчик). Если же пытаться избавляться от этого явным заданием конкретного типа владения (own/borrow/share и тому подобное), то резко возрастает опасность получить не тот эффект из-за описок программиста.
В сумме мы имеем тут реализацию классического «мы можем сделать быстро, дёшево, качественно — выберите любые два». Или гимор программисту, или затраты по памяти (где в 2, а где и в 10 раз), или затраты процессорного времени. Каждая реализация оптимизируется с ухудшением одного из этих факторов, смотря что менее важно.
непубличных
Задумывался. Именно так и начинал делать. Но пришлось вытеснить в публичные.
или публичных вложенных классов
Вот это не пробовал. Насколько оно путано в использовании?
но и происходит расширение типа до знакового при любом вычитании (я говорю про chat в java, не знаю как у других).
Вот это расширение и есть полная глупость при работе с данными. Для современного уровня все конверсии между знаковым и беззнаковым (кроме, разве что, констант) должны быть явными. А выражение типа b+1 должно быть или b+1u, или с автоматическим опознанием нужного типа для константы.
(C совершает ту же глупость, но в обратном направлении — при двух операндах, где один беззнаковый, второй преобразуется в беззнаковый.)
То есть тут нет никакой проблемы с порогом в самой по себе беззнаковой арифметике — если нет описанных Вами явных диверсий.
Что такое «5 пальцев», я не понял. Видимо, это идиома какого-то эмпирического метода защиты от переполнений. Но я твёрдо предпочитаю не использовать такую защиту, которую слишком легко проломить не заметив, а использовать в ключевых местах что-то вроде C# «checked» (извините уж за сравнение с конкурентом, но оно само напросилось).
Профсоюзу буде потрібна уніфікація — хочете бути програмістом третьої категорії?
Ви чомусь вважаєте, що такої уніфікації зараз нема. Але той роботодавець, в якого тисячі співробітників, давно її увів до ладу, навіть якщо нікому крім найближчих не показує її. І тільки справа часу, щоб він уніфіковав її з іншими володарями. У такому випадку «зустрічна» уніфікація буде благом.
А воно нам тре?
Мені — ні. Так склалося, що я завжди був ззовні цеї системи, і поки що не бачу причин міняти такий стан. Вам — не вім, бо уперше бачу.
гражданин Нечаев в отчаянном порыве забывает, что понятие «выше рынка» исчезнет как класс.
Из какого пальца высосаны забывание и «отчаянный порыв»?
Но некоторые предпочитают работать «выше рынка» и выбивать себе подобное, слабо интересуясь сколько там получает сосед.
Очевидно, под «некоторыми» Вы имеете в виду себя и надеясь, что уж Вас-то не коснётся заведомая несправедливость. Что ж, я тут скорее на Вашей стороне (против фактов и на той же эмоциональной основе). Но наш круг узок по сравнению с тысячами наёмников нынешних комбинатов типа epam/globallogic/etc, и если фигня таки случится, то от нас ничего не будет зависеть.
А какие-то аргументы кроме эмоциональных есть?
Наверно, мне мешает понять это мой background (как эта путет па рюски?), который даёт, что беззнаковые тривиально понятны и привычны. Здесь предпочту поверить на слово человеку с опытом обучения языку (по крайней мере пока другой такой же не возразит;))
Но мой реальный опыт с Java, а именно, с перепиской одного из компонентов с Python показал, что основные грабли лежат в перегруппировке сущностей по объектам, которая усложняется странными явовскими ограничениями типа необходимости класса для любой отдельной логической сущности или правила, что публичный класс должен лежать в отдельном файле — что превращает код в скопище одноэкранных мелочей и банально мешает понимать всё получившееся. По сравнению с этим возможная проблема от беззнаковых выглядит ничтожной.
Хм... это надо было делать в 2000, а не в 2013.
> Лики хорошо решаются valgrind + проанализируйте владение объектами.
Я уже написал, что valgrind не помогает. Вы как-то слишком выборочно читаете.
> Пo поводу крашей, советую проанализировать thread-safety.
Спасибо, но текущий коллектив уже достаточно компетентен в этих проблемах. Но наследие прошлых героев не решается мгновенно.
Хочу заметить что в BASIC, perl, common lisp был GC еще до появления Java.
Начну с LISP. Не Common LISP, это только одна из реализаций, а все LISP, включая Scheme и несколько других более экзотических веток, в принципе не могут обойтись без GC за счёт конструкции языка. То же самое касается Prolog (ещё
Далее, Perl есть 5 и 6 (которого, считаем, нет). В Perl5 нет GC при его обычном выполнении, несмотря на все рекламные агитки. При обычной работе интерпретатора там работает только подсчёт ссылок. GC включается только между циклами вызова интерпретации кода, что может быть достигнуто только в embedded perl, но не при standalone (/usr/bin/perl). Соответственно, до завершения такого цикла всё с циклическими ссылками «творчески» игнорируется рантаймом. Такого упрощения нет в аналогах (как минимум Python и Ruby имеют полноценный GC).
Упоминая Basic, надо указывать конкретную версию. Для дообъектных версий про GC говорить не приходится. Объектные же были резко ограничены в авторстве (считаем, одна MS) и применении (за пределами Office оно было неизвестно).
Так что Java действительно стала первым широко распространённым языком общего назначения с GC. Разумеется, это не так, как предыдущий комментатор сказал, что она была вообще первой; но ширнармассы (tm) узнали про GC только начиная с Явы. И Ваше замечание верно в общем принципе, но страдает в фактах.
Эту нишу сейчас отъедают D, Go, Rust и ещё десяток аналогов.
А как второе мешает первому?
> Думаю, так же можно делать и с беззнаковыми.
Да можно, конечно, но изврат дикий получается...
Ну, у меня есть подозрения, кто это был. Люди у нас были разные. В том числе и один очень выдающийся любитель писать медленно, идеально по спецификации, но никак не даже на миллиметр за её пределами. Вероятно, ты его и видел.
О чём именно речь про «1000 потоков на ядро»? Чего именно потоков?
А твои наезды на чужой уровень оставь кому-то другому.