Отчет по поиску работы летом 2020 в Бэй Эрии

[Вячеслав Викторович]

сейчас пишут миллионы сотни тысяч рукожопов. Тут как бы без расстрелов и репрессий проблему не решить...

Ну он как бы и изначально для рукожопов, которые не в состоянии осилить арифметику указателей, проектировался.
Но тем не менее: NULL pointer exception - в жабе самая распространённая ошибка.

Ну есть уже Котлин, там этой проблемы нет. Да и у многих других языков, которые компилируются в том числе и в байткод.
Вообще мне нравится движение к лаконичности. Я имею ввиду, что надо и размер кода тоже сравнивать. Есть множество аспектов, которые не менее важны, чем производительность.

[Krys-Krys]

сейчас пишут миллионы сотни тысяч рукожопов. Тут как бы без расстрелов и репрессий проблему не решить...

Ну он как бы и изначально для рукожопов, которые не в состоянии осилить арифметику указателей, проектировался.
Но тем не менее: NULL pointer exception - в жабе самая распространённая ошибка.

Ну есть уже Котлин, там этой проблемы нет. Да и у многих других языков, которые компилируются в том числе и в байткод.
Вообще мне нравится движение к лаконичности. Я имею ввиду, что надо и размер кода тоже сравнивать. Есть множество аспектов, которые не менее важны, чем производительность.

Позиций с Kotlin кстати довольно много вижу в ФБ, но они все для Андроида. Там и Джава конечно же тоже.
Обычно как-то так -
Kotlin/Java for Android, and Python/C++ on the backend.

[Мальчик-Одуванчик]

На Питоне самое оно написать прототип, заменив впоследствии критические в плане производительности части кусками из плюсов.

[Вячеслав Викторович]

сейчас пишут миллионы сотни тысяч рукожопов. Тут как бы без расстрелов и репрессий проблему не решить...

Ну он как бы и изначально для рукожопов, которые не в состоянии осилить арифметику указателей, проектировался.
Но тем не менее: NULL pointer exception - в жабе самая распространённая ошибка.

Ну есть уже Котлин, там этой проблемы нет. Да и у многих других языков, которые компилируются в том числе и в байткод.
Вообще мне нравится движение к лаконичности. Я имею ввиду, что надо и размер кода тоже сравнивать. Есть множество аспектов, которые не менее важны, чем производительность.

Позиций с Kotlin кстати довольно много вижу в ФБ, но они все для Андроида. Там и Джава конечно же тоже.
Обычно как-то так -
Kotlin/Java for Android, and Python/C++ on the backend.

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

[M. Ridcully]

мне кажется вы заблуждаетесь, ява ничем не медленне ц. Собственно всё зависит от алгоритма, правильный алгоритм будет работать примерно одинаково. Вот давайте решите любимую задачу Крис-Крис с литкода на Ц и сравним насколько она в десять раз работает быстрее, чем на яве.

А Дед Мороз - существует?

Алгоритм важен, никто не спорит, и литкод именно про алгоритмы. Но когда судят про "правильность" алгоритма, обычно имеют в виду абстракцию - cost model.

Реальные программы исполняются не на абстрактных моделях, а на вполне себе физическом железе. И учитывать особенности этого железа часто не менее важно, чем алгоритм. C++ изначально создавался как язык, на котором - при необходимости - можно спуститься на как угодно низкий уровень без необходимости что-то кодить на ассемблере. Другим важным пинципом в C++ является zero cost abstractions (и хотя в реальности это не всегда абсолютно так, но очень близко). Балодаря этим двум принципам правильная программа на C++ будет всегда не медленнее (а обычно - быстрее) программы, написанной на любом другом языке.

А теперь расскажите про Деда Мороза.

[uncle_Pasha]

Не нравится cpp - можно учить rust.

[Вячеслав Викторович]

мне кажется вы заблуждаетесь, ява ничем не медленне ц. Собственно всё зависит от алгоритма, правильный алгоритм будет работать примерно одинаково. Вот давайте решите любимую задачу Крис-Крис с литкода на Ц и сравним насколько она в десять раз работает быстрее, чем на яве.

А Дед Мороз - существует?

Алгоритм важен, никто не спорит, и литкод именно про алгоритмы. Но когда судят про "правильность" алгоритма, обычно имеют в виду абстракцию - cost model.

