На самом деле отличный аргумент, против которого сложно спорить. Facebook'ом ещё обосновывают использование MySQL и PHP. Вот только первый они полностью переписали, а второй масштабно патчат под свои нужды. Полагаю, c Chef они действуют так же
Эта статья — отличная иллюстрация, почему в Go нет и не нужны исключения: их заменяет явный возврат ошибки с их явной обработкой, и паники в случае действительно исключительных ситуаций, требующих раскручивания стека; причём при работе с библиотеками так же удобнее работать с возвращаемыми оттуда ошибками, а не исключениями.
В простом случае, generic'и полезны для обёрток вокруг map (например, множество на основе map[<type>]struct{}). Можно обойтись копипастой, но это некрасиво. Их отсутствие обходится, где-то embedding'ом, где-то interface{} контейнерами, где-то генерацией кода, но генерики для проектирования (но не для дебага) гораздо проще.
Напрямую — не связано. Месседж в том, что в компиляторе, вероятно, останутся вставки C-кода для производительности. В остальном же писать и поддерживать хоть сколько-то сложную логику на Go несравнимо проще и приятнее.
Вставки на C и asm вероятнее всего никуда не денутся, просто будут на своём месте: реализовывать редкие очень критичные к производительности вещи, которые на Go недостаточно эффективны.
Это уже вопросы к государству как заказчику, а не к Спутнику. Теоретически, у них есть возможность сделать то, что Яндексу недоступно, например, поисковик по закрытым документам с регламентированным доступом.
К сожалению, пост — практически копипаста с Ъ, хотя информации известно заметно больше, в том числе о внутренних технологиях. По тому, что я знаю, инвестиции в продукт при их размере команды и серверного парка вполне адекватный, команда делает много технологически крутых штук (в опенсорсе, например, прекрасный github.com/sputnik-maps/gopnik — карты они, кстати, круто сделали), и продукт адекватно развивается. С учётом сложности современных поисковых систем (а здесь ведь помимо поиска ещё большое количество сервисов типа карт), ожидать, что можно за год собрать конкурентного Яндексу монстра несколько странно.
Проблема в том, что кмк вы исправляете последствие проблемы, а не причину. PHP очень эффективно работает с опкод кешем (особенно opcache), и ломать логику приложения (см. примеры 1-3) в этом случае — бессмысленная трата времени.
Вы пробовали провести чистый бенчмарк данной проблемы, без вашего кода?
Вы утверждаете в статье, что чисто загрузка 12Мб кода из APC опкод кеша у вас занимало больше 300мс? У вас точно не было тяжёлой инициализации с запросами в БД, криво настроенного APC (размер кеша, проверка mtime на каждый запрос etc), тяжёлого автолоадера с просмотром файловой системы и прочей связанной печали? Потому как такого порядка потребление CPU фантастическое и больше опытного на порядок.
Хостнейм не должен пробрасываться, поскольку докер явно изолирует сеть для контейнера. Если очень нужен хостнейм сервера, его несложно пробросить внутрь приложения, например, флагом.
С DNS сложнее, в нашем случае пришлось явно в маунтах пробрасывать для контейнера сокет nscd.
Расскажите, пожалуйста, что вы имеете ввиду под фрактальными и голографическими моделями данных. В идеале, сразу со ссылками на соответствующие научные работы. Надеюсь, это не имеет отношения к фрактальным деревьям?
Интересная и полезная тема. Расскажите, какие есть проблемы в отрасли, как они проходят через все слои защиты от багов и проблем (например, в вашем примере про % за вклады не хватает, как оно вообще прошло мимо архитектора и кодревью), как принимаются решения должностными лицами. Судя по всему, у вас богатый опыт, и вам есть что рассказать.
Отдельно, расскажите, как вы собираетесь делать ядро: это не менее интересно. Архитектура, как делать финансовый процессинг, какие подводные камни, какие БД использовать, как это обслуживать. Например, планируете ли вы взять VoltDB, чтобы дать возможность клиентам кардинально снизить издержки на процессинг?
Этот самый «кластерный индекс» в постгресе не поддерживает обновления данных и на практике портит оптимизатора запросов (некоторые запросы вместо работы по индексам делают full table scan). То есть фактически его нет.
При этом с MySQL в условиях, когда памяти сильно меньше горячих данных, только кластерный индекс спасает производительность хоть сколько-то больших выборок по диапазону в primary key. Это реальный кейс многих высоконагруженных проектов, и в них постгрес непригоден. По мелочи, бывает полезно, что в InnoDB primary индекс содержит данные.
С другой стороны, на мой взгляд, на этом исчерпываются ключевые преимущества MySQL перед Postgres. Впрочем, говорят, репликация в mysql гораздо более адекватная (благодаря galera), и актеры
«Красивая штука» — не более чем способ презентации. Банкам, как и любому бизнесу, нужно решение проблем. Людям, принимающим решения, нужно решение проблем в их понимании. Прототип вполне может этим быть — всё зависит от презентации и того, кто её смотрит. Специалист по вебкиту нужен, чтобы сделать идеально, что совершенно не обязательно для принятия решения о внедрении.
Кстати, я бы на вашем месте начал не с банков, а с агрегаторов платежей и им подобных.
>осталось решить вопрос с … инвестициями — нам они очень нужны
В этом проблема очень большого количества перспективных стартаперов: вам не нужны инвестиции, чтобы начать делать стартап. Минимальный прототип почти любого стартапа собирается на коленке за пару месяцев, если работать только над ним. Это можно делать даже без отрыва от работы (отпуск + отпуск за свой счёт + праздники), была бы цель и желание. Человек от бизнеса, да, вам будет крайне полезен для упрощения получения фидбека и тестовых внедрений, но даже оно не обязательно. Пора уже взрослеть: вы сами уже ответственны за своё будущее, а не родители/инвесторы.
Инвестиции на этапе непроверенного прототипа — зло, ввиду обязанностей перед инвесторами вынуждающее вас не делать, например, pivot там, где близкая ниша может оказаться гораздо более перспективной.
Альтернативный вариант, если вы говорите, что вы не стартапер, а крутой специалист, и вам будет интересно делать такой проект за зарплату. Это будет гораздо честнее, и повысит шансы на старт проекта.
По закону «О связи» на провайдеров явно наложена обязанность сохранять тайну связи. www.consultant.ru/popular/communication/28_9.html#p1204
Более того, тот же закон «О связи» явно требует приостанавливать лицензию при нарушении закона.
По результатам, кого это задело, нужно писать в роскомнадзор с требованием приостановить лицензию, параллельно получать документальное подтверждение передачи трафика третим лицам и на основе него инициировать возбуждение уголовного дела. Поступать мягче с теми, кто настолько жёстко игнорирует российские законы — нельзя.
Вы пробовали провести чистый бенчмарк данной проблемы, без вашего кода?
С DNS сложнее, в нашем случае пришлось явно в маунтах пробрасывать для контейнера сокет nscd.
Крупный продакшн, всё работает.
Отдельно, расскажите, как вы собираетесь делать ядро: это не менее интересно. Архитектура, как делать финансовый процессинг, какие подводные камни, какие БД использовать, как это обслуживать. Например, планируете ли вы взять VoltDB, чтобы дать возможность клиентам кардинально снизить издержки на процессинг?
При этом с MySQL в условиях, когда памяти сильно меньше горячих данных, только кластерный индекс спасает производительность хоть сколько-то больших выборок по диапазону в primary key. Это реальный кейс многих высоконагруженных проектов, и в них постгрес непригоден. По мелочи, бывает полезно, что в InnoDB primary индекс содержит данные.
С другой стороны, на мой взгляд, на этом исчерпываются ключевые преимущества MySQL перед Postgres. Впрочем, говорят, репликация в mysql гораздо более адекватная (благодаря galera), и актеры
Кстати, я бы на вашем месте начал не с банков, а с агрегаторов платежей и им подобных.
В этом проблема очень большого количества перспективных стартаперов: вам не нужны инвестиции, чтобы начать делать стартап. Минимальный прототип почти любого стартапа собирается на коленке за пару месяцев, если работать только над ним. Это можно делать даже без отрыва от работы (отпуск + отпуск за свой счёт + праздники), была бы цель и желание. Человек от бизнеса, да, вам будет крайне полезен для упрощения получения фидбека и тестовых внедрений, но даже оно не обязательно. Пора уже взрослеть: вы сами уже ответственны за своё будущее, а не родители/инвесторы.
Инвестиции на этапе непроверенного прототипа — зло, ввиду обязанностей перед инвесторами вынуждающее вас не делать, например, pivot там, где близкая ниша может оказаться гораздо более перспективной.
Альтернативный вариант, если вы говорите, что вы не стартапер, а крутой специалист, и вам будет интересно делать такой проект за зарплату. Это будет гораздо честнее, и повысит шансы на старт проекта.
www.constitution.ru/10003000/10003000-4.htm#23
По закону «О связи» на провайдеров явно наложена обязанность сохранять тайну связи.
www.consultant.ru/popular/communication/28_9.html#p1204
Более того, тот же закон «О связи» явно требует приостанавливать лицензию при нарушении закона.
И, в довесок, уголовная ответственность всем причастным в нарушении тайны связи
www.consultant.ru/popular/ukrf/10_27.html#p1966
По результатам, кого это задело, нужно писать в роскомнадзор с требованием приостановить лицензию, параллельно получать документальное подтверждение передачи трафика третим лицам и на основе него инициировать возбуждение уголовного дела. Поступать мягче с теми, кто настолько жёстко игнорирует российские законы — нельзя.
На презентации порадовала цифра в $12M на R&D — насколько я понимаю, это очень мало для такого телефона.