У нас просто своя кастомная реализация каналов, близкая по идеалогии к "каналам на стеройдах", которая при записи не лочится и в целом дает выгоду на 24 ядрах. По сути весь треш атомиков инкапсулирован внутри. Атомики сильно затрудняют на мой взгляд понимание кода. Пример альтернативной реализации каналов: https://docs.google.com/document/d/1yIAYmbvL3JxOKOjuCyon7JhW4cSv1wy5hC0ApeGMV9s/pub

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

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

Тут уж либо играть в раздувание оценки и доли рынка, прожигая инвестиции в убыток, либо спокойно делать нишевый бизнес, который крупняку не интересен, спокойно расти как идет и не искать вложений со стороны.

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

В середине 20 века стреляли люди, подбирая дальность подрыва, а сейчас это делает автовычислитель по оптико-электронному наведению. Порядка 80 выстрелов в минуту генерируют осколочные разрывы на высоте до 4 км. Так что сверху вывалить не получится, а ковер из тысячи дронов, огибающих рельеф очень сложно организовать.

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

На войне играет роль баланс стоимости и эффективности. Против войска с калашами выглядит как супероружие без шансов, но где такие еще остались? Если решена задача напечатать тысячи дронов недорого, то теоретически можно вывалить несколько тонн этой мелочи с высоты, и не вступать в прямое столкновение. Конечно, если не на равных, а в режиме "превосходящие силы утюжат туземцев".

Если стоит задача защиты периметра от дронов, то одним из решений будет оптико-электронное наведение скорострельного пулемета, в автоматическом режиме. Современный крейсер, например, этих дронов и так не подпустит штатными средствами, потому что сбивает автоматически крылатые ракеты и прочие мелкие цели, вплоть до снарядов. Что-то аналогичное в сухопутном варианте вполне реально выставить.

Вот одновременно пару тысяч дронов из видео создали бы нагрузку, но где же их взять дешевых столько :) Кроме экономических аспектов очень интересная логистика вырисовывается и масса сопутствующих задач. Хотя бы просто одновременно в воздух поднять реально рой, а не десять штук. Как их запускать, волнами или одновременно? Если волнами, как они будут собираться и ждать друг друга, круги нарезать в определенной формации? Пока последние взлетят, у первых уже расход топлива будет, поэтому при увеличении роя дальность упадет. Если даже одновременно удастся выпустить, пусковую площадку или сотни машин просто так не спрячешь. А если скрытно разместить, то будет немобильно. Нужно какое-то более серьезное средство доставки. Не все так просто с роями.

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

У поисковика могут быть разные акценты. Если не стоит задача продать как можно больше рекламы, то могли бы наверх подняться информационные/навигационные результаты, а не коммерция. Кроме того, можно поставить задачу поиска по специфическим коллекциям, архивам, законодательству. Индексировать только проверенные источники. Некий заведомо безопасный поиск без криминала, с проверенными источниками и разными вертикалями по специфическим данным. Если серьезно подойти — большая интересная задача для большого коллектива. Почему бы и не убыточный? Лишь бы качественный.

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

В момент "перегрева" я по приколу сказал: представляешь, вот так целый день приходится думать. Кажется в этот момент они поняли, почему разработчики софта много зарабатывают и это не просто кнопки давить и формы двигать. Живешь так в пузыре, общаешься с другими разработчиками и думаешь, что это все не так и сложно. Сложно. Особенно уважают юристы, когда прочитав их "исходники" налету пару дыр в договоре находишь.

Если взять типичного водилу, то я как разработчик разложу его деятельность на запчасти, формализую оптимальные паттерны, докопаюсь, почему он не включает правильно поворотники и не придерживается траекторий. В целом тупая скучная работа оператора, хоть и ответственная. Водила же сломает мозг, если мы будем обсуждать устройство приложения.

Кроме программистов, полно специалистов, которые зарабатывают в разы и на порядок больше, будучи глубоко погруженными в предметную область. Как-то сравнивать процесс разработки с количеством высиженных часов низкоквалифицированными операторами — не совсем корректно. Я уже молчу, про хрен знает сколько лет образования и самообразования, постоянного стресса, когда твоя отрасль устаревает буквально на глазах за 2-3 года.

Разработчики — это дорогой и продвинутый обслуживающий персонал, который реализует идеи и потребности заказчиков. Заказчиков прямых или косвенных, в виде пользователей продукта. Элита — это люди, которые платят разработчикам деньги, приносят задачи и берут на себя риски.

В Go я могу локально объявить "методу нужен интерфейс publisher, который состоит из одного метода Publish()". Далее абсолютно любые объекты с методом Publish() могут быть переданы как аргумент и пролезут сквозь проверку типов. Автор объекта даже не знает, что реализовал интерфейс publisher, потому что для меня это требуемая зависимость, а для автора часть какого-то другого набора методов. В PHP для этого надо интерфейс сделать глобальным и заставить всех причастных сослаться на один и тот же неймспейс. Поэтому в PHP и слипаются во фреймворки наборы полезных объектов, из за необходимости поддержания единой иерархии зависимостей.