Ответ на пост «Забавный способ найма в IT»

Erlang vs С++. Спонтанные вопросы по незнакомому Erlang на собеседовании.

Ну это принципиально разные языки. Императивная парадигма у С++ и функциональный Erlang. Статическая типизация у С++ и иммутабельность+динамическая типизация у Erlang. Куча легковесных потоков, бешенная масштабируемость у Erlang и проблемы с производительностью на ровном месте у С++.

По своему и по опыту команды скажу, что среднее время изучения "базы" Erlang - это где-то полгода. Т.е. спустя полгода программист сможет выдавать адекватный production код на Erlang. Большая часть С++'сных вакансий в геймдеве, где весь упор внимания на программирование рендера, шейдеров, ECS и paper'ов.

Ожидать от С++сника, что он сходу разберется в новом для себя функциональном языке очень странно, т.к. (повторюсь) интерес среднего С++'сника вообще не пересекается с миром других парадигм и других (неподобных С++) ЯП. Многие С++'cники идеологию C# не понимают, и не могут смириться, что C# во много раз удобнее и средний код на нем сильно быстрее аналогичного кода на С++ (C# - выше уровнем, больше пространства для оптимизации, 1000 человеколет вложены в оптимизацию CLR на уровне компиляции и т.д.).

На мой взгляд - это ошибка HR и тех. лидера команды.

1. Зачем звать всех подряд и тратить свое время на нерелевантных кандидатов, когда можно обозначить знакомство с Erlang, Haskell, F# и Lisp ) как обязательное требование?
2. Откройте бесплатные онлайн курсы по Erlang, а потом через 3 месяца отправьте офферы самым толковым.

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

Типичный программист

1K постов6.3K подписчика

Добавить пост
Вы смотрите срез комментариев. Показать все
46
Автор поста оценил этот комментарий

