Не вижу, почему компиляторы, оптимизирующие выполнение для пути без исключений, не могут точно так же оптимизировать его для кода возврата S_OK.
Потому что компилятор вообще никак не оптимизирует "выполнене пути без исключений". Компилятор (грубо говоря, на самом деле это не совсем так, но это нюансы работы оптимизаторов) генерирует код для try и всего, что внутри, как будто этого try нет. Он просто для всех try пишет в сегмент данных дополнительную метаинформацию: интервалы адресов в коде и сопоставленный им адрес, куда делается переход для обработки исключения. Потом при выбросе исключений подключается рантайм, который ходит по стеку, находит адреса возвратов в нём (для этого так же может потребоваться дополнительная разметка call site-ов, но это опять же, данные) и дальше смотрит, есть ли в таблице try информация об этих адресах. Если он таковую находит, то делает (грубо говоря) простой jump в адрес обработчика.
С исключениями проблемы начинаются, когда на них начинают писать логику (не аварийная ситуация, а ситуации типа вместо проверки существования файла – обращаемся к нему и бросаем exception, если его нет).
it depends. Если путь к файлу задан юзером, то очевидным решением будет явная проверка наличия этого файла. Если же это какой-то ресурс приложения, или какой-то файл (например, кэш), который ранее создало само приложение где-нибудь в $HOME/.cache и по идее никто не должен был его удалять (если только это зачем-то не сделал юзер, ну или не поломалась ФС), то вполне валидно бросить исключение. Ну и обработать ошибку уже несколькими уровнями выше.
Конечно, решаемо. Мы как раз и собирали весь этот ад Maven, пока пару лет назад не смигрировали на Gradle. И это был глоток свежего воздуха. Там где раньше были обильно расставлены костыли и нагорожена куча бойлерплейта, сейчас короткие и ясные декларативные описания. Там, где приходилось сражаться с ограничениями инструмента, сейчас просто берёшь и используешь его.
Кстати, для генерации исходников у мавена таки из коробки имеется отдельная фаза.
Да-да, как и плагин. Но тут, конечно, не совсем в тему мой коммент. Просто если проект держат на Maven, то собственно Maven его достаточно редко собирают, ибо каждый раз ждать 5 минут просто чтобы запустить и проверить изменения - это невиданная расточительность. Так вот, мы всегда полагались на то, что IDEA как-то спарсит pom.xml и как-то свой проект сконфигурирует, а потом собирать идеей, т.к. она умеет в инкремениальную сборку, и там, где Maven работал несколько минут, IDEA умудрялась за пару секунд пересобирать. Ну и, конечно, туда не входил protobuf. Поэтому когда кто-то накоммитил изменений в proto-файлы, приходилось брать вручную запускать какие-то goal-ы каких-то проектов. Ну и т.к. это было не одно место, была целая россыпь run configuration на все случаи жизни - что запустить, если при очередном pull проект сломался. Это уж не говоря о том, что при переключении между feature branch и master приходилось всё то же самое проделывать. C gradle в принципе иначе поступают - там собирают всегда им, а не делегируют IDE, и он сам хорошо умеет в инкрементальную компиляцию и способен проект собрать за 2 секунды. Так что как только мы переехали на gradle, необходимость в каких-либо манипуляцих отпала - можно просто запустить проект оттуда, где вы сейчас находитесь, и он гарантированно запустится.
Кстати, ещё забыл. Проект частично на Kotlin, частично на Java, причём есть модули, где есть код и на Kotlin и на Java. Я помню, нужно было отдельно настраивать оба компилятора так, чтобы они правильно совместно работали, т.е. писать кучу бойлерплейта. С Gradle всё не так - нужно всего лишь подключить плагин Java и плагин Kotlin и оно всё само.
Ну а что поделать, если на практике реально возникла ситуация, когда стандартных фаз не хватает? Вот возник кейс, о котором создатели Maven просто не подумали. Приходится шаманить с порядком применения mojo внутри одной фазы, чтобы всё сошлось. И "почесать своё эго" вообще не при чём. По моему опыту, если делаешь типовой Java проект со Spring/Hibernate/что-то такое, собираешь это в war, то Maven отлично работает. А если проект: собрать из (почти) одних сорцов десктопное приложение в виде fat jar, Android-приложение, iOS приложение с помощью Graal Native Image и веб-приложение с помощью какого-нибудь транслятора Java->JS/WebAssembly, да ещё сервер рядом с ними положить в докер-образ вместе с нативными либами, то использование Maven превращается в АД. Кстати, да, часть исходников при этом генерится с помощью какого-нибудь ANTLR, а другая часть - Protobuf.
И, кстати, у организации тасок в граф есть ещё пара преимуществ. Во-первых, так проще сделать инкрементальную сборку. Тогда просто таски не зависят друг от друга напрямую, а output одной таски направляется в input другой. Во-вторых, граф тасок проще распараллелить.
Нет. Разница между Maven и Gradle не в императивности. Кто юзал gradle правильно, и так не писал императивных штук в скриптах, а переносил их в плагины. Разница в том, что плагин в Maven - это по сути одна таска, а в Gradle плагин способен конфигурировать проект целиком - например, подсовывать зависимости, таски, модифицировать имеющиеся и т.д. Это очень полезно, когда в проекте есть модули, имеющие некоторый общий функционал. Например, у нас в проекте мы предоставляем пользователям писать скрипты для нашего приложения на TypeScript, при этом есть некоторые модули, которые экспортируют части этого скриптового API. Для них нужны определённые действия, плюс определённые зависимости. Причём, действия - это не просто одна таска. Например, хочется запускать валидатор сгенерированных d.ts файлов, для чего нужен node.js плагин. Почему не написать свой mojo, который бы запускал node.js? Ну потому что такой плагин уже есть и не хочется его велосипедить. До переезда на Gradle мы просто тащили из модуля в модуль определённый бойлерплейт (который ещё изредка менялся и приходилось его апдейтить в каждом модуле, где он есть). В Gradle это выглядит как-то так:
plugins { id "tsApiProvider" }
Кроме того, в Gradle в принципе очень многие вещи сделаны грамотнее:
вместо прибитого гвоздям набора фаз есть граф тасок
концепция конфигураций намного гибче скоупов в maven; идущие из коробки с java плагином конфигурации лучше отражают реалии многомодульных проектов (api/implementation)
продумана инкрементальность на уровне тасок, можно чётко определять для каждой таски, откуда она получает данные на вход, куда пишет вывод.
gradle любят ругать за отсутствие документации. Так вот, для Maven она в тысячи раз хуже. Есть только базовая инструкция, как написать плагин (mojo), но как сделать продвинутые вещи (например, динамически порезолвить зависимость) можно узнать, только залезая в код каких-нибудь плагинов, которые делают более-менее то же самое.
Нет. Разбивка текста на лексему или разбор на AST - это даже не вершина айсберга компиляции, это подтаявший лёд на этой самой вершине.
IDE не будет долго "индексировать" проект, подсветка синтаксиса и большая часть информации для автокомплита будут доступны сразу.
Нет. См. пункт 1.
Не будет споров а-ля "табы vs пробелы", в файл попадет лишь дерево.
А так же исчезнет куча полезного форматирования, применимого в конкретном случае, которое позволяет сделать код более понимаемым.
Если совсем упороться, то, наверно, можно даже настроить IDE так, чтобы писать на другом языке. Например, код был на Java, а ты себе показываешь его на котлине. Просто где-то в IDE пометить, чтобы в файл сохранялось джавовое AST. Здесь я не уверен, просто как мысль, что можно ещё сделать, если отказаться от оков текста.
Языки отличаются друг от друга гораздо больше, чем просто "набором символов, входящих в лексему". И даже больше, чем типами узлов в AST. Задача перевести программу с одного языка на другой практически невыполнима в общем случае.
IDE может хранить в этих бинарях свои данные для ускорения каких-то процессов отображения и автокомплита. Правда, файлы могут сильно разрастись.
Как раз 5, 6 идея только с виду та же. В старых цивах можно было жульничать. Помню, как в третьей можно было настроить танчиков, по железным дорогам в один ход подтянуть к городам противника и следующим же ходом вынести. В 4 добавили такую штуку что при объявлении войны танчики за границу противника отправлялись и надо было снова их к городам подтягивать. В 5 сделали гексагональную карту, так что направления стали более равноправными (потому что в случае квадратных клеток перемещение по диагонали примерно в 1.41 раз быстрее) и сделали невозможность ставить два юнита на клетку. И это чуть ли не революция, потому что не даёт жульничать, местность начинает интереснее влиять на стратегию. Ещё в 5-й наконец подтянули различные формы правления, так что иногда за маленкую демократическую страну оказывалось играть выгоднее, чем за огромную авторитарную. Жаль, в 6-й этот баланс немного потеряли - стало снова выгодно тупо отстраивать побольше городов, без того, чтобы тщательно продумывать их стратегию развития (несмотря на введённые районы, которые должны только были стратегии развития городов только способствовать). Короче, после 3-й цивилизации каждая игра могла предложить что-то новое и заставляла полностью пересмотреть подходы к стратегии игры.
Вы мне сейчас приписываете какие-то утверждения, которых я не делал. Я не говорю, что верю в "подобные исследования". Я только заметил, что не всегда можно верить своим глазам и здравому смыслу. Что не исключает вероятности кривости тех или иных исследования. Как раз в постулатах квантовой механики (не понимаю, при чём тут кварки, я про них не говорил) я не сомневаюсь, ибо я вначале 10 лет учился в школе, а потом ещё 5 - на физмате, и за это время успел усвоить научную картину мира, к которой человечество шло долгие века, методом проб и ошибок, положив на это кучу ресурсов. Это при том, что с точки зрения органов чувств и "житейской" логики вся квантовая механика - это дичайшая муть.
Автор же комментария, на который я ответил, ведёт себя как такой невежда, который на физмате не учился, услышал о волновой функции и кинулся критиковать, потому что это не соответствует показаниям его органов чувств.
Что касается лично моего опыта (на основании которого, конечно, нельзя делать общих выводов, претендующих на научность) я вижу, что дама написала статью и словила кучу сексистских комментариев. Я при этом ничего не утверждаю о качестве её статьи, о достоверности содержимого - недостаточно компетентен в вопросе, чтобы судить. Я говорю именно о реакции комментаторов.
не уйдет на три года в отпуск по уходу за ребенком
Во-первых, уйти в отпуск по уходу за ребёнком может и папа. Во-вторых, как раз в IT я очень часто наблюдаю, что женщины с маленьким ребёнком работают - деньги лишними не бывают (особенно для семьи с ребёнком), а сидеть дома скучно, так что многие уже через 3-6 месяцев просятся хотя бы на полставки на удалёнку, и, надо сказать, хорошо справляются с работой.
Зависит от. Некоторые мужчины так же достаточно остро реагируют на ревью. Ну и потом, не факт, что такая реакция не имеет иных причину - например, девушка, окружённая суровыми мужиками (некоторые из которых, возможно, действительно делают сексистские выпадки), испытывает определённые проблемы с самооценкой и потому нервничает.
Считаю, что к женщинам давно уже относятся абсолютно одинаково и согласно с их реальными знаниями и умениями.
Не соглашусь. Мы с вами находимся в некотором информационном пузыре, где это, возможно, действительно так, но вовсем не факт, что так в обществе везде. Хотя бывает, что мы настолько привыкли к некоторой предвзятости по отношению к женщинам, что даже не замечаем некоторой гендерной предвзятости, считая себя образцом толератности.
С другой стороны, я совсем не думаю, что все эти инициативы со стороны компаний и посты в интернете действительно как-то помогут. Скорее, наоборот, вызовут только негативную реакцию. Вот как быть - не могу подсказать, ибо сам не знаю. Возможно, рыночек порешает - сейчас много где в мире назревает нехватка рабочей силы, и мигрантами затыкать вечно не получится (потому что страны, откуда мигрируют, либо в процессе, либо совсем скоро начнут демографический переход).
Я с одной стороны не согласен с тезисом "мужской и женский мозг ничем не отличаются". С другой, да, они отличаются. Но, ИМХО, как раз успех в той или иной деятельности зависит от такого чудовищного количества факторов, что лишь один из них (а именно те или иные гормоны) непонятно как вписывается в общую картину. И самое главное - а где научные исследования про совместимость того или иного гормонального фона с работой программистом?
Да! (ваш уровень аргументации мне нравится, что ж буду пользоваться тем же приемом)
А тут и аргументировать нечего. Нет возможности научно доказать пригодность того или иного языка для решения тех или иных задач. Я думаю, бОльшая часть программистского сообщества согласится, что Rust - это более низкоуровневая штука, на которой какие-нибудь компиляторы можно писать. А вот писать то, для чего обычно используют JS, т.е. веб-морды для всяческих онлайн-сервисов, на Rust намного сложнее. Но фанатам Rust, конечно, так не кажется, и нет никаких надёжных способов их в этом убедить.
Примеров конечно же не будет приведено в качестве аргумента?
Java: на сервере и в Android из коробки; Graal Native Image - легковесные утилиты, быстро стартующие сервисы, iOS-приложения; Google Closure Compiler, TeaVM - компиляция в JS и в WebAssembly (кстати, значительной разницы в перфомансе между JS и WASM таргетами не наблюдается)
Kotlin: из коробки на сервере, Android, iOS, JS и WebAssembly (опять же, в веб Kotlin прекрасно работал через Kotlin/JS, ещё задолго до появления WASM)
Python - из коробки на сервере; Brython - рантайм для браузера (опять же, через JS).
при том, что если вы сможете запустить модель из браузера и получить ту же производительность, что и если вы запустите из питона используя cuda
CUDA работает на видеокарте. На CPU есть ли какой-то смысл запускать AI-модели (ну кроме чисто учебных)? Во сколько раз просядет производительность? Точнее, на сколько порядков? WebAssembly как-то умеет работать на GPU?
Писать логику на расте для браузера вместо джава скрипта это как благословение с небес
Эээ, нет.
Переиспользовать можно 95% одного и того же кода на всех платформах сразу: браузер, мобила, сервер - это просто супер преимущество, тут конечно больше спасибо расту, но тем не менее.
Это совсем не уникальное преимущество WASM или Rust.
Не сегодня-завтра всем понадобится запускать ИИ модели у себя в браузере или на мобиле и производительность там играет решающее значение, wasm и тут должен стать незаменим.
Эээ, я думал, ИИ-модели запускают на CUDA, при чём тут WebAssembly? Может, в данном случае лучше предусмотреть CUDA API или хотя бы OpenCL API для браузера?
Вот всегда в таких статьях "как мы покоряем просторы вселенной" говорится о больших фичах, но всегда не обращается внимание на то, что "есть нюанс". Например, GC они выпустили, ага. Только там почему-то дереференс nullptr приводит к trap-у, а не к исключению, что полностью противоречит поведению в подавляющем числе мейнстримных языков с управляемой кучей (JS, Java, C#, Python); аналогично с делением на ноль или с neg для -0x100000000. Или вот GC не поддерживается ни в одном известном мне безбраузерном движке. Или что до сих пор не выпустили никакого стандарта debug информации, а поддержка DWARF (где она есть) сырая просто до неюзабельности и вообще не вполне стандартизирована (я как автор компилятора в WASM лично сталкивался с тем, что wasmtime и chrome понимают DWARF по-разному). Ну и что DWARF идеологически никак не ложится на языки с GC. Или что ничего близко к "нативной производительности" в WebAssembly и не пахнет, что его "куча" спроектирована так, что любое обращение к памяти неминуемо обкладывается проверками на рантайме, и как авторы этих рантаймов героически пишут оптимизации, призванные количество этих проверок хоть как-то снизить.
Зато, о чудо, реализовали хвостовую рекурсию, всё многочисленное сообщество программистов на OCaml будет довольно этой новости.
B2 хватает, это факт. Другое дело - это скорость и нагрузка. По-русски я пишу быстрее и лучше, при этом прикладывая меньше усилий. И да, я "-тся" и "-ться" не путаю, "не" знаю когда писать раздельно или слитно, но вот те же артикли так и не осилил во всех нюансах.
В догонку вспомнился один случай - как-то про мой проект кто-то упомянул в комментариях к посту в hacker news. И несколько пользователей сразу пожаловались - а по документации проекта не понятно, как вообще начать его использовать. При том, что документация getting started была - как с помощью строчки в CLI создать пустой проект hello world. Естественно, в шаблоне я добавил комментариев, чтобы человек мог создать проект, посмотреть код и увидеть тут же объяснение. Но видимо, они не осилили скопировать текст в консоль, или просто не знали, что в IDEA есть поддержка архетипов в UI - и сразу сделали вывод.
Ещё момент: многие разработчики open source проектов попросту не являются native english speaker и писать документацию с условным B2 (а именно на нём часто люди застревают в плато, с которого в C1 непонятно как попасть, не посвящая вообще всё свободное время планомерному изучению - где же тогда взять время на кодинг) довольно-таки сложно и медленно. И, наконец, разработчику не всегда очевидно, что может вызвать затруднения у других.
Потому что компилятор вообще никак не оптимизирует "выполнене пути без исключений". Компилятор (грубо говоря, на самом деле это не совсем так, но это нюансы работы оптимизаторов) генерирует код для try и всего, что внутри, как будто этого try нет. Он просто для всех try пишет в сегмент данных дополнительную метаинформацию: интервалы адресов в коде и сопоставленный им адрес, куда делается переход для обработки исключения. Потом при выбросе исключений подключается рантайм, который ходит по стеку, находит адреса возвратов в нём (для этого так же может потребоваться дополнительная разметка call site-ов, но это опять же, данные) и дальше смотрит, есть ли в таблице try информация об этих адресах. Если он таковую находит, то делает (грубо говоря) простой jump в адрес обработчика.
it depends. Если путь к файлу задан юзером, то очевидным решением будет явная проверка наличия этого файла. Если же это какой-то ресурс приложения, или какой-то файл (например, кэш), который ранее создало само приложение где-нибудь в
$HOME/.cacheи по идее никто не должен был его удалять (если только это зачем-то не сделал юзер, ну или не поломалась ФС), то вполне валидно бросить исключение. Ну и обработать ошибку уже несколькими уровнями выше.Конечно, решаемо. Мы как раз и собирали весь этот ад Maven, пока пару лет назад не смигрировали на Gradle. И это был глоток свежего воздуха. Там где раньше были обильно расставлены костыли и нагорожена куча бойлерплейта, сейчас короткие и ясные декларативные описания. Там, где приходилось сражаться с ограничениями инструмента, сейчас просто берёшь и используешь его.
Да-да, как и плагин. Но тут, конечно, не совсем в тему мой коммент. Просто если проект держат на Maven, то собственно Maven его достаточно редко собирают, ибо каждый раз ждать 5 минут просто чтобы запустить и проверить изменения - это невиданная расточительность. Так вот, мы всегда полагались на то, что IDEA как-то спарсит pom.xml и как-то свой проект сконфигурирует, а потом собирать идеей, т.к. она умеет в инкремениальную сборку, и там, где Maven работал несколько минут, IDEA умудрялась за пару секунд пересобирать. Ну и, конечно, туда не входил protobuf. Поэтому когда кто-то накоммитил изменений в proto-файлы, приходилось брать вручную запускать какие-то goal-ы каких-то проектов. Ну и т.к. это было не одно место, была целая россыпь run configuration на все случаи жизни - что запустить, если при очередном pull проект сломался. Это уж не говоря о том, что при переключении между feature branch и master приходилось всё то же самое проделывать. C gradle в принципе иначе поступают - там собирают всегда им, а не делегируют IDE, и он сам хорошо умеет в инкрементальную компиляцию и способен проект собрать за 2 секунды. Так что как только мы переехали на gradle, необходимость в каких-либо манипуляцих отпала - можно просто запустить проект оттуда, где вы сейчас находитесь, и он гарантированно запустится.
Кстати, ещё забыл. Проект частично на Kotlin, частично на Java, причём есть модули, где есть код и на Kotlin и на Java. Я помню, нужно было отдельно настраивать оба компилятора так, чтобы они правильно совместно работали, т.е. писать кучу бойлерплейта. С Gradle всё не так - нужно всего лишь подключить плагин Java и плагин Kotlin и оно всё само.
Ну а что поделать, если на практике реально возникла ситуация, когда стандартных фаз не хватает? Вот возник кейс, о котором создатели Maven просто не подумали. Приходится шаманить с порядком применения mojo внутри одной фазы, чтобы всё сошлось. И "почесать своё эго" вообще не при чём. По моему опыту, если делаешь типовой Java проект со Spring/Hibernate/что-то такое, собираешь это в war, то Maven отлично работает. А если проект: собрать из (почти) одних сорцов десктопное приложение в виде fat jar, Android-приложение, iOS приложение с помощью Graal Native Image и веб-приложение с помощью какого-нибудь транслятора Java->JS/WebAssembly, да ещё сервер рядом с ними положить в докер-образ вместе с нативными либами, то использование Maven превращается в АД. Кстати, да, часть исходников при этом генерится с помощью какого-нибудь ANTLR, а другая часть - Protobuf.
И, кстати, у организации тасок в граф есть ещё пара преимуществ. Во-первых, так проще сделать инкрементальную сборку. Тогда просто таски не зависят друг от друга напрямую, а output одной таски направляется в input другой. Во-вторых, граф тасок проще распараллелить.
Нет. Разница между Maven и Gradle не в императивности. Кто юзал gradle правильно, и так не писал императивных штук в скриптах, а переносил их в плагины. Разница в том, что плагин в Maven - это по сути одна таска, а в Gradle плагин способен конфигурировать проект целиком - например, подсовывать зависимости, таски, модифицировать имеющиеся и т.д. Это очень полезно, когда в проекте есть модули, имеющие некоторый общий функционал. Например, у нас в проекте мы предоставляем пользователям писать скрипты для нашего приложения на TypeScript, при этом есть некоторые модули, которые экспортируют части этого скриптового API. Для них нужны определённые действия, плюс определённые зависимости. Причём, действия - это не просто одна таска. Например, хочется запускать валидатор сгенерированных
d.tsфайлов, для чего нужен node.js плагин. Почему не написать свой mojo, который бы запускал node.js? Ну потому что такой плагин уже есть и не хочется его велосипедить. До переезда на Gradle мы просто тащили из модуля в модуль определённый бойлерплейт (который ещё изредка менялся и приходилось его апдейтить в каждом модуле, где он есть). В Gradle это выглядит как-то так:plugins {id "tsApiProvider"
}
Кроме того, в Gradle в принципе очень многие вещи сделаны грамотнее:
вместо прибитого гвоздям набора фаз есть граф тасок
концепция конфигураций намного гибче скоупов в maven; идущие из коробки с java плагином конфигурации лучше отражают реалии многомодульных проектов (api/implementation)
продумана инкрементальность на уровне тасок, можно чётко определять для каждой таски, откуда она получает данные на вход, куда пишет вывод.
gradle любят ругать за отсутствие документации. Так вот, для Maven она в тысячи раз хуже. Есть только базовая инструкция, как написать плагин (mojo), но как сделать продвинутые вещи (например, динамически порезолвить зависимость) можно узнать, только залезая в код каких-нибудь плагинов, которые делают более-менее то же самое.
Нет. Разбивка текста на лексему или разбор на AST - это даже не вершина айсберга компиляции, это подтаявший лёд на этой самой вершине.
Нет. См. пункт 1.
А так же исчезнет куча полезного форматирования, применимого в конкретном случае, которое позволяет сделать код более понимаемым.
Языки отличаются друг от друга гораздо больше, чем просто "набором символов, входящих в лексему". И даже больше, чем типами узлов в AST. Задача перевести программу с одного языка на другой практически невыполнима в общем случае.
А зачем? IDE и так хранит эти данные в индексах.
Как раз 5, 6 идея только с виду та же. В старых цивах можно было жульничать. Помню, как в третьей можно было настроить танчиков, по железным дорогам в один ход подтянуть к городам противника и следующим же ходом вынести. В 4 добавили такую штуку что при объявлении войны танчики за границу противника отправлялись и надо было снова их к городам подтягивать. В 5 сделали гексагональную карту, так что направления стали более равноправными (потому что в случае квадратных клеток перемещение по диагонали примерно в 1.41 раз быстрее) и сделали невозможность ставить два юнита на клетку. И это чуть ли не революция, потому что не даёт жульничать, местность начинает интереснее влиять на стратегию. Ещё в 5-й наконец подтянули различные формы правления, так что иногда за маленкую демократическую страну оказывалось играть выгоднее, чем за огромную авторитарную. Жаль, в 6-й этот баланс немного потеряли - стало снова выгодно тупо отстраивать побольше городов, без того, чтобы тщательно продумывать их стратегию развития (несмотря на введённые районы, которые должны только были стратегии развития городов только способствовать). Короче, после 3-й цивилизации каждая игра могла предложить что-то новое и заставляла полностью пересмотреть подходы к стратегии игры.
А как же
IntStream?Вы мне сейчас приписываете какие-то утверждения, которых я не делал. Я не говорю, что верю в "подобные исследования". Я только заметил, что не всегда можно верить своим глазам и здравому смыслу. Что не исключает вероятности кривости тех или иных исследования. Как раз в постулатах квантовой механики (не понимаю, при чём тут кварки, я про них не говорил) я не сомневаюсь, ибо я вначале 10 лет учился в школе, а потом ещё 5 - на физмате, и за это время успел усвоить научную картину мира, к которой человечество шло долгие века, методом проб и ошибок, положив на это кучу ресурсов. Это при том, что с точки зрения органов чувств и "житейской" логики вся квантовая механика - это дичайшая муть.
Автор же комментария, на который я ответил, ведёт себя как такой невежда, который на физмате не учился, услышал о волновой функции и кинулся критиковать, потому что это не соответствует показаниям его органов чувств.
Что касается лично моего опыта (на основании которого, конечно, нельзя делать общих выводов, претендующих на научность) я вижу, что дама написала статью и словила кучу сексистских комментариев. Я при этом ничего не утверждаю о качестве её статьи, о достоверности содержимого - недостаточно компетентен в вопросе, чтобы судить. Я говорю именно о реакции комментаторов.
Во-первых, уйти в отпуск по уходу за ребёнком может и папа. Во-вторых, как раз в IT я очень часто наблюдаю, что женщины с маленьким ребёнком работают - деньги лишними не бывают (особенно для семьи с ребёнком), а сидеть дома скучно, так что многие уже через 3-6 месяцев просятся хотя бы на полставки на удалёнку, и, надо сказать, хорошо справляются с работой.
Зависит от. Некоторые мужчины так же достаточно остро реагируют на ревью. Ну и потом, не факт, что такая реакция не имеет иных причину - например, девушка, окружённая суровыми мужиками (некоторые из которых, возможно, действительно делают сексистские выпадки), испытывает определённые проблемы с самооценкой и потому нервничает.
Согласно моим глазам, ушам, памяти и здравому смыслу нет ничего абсурднее квантовой механики.
Не соглашусь. Мы с вами находимся в некотором информационном пузыре, где это, возможно, действительно так, но вовсем не факт, что так в обществе везде. Хотя бывает, что мы настолько привыкли к некоторой предвзятости по отношению к женщинам, что даже не замечаем некоторой гендерной предвзятости, считая себя образцом толератности.
С другой стороны, я совсем не думаю, что все эти инициативы со стороны компаний и посты в интернете действительно как-то помогут. Скорее, наоборот, вызовут только негативную реакцию. Вот как быть - не могу подсказать, ибо сам не знаю. Возможно, рыночек порешает - сейчас много где в мире назревает нехватка рабочей силы, и мигрантами затыкать вечно не получится (потому что страны, откуда мигрируют, либо в процессе, либо совсем скоро начнут демографический переход).
Я с одной стороны не согласен с тезисом "мужской и женский мозг ничем не отличаются". С другой, да, они отличаются. Но, ИМХО, как раз успех в той или иной деятельности зависит от такого чудовищного количества факторов, что лишь один из них (а именно те или иные гормоны) непонятно как вписывается в общую картину. И самое главное - а где научные исследования про совместимость того или иного гормонального фона с работой программистом?
А никто не говорит про объединение. Старые добрые потоки в пуле
А вы пробовали вместо потока на каждый файл банально запускать задачи в thread pool?
А тут и аргументировать нечего. Нет возможности научно доказать пригодность того или иного языка для решения тех или иных задач. Я думаю, бОльшая часть программистского сообщества согласится, что Rust - это более низкоуровневая штука, на которой какие-нибудь компиляторы можно писать. А вот писать то, для чего обычно используют JS, т.е. веб-морды для всяческих онлайн-сервисов, на Rust намного сложнее. Но фанатам Rust, конечно, так не кажется, и нет никаких надёжных способов их в этом убедить.
Java: на сервере и в Android из коробки; Graal Native Image - легковесные утилиты, быстро стартующие сервисы, iOS-приложения; Google Closure Compiler, TeaVM - компиляция в JS и в WebAssembly (кстати, значительной разницы в перфомансе между JS и WASM таргетами не наблюдается)
Kotlin: из коробки на сервере, Android, iOS, JS и WebAssembly (опять же, в веб Kotlin прекрасно работал через Kotlin/JS, ещё задолго до появления WASM)
Python - из коробки на сервере; Brython - рантайм для браузера (опять же, через JS).
CUDA работает на видеокарте. На CPU есть ли какой-то смысл запускать AI-модели (ну кроме чисто учебных)? Во сколько раз просядет производительность? Точнее, на сколько порядков? WebAssembly как-то умеет работать на GPU?
Эээ, нет.
Это совсем не уникальное преимущество WASM или Rust.
Эээ, я думал, ИИ-модели запускают на CUDA, при чём тут WebAssembly? Может, в данном случае лучше предусмотреть CUDA API или хотя бы OpenCL API для браузера?
Вот всегда в таких статьях "как мы покоряем просторы вселенной" говорится о больших фичах, но всегда не обращается внимание на то, что "есть нюанс". Например, GC они выпустили, ага. Только там почему-то дереференс nullptr приводит к trap-у, а не к исключению, что полностью противоречит поведению в подавляющем числе мейнстримных языков с управляемой кучей (JS, Java, C#, Python); аналогично с делением на ноль или с neg для -0x100000000. Или вот GC не поддерживается ни в одном известном мне безбраузерном движке. Или что до сих пор не выпустили никакого стандарта debug информации, а поддержка DWARF (где она есть) сырая просто до неюзабельности и вообще не вполне стандартизирована (я как автор компилятора в WASM лично сталкивался с тем, что wasmtime и chrome понимают DWARF по-разному). Ну и что DWARF идеологически никак не ложится на языки с GC. Или что ничего близко к "нативной производительности" в WebAssembly и не пахнет, что его "куча" спроектирована так, что любое обращение к памяти неминуемо обкладывается проверками на рантайме, и как авторы этих рантаймов героически пишут оптимизации, призванные количество этих проверок хоть как-то снизить.
Зато, о чудо, реализовали хвостовую рекурсию, всё многочисленное сообщество программистов на OCaml будет довольно этой новости.
B2 хватает, это факт. Другое дело - это скорость и нагрузка. По-русски я пишу быстрее и лучше, при этом прикладывая меньше усилий. И да, я "-тся" и "-ться" не путаю, "не" знаю когда писать раздельно или слитно, но вот те же артикли так и не осилил во всех нюансах.
В догонку вспомнился один случай - как-то про мой проект кто-то упомянул в комментариях к посту в hacker news. И несколько пользователей сразу пожаловались - а по документации проекта не понятно, как вообще начать его использовать. При том, что документация getting started была - как с помощью строчки в CLI создать пустой проект hello world. Естественно, в шаблоне я добавил комментариев, чтобы человек мог создать проект, посмотреть код и увидеть тут же объяснение. Но видимо, они не осилили скопировать текст в консоль, или просто не знали, что в IDEA есть поддержка архетипов в UI - и сразу сделали вывод.
Ещё момент: многие разработчики open source проектов попросту не являются native english speaker и писать документацию с условным B2 (а именно на нём часто люди застревают в плато, с которого в C1 непонятно как попасть, не посвящая вообще всё свободное время планомерному изучению - где же тогда взять время на кодинг) довольно-таки сложно и медленно. И, наконец, разработчику не всегда очевидно, что может вызвать затруднения у других.