Реальные программы исполняются не на абстрактных моделях, а на вполне себе физическом железе. И учитывать особенности этого железа часто не менее важно, чем алгоритм. C++ изначально создавался как язык, на котором - при необходимости - можно спуститься на как угодно низкий уровень без необходимости что-то кодить на ассемблере. Другим важным пинципом в C++ является zero cost abstractions (и хотя в реальности это не всегда абсолютно так, но очень близко). Балодаря этим двум принципам правильная программа на C++ будет всегда не медленнее (а обычно - быстрее) программы, написанной на любом другом языке.

А теперь расскажите про Деда Мороза.

Железо становится всё более быстрым и дешевым, а труд программистов всё более дорогим. ФБ идёт против этих тенденций, надеясь сэкономить на спичках железе. Ну окей, понятно. Но когда то же железо станет настолько дешевым, что затраты на программистов станут дороже? Даже на триллионах запросов. Что тогда, переписывать с ц на яву го или хаскел?
Собственно задача низкоуровневой оптимизации - это задачи компилятора и/или виртуальной машины. Их совершенствование идёт постоянно и даже со специализацией для различных задач.
Собственно там и надо прилагать усилия, а не оптимизировать на низком уровне каждую отдельную программу.
Ну и скажем, есть ещё один аспект - это функциональная сложность. У ФБ - она скажем не самая высокая. Есть много областей, где функциональность более обширна, но требования к производительности не столь высоки.
Так вот, если есть тенденция к расширению функциональности ФБ, то долгосрочная стратегия фокус на Ц - с этой точки тоже проигрышная.

[Вячеслав Викторович]

Не нравится cpp - можно учить rust.

Что тогда, переписывать с ц на яву го или хаскел rust?

[apex]

Вообще мне нравится движение к лаконичности...

Образец лаконичности: была давно книга по алгоритмам для программируемых советских калькуляторов. ~100 команд максимум.

[rx300]

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

Пацаны в FB, конечно, дураки. Забыли посчитать маржу по формуле форумных экспертов.

[rx300]

Вообще мне нравится движение к лаконичности...

Образец лаконичности: была давно книга по алгоритмам для программируемых советских калькуляторов. ~100 команд максимум.

Дьяконов - наше фсе!

[Big Cheese]

Ну, может и не все, но большинство явное - и, подозреваю, что погоду делают именно они. Я интервьюировался во что-то более обще-сетевое - SDN и т.д. - сплошная Циска.

Да, в Циске, говорят, много индусов.. У меня на прошлой работе были пара оттуда, вполне, кстати, вменяемые ребята.
Хотя странно - индусы по канону должны по Жабе специализироваться, а в network, наверно, больше C/C++ идет.

[M. Ridcully]

Для usdt, они сделали, чтобы это без похода в kernel и обратно (что, теоретически, совсем не нужно) работало?

Интересно, их кто-то еще использует?

В смысле? Вас удвляет то, что кому-то може потребоваться трейсить userland code?
bpftrace это может, если что. Но они это делают из kernel, что как бы мало смысла имеет, и неэффективно.
Есть альтернативы вроде lttng-ust, там usdt, вроде, правильно симплементирован, но уж больно тяжеловесно все в использовании (практического опыта нет, но документация уже испугала).
В bpftrace подкупает удобство front end tool, хорошо подходит для ad hoc analysis.

Глубоко не интересовался, но посмотрите на предмет systemtap with dyninst

Ок, спасибо, поищу по этим словам.

[Big Cheese]

Еще, наверно, можно добавить zero trust и вообще всякие security use cases, но все равно +1, что технология весьма нишевая.

Что в наше время тебует наименьшей отдачи рабочего времени и оплачивается лучше чего-либо еще, чем нишевые технологии?
А с точки job security - зависимость только одна: Linux, да кернел поновее, что в итоге будет практически везде.

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

Тот же инфосек был весьма посредственной нишей Ой-Ти с оплатой по тарифу "сисадмин-эникейщик" (т.е. никак) до тех пор, пока Злобные Хацкеры не нагнули энтерпрайз в разгар Цыфровой Трансформации.

