Если человек знает иностранный язык, он может на нём говорить
Есть такое интересно понятие - активный и пассивный словарный запас. Оно в этом мифе, кмк, играет одну из главных ролей. Я на себе это отлично чувствую. Чтение, письмо, видео и речь на слух - без проблем. А вот начать говорить - и тут ступор. Потому что одно дело спокойно вспомнить значение какого-то слова, которое бывает ты только интуитивно понимаешь - пассивный запас. Совсем другое спонтанно вспомнить и правильно применить ровно тоже самое слово - активный запас.
Я бы даже сказал, что это касается в целом любой части языка. Сложные идиомы, грамматические формы. Все тоже самое обычно можно сказать намного проще.
Угу, ими и не надо пользоваться. Ниразу не видел их использования. Ни в своих проектах, ни в каких-либо зависимостях, которые смотрел сорцы. Если еще примут пропозал об их удалении из языка, то будет совсем замечательно.
Каких конфликтов? Все внешние символы всегда используют полный квалификатор с указанием имени пакета, что как раз исключает конфликты имен. Есть проблемы только с пакетами с одинаковым именем, для чего есть переименование при импорте.
Так на словах совершенно не ясно, о каких конфликтах речь. Нужен пример. Вот в шарпах могу представить, где символы прям напрямую импортируются обычно и обращаешься к ним так, будто они у тебя локально в неймспейсе лежат.
Вполне стандартная тема для многих языков. Тот же C# шарит все внутри одного неймспейса между файлами. В Go есть одна вещь, которая сильно улучшает читабельность - можно однозначно отличить, откуда символ пришел. Если у него нет идентификатора пакет, то это локальный символ из текущего пакета (опускаем dot-imports, которыми никто не пользуется). Иначе, всегда будет идентификатор пакета и по импортам ясно, откуда он пришел. Теже шарпы или Java читать намного сложнее, потому что при импорте все символы, как правило, доступны напрямую без необходимости писать идентификатор неймспейса. И хер ты без IDE поймешь, откуда взялся тот или иной класс.
Не знаю, где обычно, но обычно как раз все пишется в одном пакете. В отдельный пакет выносятся тесты обычно для так сказать более строго отделения от подробностей реализации (и поэтому очень полезно, что ты не можешь непубличный метод достать. В этом вся фишка), либо по каким-то объективным иным причинам. Например, интеграционный тесты часто туда уносят, т.к. обычно это целая гора никак не связанного с основным приложением кода. Порой еще выносят это в отдельный го модуль, чтобы не тянуть ненужные зависимости в основной бинарь.
А зачем это нужно? Ты либо импортируешь пакет, либо нет. К пакету всегда обращение через его имя, поэтому пофиг, сколько десятков тысяч символов в нем. И читается это всегда однозначно
Конкретно для клаудфлейр раст был выбран совсем не из-за того, что плюсы не справляются. Нджинкс на расте был бы такой же медленный для них. Проблема в его архитектуре. Раст там именно что был выбран как более модный и современный с гарантиями безопасности.
По-моему в C изначально UB именно для этого и было и означало скорее implementation defined поведение. Т.е. язык как бы не при делах, но в конкретных условиях все ок. В те времена C еще можно было считать человекочитаемым ассемблером.
Сейчас же UB предназначено целиком и полностью для оптимизации, чтобы у компилятора была свобода ломать код так, как ему вздумается. Платформа здесь не имеет значения, потому что компилятор не смотрит на то, что в какой-то системе two's complement представление чисел. Для него UB это UB на любой платформе. Собственно, для него вообще платформы конечной не существует - он работает с абстрактной машиной. Поэтому как выше писали, проверка на переполнение будет просто удалена компилятором. Поэтому и версия компилятора может запросто сломать то, что работало раньше, если оно опиралось на UB.
Только вот заказчик не обязан ничего принимать. На испытаниях запросто может оказаться, что интерпретации исполнителя и заказчика расходятся и последний не считает ТЗ выполненным. И дальше только в суд и не факт, что исполнитель еще прав, тк возможно пытается натягивать сову на глобус, чтобы не переделывать ничего. И аджайл тут как раз очень кстати, тк позволит скорректировать реализацию на раннем этапе и прийти на испытания по сути как на формальность, тк заказчика уже все устраивает и он все видел. Интерес тут с обоих сторон есть и на моей практике теже гос заказчики очень желают так работать
Единица измерения в скраме совсем другая - польза бизнесу, а никакая не скорость разработки в вакууме. Можно гордо строчить задачи одна за другой и хвастаться скоростью, но потом окажется, что все эти задачи сделаны в пустую.
Польза от скрама постулируется по сути одна - увеличение пользы для бизнеса за счет коротких циклов разработки и постоянного фидбека. Чтобы как выше пишут не оказалось, что мы год писали что-то очень быстро в отрыве от всех и били рекорды, а потом оказалось, что большая часть сделана впустую. Поэтому да, вот так в лоб нельзя сравнивать.
Почему с первым. В целом система защиты xbox 360 полагалась на eFuse как средство против даунгрейда. Там был счетчик, который при каждом обновлении увеличивался, физически "прожигая" фьюз.
Теоретически да с учетом, что сама ВМ написана на тех же плюсах. На практике, я не могу найти уязвимостей особо в их JITe. Почему так - сложно сказать. Возможно виной тому дизайн байткода, семантика самого языка. Его куда легче верифицировать чем JS, в котором все что угодно на уровне системы типов может твориться.
Другая часть это стандартная библиотека. Тут все очевидно. У Java и .Net она реализована на Java и C# соответственно. Тем самым, практически весь код JDK и .Net Core получает те же гарантии безопасности, что код приложений. Остается лишь относительно маленькая часть на плюсах, которая реализует GC, JIT и вот это все. Javascript и V8 реализация как минимум сделана иначе. Там и стандартная библиотека написана на плюсах и можно найти множество CVE, которые были вызваны именно этим.
Нет, этот вывод как раз таки универсальный. Если погуглить, то примерно такая же статистика есть по Windows, Linux, iOS, macOS, android. И все эти проблемы были бы решены безопасными языками.
куда уж взломщикам понять во что выльется их попытка влезть в эту систему
Взломщикам плевать на компилятор. У них есть готовый бинарь и окружение и под них пишется шеллкод. Если надо, под конкретные версии.
Реальные уязвимости связаны с людьми и логическими ошибками
Реальные уязвимости связаны как раз с тем, что в статье перечислено. Выходы за границы, двойное освобождение, целочисленные переполнения - все это реально эксплуатируется постоянно. Более того, эксплуатируется порой не напрямую, а косвенно из того же Javascript атакуют JIT. И вы еще говорите о невозможности чего-то там взломщиками.
Эту проблему не способен решить никакой язык
Эта проблема полностью решена в GC языках как класс. Она практически полностью решена в Swift за исключением циклических ссылок. Но и они очень редко создают проблемы.
в языке Go нет 'const', при этом все функции принимают всё по (мутабельным) указателям, а менять данные из двух потоков - уб. Невероятно безопасный язык.
Во-первых, в Go не такого понятия как UB и гонки не приводят к UB в том понимании, в котором это заведено в C/C++. Есть строго определенное число возможных исходов. И самое главное, это не приведет к эксплуатируемой уязвимости. Максимум это логическая ошибка или рантайм паника.
Зато двоичный поиск генерирует кэш промахи и сбивает логику префетчинга, а на этом часто весь перформанс и умирает. Подобное надо бенчить на конкретных продовых данных.
В сях массив таки придется весь пройти, чтобы длину получить. И тогда бинарный поиск тут уже будет бесполезен, как и сам факт отсортированности массива.
Для инвалидации in-memory всех инстансов не нужно заводить редисы и прочие pub-sub. Достаточно каждый инстанс посадить на топик без consumer group и пусть каждый читает одни и теже эвенты.
По thundering herd. Есть простое решение в виде библиотеки singleflight и подобной ей механизмов. Пока один запрос выполняется, все остальные стоят и ждут на локе. После разблокировки все получат один и тот же ответ и дальше пойдет раздача из кэша. Можно сделать лок распределенным, но в большинстве случаев не страшно, если будут локальные локи и каждый инстанс пойдет на промахе один раз в основной стор.
По этой же причине отвал был и у xbox 360, и у nvidia чипов.
Помню эти времена и все эти колхозные решения. Реболл это был высший пилотаж. Обычно же в домашних условиях кулер посильнее прикручивался, так называемой метод прижима. Мой 360 в таких условиях прожил еще несколько лет. Сначала да, думали на шарики под bga. Потом уже додумали, что на самом деле проблема в креплении кристалла к подложке. А видео выше дало еще более точный ответ - проблема в компаунде. Тогда не помню, чтобы о такой версии говорили.
Именно! Когда язык не однороден - тут значение, а тут типа тоже "значение", которое указатель, появляется много не очевидных моментов в таких структурах.
Язык то как раз предельно однороден. Все передается по значения и этот постулат нигде не нарушается. Ни у слайсов, ни у мап, ни у каналов.
Есть такое интересно понятие - активный и пассивный словарный запас. Оно в этом мифе, кмк, играет одну из главных ролей. Я на себе это отлично чувствую. Чтение, письмо, видео и речь на слух - без проблем. А вот начать говорить - и тут ступор. Потому что одно дело спокойно вспомнить значение какого-то слова, которое бывает ты только интуитивно понимаешь - пассивный запас. Совсем другое спонтанно вспомнить и правильно применить ровно тоже самое слово - активный запас.
Я бы даже сказал, что это касается в целом любой части языка. Сложные идиомы, грамматические формы. Все тоже самое обычно можно сказать намного проще.
Угу, ими и не надо пользоваться. Ниразу не видел их использования. Ни в своих проектах, ни в каких-либо зависимостях, которые смотрел сорцы. Если еще примут пропозал об их удалении из языка, то будет совсем замечательно.
Каких конфликтов? Все внешние символы всегда используют полный квалификатор с указанием имени пакета, что как раз исключает конфликты имен. Есть проблемы только с пакетами с одинаковым именем, для чего есть переименование при импорте.
Так на словах совершенно не ясно, о каких конфликтах речь. Нужен пример. Вот в шарпах могу представить, где символы прям напрямую импортируются обычно и обращаешься к ним так, будто они у тебя локально в неймспейсе лежат.
Вполне стандартная тема для многих языков. Тот же C# шарит все внутри одного неймспейса между файлами. В Go есть одна вещь, которая сильно улучшает читабельность - можно однозначно отличить, откуда символ пришел. Если у него нет идентификатора пакет, то это локальный символ из текущего пакета (опускаем dot-imports, которыми никто не пользуется). Иначе, всегда будет идентификатор пакета и по импортам ясно, откуда он пришел. Теже шарпы или Java читать намного сложнее, потому что при импорте все символы, как правило, доступны напрямую без необходимости писать идентификатор неймспейса. И хер ты без IDE поймешь, откуда взялся тот или иной класс.
Не знаю, где обычно, но обычно как раз все пишется в одном пакете. В отдельный пакет выносятся тесты обычно для так сказать более строго отделения от подробностей реализации (и поэтому очень полезно, что ты не можешь непубличный метод достать. В этом вся фишка), либо по каким-то объективным иным причинам. Например, интеграционный тесты часто туда уносят, т.к. обычно это целая гора никак не связанного с основным приложением кода. Порой еще выносят это в отдельный го модуль, чтобы не тянуть ненужные зависимости в основной бинарь.
А зачем это нужно? Ты либо импортируешь пакет, либо нет. К пакету всегда обращение через его имя, поэтому пофиг, сколько десятков тысяч символов в нем. И читается это всегда однозначно
Конкретно для клаудфлейр раст был выбран совсем не из-за того, что плюсы не справляются. Нджинкс на расте был бы такой же медленный для них. Проблема в его архитектуре. Раст там именно что был выбран как более модный и современный с гарантиями безопасности.
По-моему в C изначально UB именно для этого и было и означало скорее implementation defined поведение. Т.е. язык как бы не при делах, но в конкретных условиях все ок. В те времена C еще можно было считать человекочитаемым ассемблером.
Сейчас же UB предназначено целиком и полностью для оптимизации, чтобы у компилятора была свобода ломать код так, как ему вздумается. Платформа здесь не имеет значения, потому что компилятор не смотрит на то, что в какой-то системе two's complement представление чисел. Для него UB это UB на любой платформе. Собственно, для него вообще платформы конечной не существует - он работает с абстрактной машиной. Поэтому как выше писали, проверка на переполнение будет просто удалена компилятором. Поэтому и версия компилятора может запросто сломать то, что работало раньше, если оно опиралось на UB.
Что-то мне это напоминает... https://ru.wikipedia.org/wiki/Система_социального_кредита
Только вот заказчик не обязан ничего принимать. На испытаниях запросто может оказаться, что интерпретации исполнителя и заказчика расходятся и последний не считает ТЗ выполненным. И дальше только в суд и не факт, что исполнитель еще прав, тк возможно пытается натягивать сову на глобус, чтобы не переделывать ничего. И аджайл тут как раз очень кстати, тк позволит скорректировать реализацию на раннем этапе и прийти на испытания по сути как на формальность, тк заказчика уже все устраивает и он все видел. Интерес тут с обоих сторон есть и на моей практике теже гос заказчики очень желают так работать
В том числе по этой причине стендап и проводится в одно и тоже время
Единица измерения в скраме совсем другая - польза бизнесу, а никакая не скорость разработки в вакууме. Можно гордо строчить задачи одна за другой и хвастаться скоростью, но потом окажется, что все эти задачи сделаны в пустую.
Польза от скрама постулируется по сути одна - увеличение пользы для бизнеса за счет коротких циклов разработки и постоянного фидбека. Чтобы как выше пишут не оказалось, что мы год писали что-то очень быстро в отрыве от всех и били рекорды, а потом оказалось, что большая часть сделана впустую. Поэтому да, вот так в лоб нельзя сравнивать.
Почему с первым. В целом система защиты xbox 360 полагалась на eFuse как средство против даунгрейда. Там был счетчик, который при каждом обновлении увеличивался, физически "прожигая" фьюз.
Теоретически да с учетом, что сама ВМ написана на тех же плюсах. На практике, я не могу найти уязвимостей особо в их JITe. Почему так - сложно сказать. Возможно виной тому дизайн байткода, семантика самого языка. Его куда легче верифицировать чем JS, в котором все что угодно на уровне системы типов может твориться.
Другая часть это стандартная библиотека. Тут все очевидно. У Java и .Net она реализована на Java и C# соответственно. Тем самым, практически весь код JDK и .Net Core получает те же гарантии безопасности, что код приложений. Остается лишь относительно маленькая часть на плюсах, которая реализует GC, JIT и вот это все. Javascript и V8 реализация как минимум сделана иначе. Там и стандартная библиотека написана на плюсах и можно найти множество CVE, которые были вызваны именно этим.
И что? Для GC циклические ссылки не представляют проблемы. Или вы о чем?
Нет, этот вывод как раз таки универсальный. Если погуглить, то примерно такая же статистика есть по Windows, Linux, iOS, macOS, android. И все эти проблемы были бы решены безопасными языками.
Взломщикам плевать на компилятор. У них есть готовый бинарь и окружение и под них пишется шеллкод. Если надо, под конкретные версии.
Реальные уязвимости связаны как раз с тем, что в статье перечислено. Выходы за границы, двойное освобождение, целочисленные переполнения - все это реально эксплуатируется постоянно. Более того, эксплуатируется порой не напрямую, а косвенно из того же Javascript атакуют JIT. И вы еще говорите о невозможности чего-то там взломщиками.
Эта проблема полностью решена в GC языках как класс. Она практически полностью решена в Swift за исключением циклических ссылок. Но и они очень редко создают проблемы.
Во-первых, в Go не такого понятия как UB и гонки не приводят к UB в том понимании, в котором это заведено в C/C++. Есть строго определенное число возможных исходов. И самое главное, это не приведет к эксплуатируемой уязвимости. Максимум это логическая ошибка или рантайм паника.
Зато двоичный поиск генерирует кэш промахи и сбивает логику префетчинга, а на этом часто весь перформанс и умирает. Подобное надо бенчить на конкретных продовых данных.
В сях массив таки придется весь пройти, чтобы длину получить. И тогда бинарный поиск тут уже будет бесполезен, как и сам факт отсортированности массива.
Для инвалидации in-memory всех инстансов не нужно заводить редисы и прочие pub-sub. Достаточно каждый инстанс посадить на топик без consumer group и пусть каждый читает одни и теже эвенты.
По thundering herd. Есть простое решение в виде библиотеки singleflight и подобной ей механизмов. Пока один запрос выполняется, все остальные стоят и ждут на локе. После разблокировки все получат один и тот же ответ и дальше пойдет раздача из кэша. Можно сделать лок распределенным, но в большинстве случаев не страшно, если будут локальные локи и каждый инстанс пойдет на промахе один раз в основной стор.
По этой же причине отвал был и у xbox 360, и у nvidia чипов.
Помню эти времена и все эти колхозные решения. Реболл это был высший пилотаж. Обычно же в домашних условиях кулер посильнее прикручивался, так называемой метод прижима. Мой 360 в таких условиях прожил еще несколько лет. Сначала да, думали на шарики под bga. Потом уже додумали, что на самом деле проблема в креплении кристалла к подложке. А видео выше дало еще более точный ответ - проблема в компаунде. Тогда не помню, чтобы о такой версии говорили.
Можно сказать, переизобрели Loki
Язык то как раз предельно однороден. Все передается по значения и этот постулат нигде не нарушается. Ни у слайсов, ни у мап, ни у каналов.