Из моих наблюдений крупных западных компаний в которых я работал (и их софт/сервисы/железо используется повсеместно):
Начальство и непотизм. Это только на словах открытость и инклюзивность. Менеджмент окружён друзьями, и они просто не видят реальности, т.к. друзья не хотят потерять свое положение, если будут рассказывать горькую правду. Плюс многие менеджеры считают себя умнее чернорабочих (именно так они воспринимают программистов), и принимают необоснованные решения.
Квоты социальной справедливости. Если нанимать людей "по повестке", компании получают налоговые вычеты. Более того, потом этих людей практически невозможно уволить, потому что они сразу начнут раздувать шум и даже судится, потому что типа их уволили из-за их расы/ориентации/тд. Этим людям нельзя ни в чем возражать, поэтому их проекты, какие бы не были бредовые, будут поддерживаться. Их код нельзя честно ревьювить, ибо опять-таки будет шум и суды.
Снежинки. В школе их приучают, что они snowflake (т.е. уникальные и неповторимые), поэтому на работе они себя ведут как непризнанные гении, которым нельзя давать монотонную работу. Именно такие внедряют реакты, микросервисы и прочие тренды, ибо это модно и интересно. Алгоритмы, большое О и просто понимание как работает все изнутри - скучно и не нужно. Из-за нехватки специалистов и распространённого глупого мнения, что лучше нанимать джунов ибо "мы их вырастим" (в реальности они покидают компанию через год-два), нанимается очень много именно этих снежинок.
auto не поможет, когда надо написать алгоритм числодробилку, в которой миллиарды надо умножать на миллионы (какой тип будет у "auto c = a * b;", если a и b int?). В этом плане Python с его прозрачным bignum намного удобнее. Другой пример - сложные коллекции (например, словарь со составным ключом и другой коллекцией для значений). В любом случае, это просто был совет, и это ваше полное право его игнорировать.
Во многих серьёзных компаниях есть два пути развития: people manager & individual contributor. Где-то начиная с senior developer можно выбирать и вполне можно оставаться программистом (individual contributor). Например technical leader (моя текущая позиция) эквивалентна director (позиция для менеджера). Естественно, есть дополнительные роли и все-равно не будет много времени на программирование, но с другой стороны, можно продолжать заниматься любимой работой, а не разбираться кто кого обидел.
Единственное исключение я знаю Facebook, они там требуют от всех программировать и у них "горизонтальные" отношения. Деталей дальше не знаю, так как не успел написать решения для их задачек (подсказка всем кто почему-то хочет у них работать - не используйте C++ или что-то другое сильно типизированное, потому что они не принимают псевдокод и надо чтобы программа корректно компилировалась и работала. Естественно, никаких IDE, все в онлайн блокноте с компилятором + несколько предустановленных библиотек).
Новоприбывшим сейчас очень тяжело. Жилье и страховки бешеные, конкуренция с индусами, китайцами и нигерийцами, которые может и менее квалифицированны, но могут лучше влится в коллектив (особенно если компания уже состоит из таких же). Я полностью поддерживаю их мнение что надо получать гражданство и валить. Я ещё верил в Канаду лет пять назад, но сейчас я вижу как все деградирует. Ещё помню когда Ванкувер был реально чистый и красивый, но сейчас в этот бомжатник ни ногой. Монреаля это конечно меньше коснулось, и возможно в вашем райском уголке все хорошо, вам можно только позавидовать.
Вам очень повезло и с компанией и с тем что вы находитесь в Онтарио. Я видел увольнения и за день и за месяц, но должен признать, что когда меня хотели уволить, мне дали шанс, но тем у кого квалификация ниже, обычно придумывают повод и увольняют быстро. Но причина практически всегда одна (из того что я видел) - токсичное поведение (читать, несогласие с начальством). Канадцы очень не любят критику, и поэтому я просто принял позицию "канадцы это дети, общайся с ними, как с детьми". И это работает.
Страховка и интернет в Онтарио дешевле, ибо конкуренция и правила страхования лучше. На западе Канады олигополия (хотя конечно это применимо и ко всей Канаде), а например в BC машины страхует только государство, полная монополия. В Альберте повышенная страховка из-за ужасного климата и постоянных аварий. Например я плачу $350, потому что я провел вне Канады 1.5 года и мне сбросили волительский стаж до нуля (!!!), и это ещё минимальное страхование ответственности (1 миллион, хотели всучить "стандартные" два).
Канада - экспортёр дешевой рабочей силы для США и экспортёр ресурсов + обдирает туристов (включая местных) космическими ценами. Например, самая зачуханная гостиница в Банфе стоит спокойно $300 USD в high season. Хорошие гостиницы типа fairmont могут спокойно стоить $1000+ (можете сами проверить цены на рождественные праздники тут через booking). Причём я останавливался в Fairmont Lake Louise (мне была скидка как резиденту Альберты), $600 выкинуты зря - да, вид красивый, только мутный из-за грязного окна, и обшарпанные стены с облупленной краской никак не создают впечатления высокого класса (сравниваю с Европой и Азией). Так что вот такой тут ВВП, а ай-ти тут имеет очень маленький вклад (T013, примерно 5%): https://www150.statcan.gc.ca/t1/tbl1/en/tv.action?pid=3610043402
Не совсем понял, как это wasm перпендикулярен? Байт-код — это подмножество скриптов, какая разница это бинарный формат или строковой. Lua-байткод не подходил, потому что это проприетарный формат, а оригинальный код не совсем соответствовал требованиям. Wasm стандартизирован, и имеет богатый тулчайн, вплоть до того, что мы можем спокойно модифировать сам байткод, не беспокоясь, что это сломается завтра.
Добавил тест и обновил статью. Документации достаточно мало, плюс нет API для взаимодействия, поэтому написал небольшой менеджер памяти для обмена данных (у меня совсем вылетело из головы, что в WASM-е строк и вообще работы с памятью толком нет, и многие решения основаны на том, что все запускается в JS).
В принципе, качество работы вполне удовлетворительное (правда, C++ биндинги подкачали, но это дело наживное). Будем обсуждать с коллегами, но лично я вижу два главных препятствия для того, чтобы wasm3 стал первичным кандидатом для нас:
большой расход памяти (проверил valgrind-ом, утечек нет, просто расход большой);
[не специфично для wasm3] требуется большой рантайм в самом WASM для хорошей функциональности (я попробовал два варианта: 1) no_std дал размер в несколько десятков байт, но весьма скудная функциональность; 2) полноценный Rust добавил сразу большой рантайм, и хотя стало комфортно программировать, WASM-файл занял несколько сотен килобайт ). Я пытался урезать, но толку мало, все-равно достаточно большие файлы без no_std.
Конечно, компилятор Rust не единственный, можно и Emscripten, но он тоже добавляет свой рантайм, а функциональность будет намного хуже чем в Rust. Впрочем, к самому проекту это отношения не имеет, это отдельная история, и можно рассмотреть те же v-lang, nim и т.п. Дополнительно остается, конечно, вопрос производительности, но этим я буду заниматься в рамках других проектов. Еще раз спасибо за ссылку, при всех сомнениях wasm3 все-равно остается хорошим кандидатом для встраивания.
Спасибо за ссылку, действительно интересный проект. Судя по всему, он удовлетворяет нас по всем требованиям, и есть возможность биндинга нативных функций, пусть даже еще не задокументированная (https://github.com/wasm3/wasm3/pull/71). Насчет прода я не особо переживаю, если проект стоящий, то можно найти ресурсы или спонсоров, чтобы его допилили.
Я постараюсь включить его в тесты, и дам вам знать результаты.
К моему удивлению, MicroPython очень тяжело встраивать, пришлось использовать различные трюки, чтобы заставить его работать без написания больших Makefile-ов.
Мы поддерживаем компиляцию в WASM, но внедрение его VM — это совершенная другая история. Мы рассматривали это, но не подошло, в частности из-за того, что не нашли подходящую под наши требования VM. Все, что мы нашли, были реализованы:
как надстройка к node.js -> V8. Слишком тяжелый рантайм, плюс сборка V8 — это отдельное приключение (возможно, Blink собирается проще, но все-равно тяжеловесный);
Object Pascal не является таким переносимым, как Си — например, так просто скомпилировать его в WASM, или для микроконтроллеров (как вышеупомяный stm32) вряд ли получится (даже если решения есть, они не такие распространенные, и могут иметь проблемы).
Можно объединить без разделителей (а ";" в выражениях и так нужна, хотя она и опциональная): function f1() {}function f2() {}
В Scheme/Lisp вообще нет разделителей:
(define a 1)
(define b 1)
Объединяются в одну строку: (define a 1)(define b 1)
Под «чувствителен к новым строкам» я подразумеваю, что если полность удалить переносы строк, код перестанет работать. Замены на пробелы потенциально может работать, но насколько я понимаю, это особенность Lua (признаюсь, про которую я не знал).
DOM — это отдельная история, переносы строк на сам рендеринг HTML не влияют (по-крайней мере, наши тестеры и клиенты из Fortune 500 не жаловались, при всем разнообразии поддерживаемых браузеров включая IE6). Естественно, могут быть нюансы, но кросс-браузерная разработка давно заставила всех использовать только безопасное API с правильными селекторами (или просто использовать библиотеки, где это все учитывается).
Ruby чувствителен к переносам строк, так что его реализации были исключены из списка. Но т.к. я включил Lua и собираюсь включить Python, могу и включить mruby в список, если интересно. Но парсер и компилятор будут включены, т.к. необходимо позволять редактировать скрипты в любое время, при этом не требуя дополнительных инструментов.
Не все встраиваемые ЯП поддерживают байткод. Более того, возможно мы немного по-разному понимаем обфускацию. Для меня это возможность минимизировать и запутать код (вплоть до изменения хода выполнения кода путем вставления и реорганизации вызовов). Байткод не обязательно обфусцированный, хотя конечно, он компактнее исходного кода. luac -l -l -p дает достаточно читабельное представление байткода Lua, хотя, конечно, я верю, что есть специальные обфускаторы. Однако все это весьма специфично для конкретных ЯП и если есть возможность обфусцировать на уровне исходного кода, это предпочтительнее для нас (но, естественно, может быть неудобно для других и им лучше использовать байткод и сторонние утилиты).
Согласен, что неплохо было бы показать использование RAM. К сожалению, для "Hello world" примера числа будут весьма "бестолковые" тоже, т.к. только специфические конструкции или библиотеки могут вызывать большой расход памяти. Однако какие-то числа лучше чем вообще никакие, так что я добавлю это в тесты (https://gitlab.com/nuald-grp/embedded-langs-footprint/-/issues/4)
Под обычный Linux — некоторые ЯП достаточно экзотичны и имеют весьма скудную документацию. Собственно, некоторые я смог завести (чтобы подключить их в виде библиотеки) только изучив их исходный код, так что поддержка кросс-компиляции — это отдельная история, на которую у меня, к сожалению, нет времени.
Область применения — массовые потребительские устройства (включая бюджетные типа телефонов на KaiOS), микроконтроллеры и SoC у нас есть в планах, но далеких. Т.к. на некоторых устройствах (типа той же KaiOS) нет возможности исполнять нативный код, то одна из поддерживаемых target — это WASM, и засовывать туда 5 мегабайт пайтона сверху (которые надо будет пользователю скачать в условиях ограниченного хранилища и дорогого интернета) — это роскошь.
Из моих наблюдений крупных западных компаний в которых я работал (и их софт/сервисы/железо используется повсеместно):
Начальство и непотизм. Это только на словах открытость и инклюзивность. Менеджмент окружён друзьями, и они просто не видят реальности, т.к. друзья не хотят потерять свое положение, если будут рассказывать горькую правду. Плюс многие менеджеры считают себя умнее чернорабочих (именно так они воспринимают программистов), и принимают необоснованные решения.
Квоты социальной справедливости. Если нанимать людей "по повестке", компании получают налоговые вычеты. Более того, потом этих людей практически невозможно уволить, потому что они сразу начнут раздувать шум и даже судится, потому что типа их уволили из-за их расы/ориентации/тд. Этим людям нельзя ни в чем возражать, поэтому их проекты, какие бы не были бредовые, будут поддерживаться. Их код нельзя честно ревьювить, ибо опять-таки будет шум и суды.
Снежинки. В школе их приучают, что они snowflake (т.е. уникальные и неповторимые), поэтому на работе они себя ведут как непризнанные гении, которым нельзя давать монотонную работу. Именно такие внедряют реакты, микросервисы и прочие тренды, ибо это модно и интересно. Алгоритмы, большое О и просто понимание как работает все изнутри - скучно и не нужно. Из-за нехватки специалистов и распространённого глупого мнения, что лучше нанимать джунов ибо "мы их вырастим" (в реальности они покидают компанию через год-два), нанимается очень много именно этих снежинок.
auto не поможет, когда надо написать алгоритм числодробилку, в которой миллиарды надо умножать на миллионы (какой тип будет у "auto c = a * b;", если a и b int?). В этом плане Python с его прозрачным bignum намного удобнее. Другой пример - сложные коллекции (например, словарь со составным ключом и другой коллекцией для значений). В любом случае, это просто был совет, и это ваше полное право его игнорировать.
Во многих серьёзных компаниях есть два пути развития: people manager & individual contributor. Где-то начиная с senior developer можно выбирать и вполне можно оставаться программистом (individual contributor). Например technical leader (моя текущая позиция) эквивалентна director (позиция для менеджера). Естественно, есть дополнительные роли и все-равно не будет много времени на программирование, но с другой стороны, можно продолжать заниматься любимой работой, а не разбираться кто кого обидел.
Единственное исключение я знаю Facebook, они там требуют от всех программировать и у них "горизонтальные" отношения. Деталей дальше не знаю, так как не успел написать решения для их задачек (подсказка всем кто почему-то хочет у них работать - не используйте C++ или что-то другое сильно типизированное, потому что они не принимают псевдокод и надо чтобы программа корректно компилировалась и работала. Естественно, никаких IDE, все в онлайн блокноте с компилятором + несколько предустановленных библиотек).
Новоприбывшим сейчас очень тяжело. Жилье и страховки бешеные, конкуренция с индусами, китайцами и нигерийцами, которые может и менее квалифицированны, но могут лучше влится в коллектив (особенно если компания уже состоит из таких же). Я полностью поддерживаю их мнение что надо получать гражданство и валить. Я ещё верил в Канаду лет пять назад, но сейчас я вижу как все деградирует. Ещё помню когда Ванкувер был реально чистый и красивый, но сейчас в этот бомжатник ни ногой. Монреаля это конечно меньше коснулось, и возможно в вашем райском уголке все хорошо, вам можно только позавидовать.
Вам очень повезло и с компанией и с тем что вы находитесь в Онтарио. Я видел увольнения и за день и за месяц, но должен признать, что когда меня хотели уволить, мне дали шанс, но тем у кого квалификация ниже, обычно придумывают повод и увольняют быстро. Но причина практически всегда одна (из того что я видел) - токсичное поведение (читать, несогласие с начальством). Канадцы очень не любят критику, и поэтому я просто принял позицию "канадцы это дети, общайся с ними, как с детьми". И это работает.
Страховка и интернет в Онтарио дешевле, ибо конкуренция и правила страхования лучше. На западе Канады олигополия (хотя конечно это применимо и ко всей Канаде), а например в BC машины страхует только государство, полная монополия. В Альберте повышенная страховка из-за ужасного климата и постоянных аварий. Например я плачу $350, потому что я провел вне Канады 1.5 года и мне сбросили волительский стаж до нуля (!!!), и это ещё минимальное страхование ответственности (1 миллион, хотели всучить "стандартные" два).
Канада - экспортёр дешевой рабочей силы для США и экспортёр ресурсов + обдирает туристов (включая местных) космическими ценами. Например, самая зачуханная гостиница в Банфе стоит спокойно $300 USD в high season. Хорошие гостиницы типа fairmont могут спокойно стоить $1000+ (можете сами проверить цены на рождественные праздники тут через booking). Причём я останавливался в Fairmont Lake Louise (мне была скидка как резиденту Альберты), $600 выкинуты зря - да, вид красивый, только мутный из-за грязного окна, и обшарпанные стены с облупленной краской никак не создают впечатления высокого класса (сравниваю с Европой и Азией). Так что вот такой тут ВВП, а ай-ти тут имеет очень маленький вклад (T013, примерно 5%): https://www150.statcan.gc.ca/t1/tbl1/en/tv.action?pid=3610043402
Не совсем понял, как это wasm перпендикулярен? Байт-код — это подмножество скриптов, какая разница это бинарный формат или строковой. Lua-байткод не подходил, потому что это проприетарный формат, а оригинальный код не совсем соответствовал требованиям. Wasm стандартизирован, и имеет богатый тулчайн, вплоть до того, что мы можем спокойно модифировать сам байткод, не беспокоясь, что это сломается завтра.
Добавил тест и обновил статью. Документации достаточно мало, плюс нет API для взаимодействия, поэтому написал небольшой менеджер памяти для обмена данных (у меня совсем вылетело из головы, что в WASM-е строк и вообще работы с памятью толком нет, и многие решения основаны на том, что все запускается в JS).
В принципе, качество работы вполне удовлетворительное (правда, C++ биндинги подкачали, но это дело наживное). Будем обсуждать с коллегами, но лично я вижу два главных препятствия для того, чтобы wasm3 стал первичным кандидатом для нас:
Конечно, компилятор Rust не единственный, можно и Emscripten, но он тоже добавляет свой рантайм, а функциональность будет намного хуже чем в Rust. Впрочем, к самому проекту это отношения не имеет, это отдельная история, и можно рассмотреть те же v-lang, nim и т.п. Дополнительно остается, конечно, вопрос производительности, но этим я буду заниматься в рамках других проектов. Еще раз спасибо за ссылку, при всех сомнениях wasm3 все-равно остается хорошим кандидатом для встраивания.
Спасибо за ссылку, действительно интересный проект. Судя по всему, он удовлетворяет нас по всем требованиям, и есть возможность биндинга нативных функций, пусть даже еще не задокументированная (https://github.com/wasm3/wasm3/pull/71). Насчет прода я не особо переживаю, если проект стоящий, то можно найти ресурсы или спонсоров, чтобы его допилили.
Я постараюсь включить его в тесты, и дам вам знать результаты.
Добавил Python (с примером использования Cython: https://gitlab.com/nuald-grp/embedded-langs-footprint#user-content-using-cython ) и MicroPython. Как я и предполагал, Python достаточно тяжелый (и тестовая программа даже не включала всю стандартную библиотеку, а только базовый необходимый набор).
К моему удивлению, MicroPython очень тяжело встраивать, пришлось использовать различные трюки, чтобы заставить его работать без написания больших Makefile-ов.
Мы поддерживаем компиляцию в WASM, но внедрение его VM — это совершенная другая история. Мы рассматривали это, но не подошло, в частности из-за того, что не нашли подходящую под наши требования VM. Все, что мы нашли, были реализованы:
К сожалению, мы не нашли реализацию на чистом C/C++, но если вы знаете какую-либо, дайте знать пожалуйста.
tcc уже несколько лет как фактически заморожен, т.к. его автор больше над ним не работает (https://bellard.org/tcc/):
Плюс он компилирует в машинный код, что нам не особо подходит (например, не будет работать в WASM VM).
GPL-лицензия, не подходит для коммерческого использования.
Object Pascal не является таким переносимым, как Си — например, так просто скомпилировать его в WASM, или для микроконтроллеров (как вышеупомяный stm32) вряд ли получится (даже если решения есть, они не такие распространенные, и могут иметь проблемы).
Думаю, лучше привести примеры кода (JS):
Можно объединить без разделителей (а ";" в выражениях и так нужна, хотя она и опциональная):
function f1() {}function f2() {}В Scheme/Lisp вообще нет разделителей:
Объединяются в одну строку:
(define a 1)(define b 1)Так что все зависит от ЯП.
Под «чувствителен к новым строкам» я подразумеваю, что если полность удалить переносы строк, код перестанет работать. Замены на пробелы потенциально может работать, но насколько я понимаю, это особенность Lua (признаюсь, про которую я не знал).
DOM — это отдельная история, переносы строк на сам рендеринг HTML не влияют (по-крайней мере, наши тестеры и клиенты из Fortune 500 не жаловались, при всем разнообразии поддерживаемых браузеров включая IE6). Естественно, могут быть нюансы, но кросс-браузерная разработка давно заставила всех использовать только безопасное API с правильными селекторами (или просто использовать библиотеки, где это все учитывается).
Ruby чувствителен к переносам строк, так что его реализации были исключены из списка. Но т.к. я включил Lua и собираюсь включить Python, могу и включить mruby в список, если интересно. Но парсер и компилятор будут включены, т.к. необходимо позволять редактировать скрипты в любое время, при этом не требуя дополнительных инструментов.
Не все встраиваемые ЯП поддерживают байткод. Более того, возможно мы немного по-разному понимаем обфускацию. Для меня это возможность минимизировать и запутать код (вплоть до изменения хода выполнения кода путем вставления и реорганизации вызовов). Байткод не обязательно обфусцированный, хотя конечно, он компактнее исходного кода.
luac -l -l -pдает достаточно читабельное представление байткода Lua, хотя, конечно, я верю, что есть специальные обфускаторы. Однако все это весьма специфично для конкретных ЯП и если есть возможность обфусцировать на уровне исходного кода, это предпочтительнее для нас (но, естественно, может быть неудобно для других и им лучше использовать байткод и сторонние утилиты).Согласен, что неплохо было бы показать использование RAM. К сожалению, для "Hello world" примера числа будут весьма "бестолковые" тоже, т.к. только специфические конструкции или библиотеки могут вызывать большой расход памяти. Однако какие-то числа лучше чем вообще никакие, так что я добавлю это в тесты (https://gitlab.com/nuald-grp/embedded-langs-footprint/-/issues/4)
Под обычный Linux — некоторые ЯП достаточно экзотичны и имеют весьма скудную документацию. Собственно, некоторые я смог завести (чтобы подключить их в виде библиотеки) только изучив их исходный код, так что поддержка кросс-компиляции — это отдельная история, на которую у меня, к сожалению, нет времени.
Область применения — массовые потребительские устройства (включая бюджетные типа телефонов на KaiOS), микроконтроллеры и SoC у нас есть в планах, но далеких. Т.к. на некоторых устройствах (типа той же KaiOS) нет возможности исполнять нативный код, то одна из поддерживаемых target — это WASM, и засовывать туда 5 мегабайт пайтона сверху (которые надо будет пользователю скачать в условиях ограниченного хранилища и дорогого интернета) — это роскошь.