Или вот пресловутым искуственным интеллектом с 80-х годов занимались без особого успеха, так что к началу 2000-х в теме остались только самые упртые. А через 10 лет звезды грамотно расположились, и некоторые таки неплохо на этом поднялись. И даже те, кто вовремя к этому мышинному лернингу примкнул (типа Андрея Ына сотоварищи) чувствуют себя имхо намного лучше, чем те, кто пилит тот же BPF (которому тоже лет 30 наверно?) в каких-нибудь, не дай бог, Ривербедах.

Все ИМХО, разумеется.

[uncle_Pasha]

Для usdt, они сделали, чтобы это без похода в kernel и обратно (что, теоретически, совсем не нужно) работало?

Интересно, их кто-то еще использует?

В смысле? Вас удвляет то, что кому-то може потребоваться трейсить userland code?

Нет, я имел ввиду именно statically defined tracepoints.

[Big Cheese]

мне кажется вы заблуждаетесь, ява ничем не медленне ц. Собственно всё зависит от алгоритма, правильный алгоритм будет работать примерно одинаково. Вот давайте решите любимую задачу Крис-Крис с литкода на Ц и сравним насколько она в десять раз работает быстрее, чем на яве.

Почему-то на моей практике с джавой всегда больше геммороя.

Ну на яве сейчас пишут миллионы сотни тысяч рукожопов. Тут как бы без расстрелов и репрессий проблему не решить...
вот зачотный сайт по измерению производительности конкретных алгоритмов, реализованных на разных языках:
https://benchmarksgame-team.pages.debia ... /java.html
С исходниками! Очень познавательно!

Тыкнул наугад в первый попавшийся исходник на С - не нашел ни одного malloc(). Там все эти алгоритмы чисто цифродробилки? Если так, то понятно, почему разницы между языками нет..

[M. Ridcully]

Нет, я имел ввиду именно statically defined tracepoints.

Ну да, именно statically defined нужны!
Чтобы не беспокоиться об API stability, optimized out functions, etc.

[Вячеслав Викторович]

Вообще мне нравится движение к лаконичности...

Образец лаконичности: была давно книга по алгоритмам для программируемых советских калькуляторов. ~100 команд максимум.

собственно речь о размере исходного кода. Ну и движение от императивного программирования к функциональному наблюдает во многих языках. В последних плюсах тоже вроде что-то уже есть.
Это не только к лаконичности, но и общей производительности, за счёт возможности распараллеливания вычисления функций, кэширования результатов функций, более лёгкой низкоуровневой оптимизации на уровне компилятора и т.д.
Но из-за отсутствия сборщика мусора в Ц функциональный стиль программирования может породить массу проблем с памятью. Я не знаю, кто-нибудь использует в ФБ функциональный стиль программирования на Ц?

[apex]

Вообще мне нравится движение к лаконичности...

Образец лаконичности: была давно книга по алгоритмам для программируемых советских калькуляторов. ~100 команд максимум.

Дьяконов - наше фсе!

У меня есть! Одна из дюжины книг, которые привез в штаты. Также привез "Секреты запуска двигателя."

[OtherSide]

почитал с интересом. не понятно только что значат все эти 5/6 уровни? мне в трудовой в рф обычно писали че попало от инженер программист до старший инженер программист, но с обязанностями это никак не пересекалось. как это меряется вообще?
выбрать менеджера и комманду тоже не понял это как вообще? не наоборот разве?

[Krys-Krys]

почитал с интересом. не понятно только что значат все эти 5/6 уровни? мне в трудовой в рф обычно писали че попало от инженер программист до старший инженер программист, но с обязанностями это никак не пересекалось. как это меряется вообще?
выбрать менеджера и комманду тоже не понял это как вообще? не наоборот разве?

На этом сайте можно сравнить уровни в разных компаниях - https://www.levels.fyi/

[OtherSide]

не ну по зарплате то понятно. не понятно как оценивать себя типа я уровень 5. И искать сразу 5-ый. Это же кому как приглянешься. вот это не ясно

[Krys-Krys]

не ну по зарплате то понятно. не понятно как оценивать себя типа я уровень 5. И искать сразу 5-ый. Это же кому как приглянешься. вот это не ясно

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

[OtherSide]

Дык не разумнее ли резюме писать под нужный уровень, а не ждать что кинут кость по миниму из за кривого резюме?

[Херовимчик]

почитал с интересом. не понятно только что значат все эти 5/6 уровни?

так еще в зависимости от компании это будут разные уровни (разные обязаности)
5 может быть как mid, sr или вообще staff