средний код на нем сильно быстрее аналогичного кода на С++ (C# - выше уровнем, больше пространства для оптимизации, 1000 человеколет вложены в оптимизацию CLR на уровне компиляции и т.д.)

О как, оказывается managed ЯП, выполняемый виртуальной машиной, быстрее чем опасный ЯП, компилируемый в нативный код. Ведь чем выше уровень ЯП тем больше пространства для оптимизации. Как ещё Closure/Scala всех по производительности не зарулили, или Javascript с V8 который ещё сильнее заоптимизирован чем эта ваша CLR...

раскрыть ветку (23)
11
Автор поста оценил этот комментарий

Тоже резануло глаза. Но может быть автор имел ввиду, что крупное приложение на C# окажется быстрее такого же крупного на C++ (и на которое затратили относительно столько же времени) за счет того, что разработчик сможет больше внимания уделить общей картине, а не деталям реализации. Во всяком случае, я хотел бы верить, что автор имел ввиду это.

раскрыть ветку (1)
Автор поста оценил этот комментарий

Да. Чуть ниже ответил более развернуто.

15
Автор поста оценил этот комментарий

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

раскрыть ветку (7)
7
Автор поста оценил этот комментарий

Это заявлялось ещё во времена первых версий .NET. Примерно в то что же время Майкрософт заявляла, что IIS поддерживает тысячи пулов. И оба заявления с реальностью никак не коррелировали.

Что-то поменялось?

раскрыть ветку (1)
5
Автор поста оценил этот комментарий

Связи не наблюдаю, но вам наверняка будет полезно познакомиться ближе с актуальным дотнетом - много воды утекло лет за 15 со времен отказа от .NET Framework. ASP.NET Core сейчас один из самых быстрых "жирных" веб-фреймворков.

3
Автор поста оценил этот комментарий

Толку с этого знания если его нет у байткода на входе JIT. А машину ещё греть надо

раскрыть ветку (4)
5
Автор поста оценил этот комментарий

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

раскрыть ветку (3)
5
Автор поста оценил этот комментарий

Да. А потом лови на своих сервисах когда сборщик решил всех нафиг послать и поработать дворником. Разогретый. В плюсах хер ты позволишь кому то орудовать в работе своего процесса, если тебе это критично. И не надо тут теперь про кучу ломающихся костылей писать про дворника

раскрыть ветку (2)
2
Автор поста оценил этот комментарий

Это уже ближе к истине: любишь нагружать GC - мирись и с его тормозами.

Автор поста оценил этот комментарий

А зачем ты тогда выбрал средство языка, не под задачу?

1
Автор поста оценил этот комментарий

Время, которое вы тратите на оптимальный код на С++ сильно больше, чем время, которое вы тратите на решение задачи на других языках (C#), а разница в производительности не существенна.


Как тех. руководитель, я буду выбирать средство под задачу. А не свято тащить везде С++, потому что его прекрасно знаю.

раскрыть ветку (1)
2
Автор поста оценил этот комментарий

потому что его прекрасно знаю.

Оно и видно по уровню статьи, где у C++ "проблемы с производительностью на ровном месте", а святой C# во много раз удобнее и быстрее и замшелые плюсовики "не могут с этим смириться". Если вы хотели быть объективным, в статье это у вас плохо получилось.

Автор поста оценил этот комментарий

хуйни не неси, ок? виртуальная машина вообще-то располагает тем, что плюсовому компилятору и не снилось, а именно рантайм статистикой по выполняемому коду. на высоких тьерах оптимизации нормальный компайлер порежет у тебя минимум 90% бранчей, не говоря о прочем. я, уж поверь, хороший плюсовик, достаточно хороший, что занимаюсь, внезапно, именно разработкой виртуальных машин, и мне и в голову не придет сравнивать быстродействие плюсов и явки на средней сложности бизнес-задаче. если не веришь, вот тебе совсем простенькая задачка: распарсить несколько-гигабайтный JSON на предмет записей определенного формата и слить результат в базу данных, -- напиши ее на плюсах, чтобы все правильно, чтобы все путем, а потом сделай то же самое на явке и сравни. результат тебя сильно удивит

раскрыть ветку (10)
1
Автор поста оценил этот комментарий

По-вашему перф зависит исключительно от того, по горячим ли путям ходит cpu??? А боксинг, GC, JIT в Java за бесплатно? Задачи, где за счёт собранной в рантайме статистики Java выиграет в быстродействии, конечно, бывают, но огульно говорить, что Java по быстродействию всегда зарулит это бред.


вот тебе совсем простенькая задачка: распарсить несколько-гигабайтный JSON

Забавно, что вы в качестве задачи взяли ту, где branch prediction скорее всего не играет критической роли. Писать мне ничего не надо, всё уже написано: https://github.com/simdjson/simdjson. Давайте что там лучшее в java для парсинга json, и померяем перф.

раскрыть ветку (3)
Автор поста оценил этот комментарий

даже не знаю, что ответить ..., который на предложение решить простую задачу на плюсах, с соответствующими трудозатратами (2-3 человеко-часа), а потом сравнить производительность решения с аналогичным решением на java, приводит ссылку на проект, который сотня с лихуем высококвалифицированных инженеров разрабатывает на протяжении 20 лет, и трудозатраты на который измеряются ДЕСЯТКАМИ ТЫСЯЧ человеко-часов. где от плюсов только расширения, бо все остальное написано на векторных интринсиках или в машинных кодах, так как соответствующих интринсиков еще тупо нет. что именно ты хотел этим сказать?


что там лучшее есть в java? JNI, блядь, устроит?

раскрыть ветку (2)
1
Автор поста оценил этот комментарий

разрабатывает на протяжении 20 лет

все остальное написано на векторных интринсиках

Вы упоролись? Первый релиз simdjson судя по гитхабу состоялся в 2020 году, а самому формату JSON чуть больше 10 лет, никакому парсеру JSON не может быть 20 лет. Большая часть написана на C++, с критичными кусками на интринсиках. И что, мне в защиту C++ нельзя приводить примеры кода, использующие все возможности языка в тч интринсики?


сотня с лихуем высококвалифицированных инженеров

Ну если Java такая прекрасная и быстрая, что ж другая сотня высококвалифицированных инженеров не собралась и не написала парсер JSON, который зарулит парсеры на C и C++ и станет индустриальным стандартом? Бизнес такой парсер с руками оторвёт.


с соответствующими трудозатратами (2-3 человеко-часа)

Это что, мне типа парсер json с нуля писать за 2-3 часа? Сомневаюсь, что это возможно, кажется вы не очень представляете масштабы и сложность этого формата. Я предполагал, что мне разрешено взять любой готовый парсер из плюсовой экосистемы и написать простой высокоуровневый код поверх него - фильтр и вывод в БД. Берите какой угодно готовый парсер из экосистемы Java, пишите то же самое. При чём здесь JNI я не очень понимаю. Если вас не устраивает что я могу брать внешние парсеры json на плюсах, тогда давайте задачу проще - инверсия порядка слов в каждой строке текстового файла на пару Гб, без внешних библиотек.

раскрыть ветку (1)
Автор поста оценил этот комментарий

слушай, либо ты выключаешь режим еблана, либо иди нахуй. мой поинт предельно простой: решение ТИПИЧНОЙ энтерпрайз-задачи выполняемое ТИПИЧНЫМ энтерпрайз-разработчиком с крайне большой вероятностью будет выигрывать в перфе на java. все! не больше и не меньше. и это ровно то, что утверждал ТС. никто не утверждает, что java или шарп -- золотые пули, которые в клочья разорвут плюсы на ЛЮБОЙ задаче.


никто не заставлял тебя писать JSON-парсер на плюсах за 3 часа, тебе нужно было всего лишь выбрать из очень большого щитдампа записи определенного формата. потоки по количеству ядер мапят куски файла в память, и гонят по ним regex_search, сливая найденные записи в преаллоцированный буфер, при переполнении которого сливают данные в базу. все! что здесь сложного? строк 300-400 от силы. был конкретно многогигабайтный лог от кастомера, куда срали все его компоненты подряд, кто текстом, кто json'ом, кто во что горазд. из этого лога потребовалось выбирать для анализа вполне определенные записи и сводить их в базу из трех связных таблиц. и вот на этой несложной и вполне себе типовой для бизнеса задаче, как оказалось java превосходит плюсы процентов на 25-30%.


вот тебе еще пример: клиент L2 в оригинальной плюсовой сборке под париками в COA или на осадах приходилось перезагружать каждые полчаса, бо он тупо вставал колом из-за тотальной деградации хипа, а еретичный L2J с его "небесплатным" GC спокойно тащил сутками без каких-либо лагов.


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


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

Автор поста оценил этот комментарий

"Хороший плюсовик", прочитай в комментах ниже подобный пример, что я оформил. Во-первых, я не говорил про Java (правильное произношение "джава", а не "явка").

Во-вторых, забавно слышать от человека, который позиционирует себя, как крутой С++ сник, который пишет виртуальные машины "хуйни не неси" в публичном пространстве.

В-третьих, я занимаюсь разработкой и внезапно оптимизацией игровых движков, и опыт далеко не ограничивается стандартным набором форков для UE4/UE5, проектах на Unity и  CryEngine.

В-четвертых, повторю для тебя: в условиях ограниченного времени и конкретной задачи, программист C# будет думать о том, как ее решить и скомпиленный байт код будет нативным и "лучшим" (здесь в кавычках, потому что лучшим=быстрым), чем твои каракули на С++. Потому что типичный Сшник будет думать, как написать код в принципе и не устроить лишнее копирование, и лучшую синхронизацию потоков, если даже доберется до нее. А в итоге забудет поставить noexcept в операторе, из-за чего move semantic'а "не сработает". Когда код на C# в принципе более отказоустойчивый, потому что язык не позволяет этим заниматься программисту и больше доверяет компилятору.

В-пятых, я нигде и не утверждал что в итоге идеальный=оптимальный код можно написать только на C#. В пределе(на дальней дистанции) С++ выигрывает, но времени займет больше, багов будет больше и человеко часов будет затрачено существенно больше.

раскрыть ветку (5)
1
Автор поста оценил этот комментарий

извини, мне нехуй делать читать всю ветку, клацни ссылку на пример

раскрыть ветку (1)
Автор поста оценил этот комментарий

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

1
Автор поста оценил этот комментарий

"Во-вторых, забавно слышать от человека, который позиционирует себя, как крутой С++ сник, который пишет виртуальные машины "хуйни не неси" в публичном пространстве"
Крутые плюсовики не ругаются матом и какают бабочками?

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

Автор поста оценил этот комментарий

ты дурак? если ты чутка пошевелишь мозгом, то блядь поймешь, что я с тобой СОВЕРШЕННО СОГЛАСЕН. я возражал не тебе, блядь, а твоему оппоненту. иди нахуй пей зеленку

раскрыть ветку (1)
Автор поста оценил этот комментарий

:) LMAO. Извини не так читаю. Много агро вылилось в теме. Defense mode и все дела.


Спасибо.

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку