Блог*
Лучший пост?
Опрос завершён (с всего 89 голосов — где вы все?!). Не буду проходится по всем пунктам — иначе это слишком уж походит на самолюбование — хочу отметить лишь наиболее популярный вариант.
Пост про регулярные выражения. Честно говоря, я удивлён. Ну то есть, я писал о куда как более продвинутых вещах, а здесь я даже кода никакого не привёл. В чём же дело? Я вижу две возможные причины.
Во-первых, это тема, понятная и близкая многим разработчикам, да и, в общем-то, также и некоторым из тех, кто программистом не является. Остальные авторские посты у меня погружаются вкостыли тонкости Rust — языка всё ещё не особо широко распространённого, а регулярные выражения — это то, пост про что можно скинуть коллеге.
Во-вторых, да, тон поста. Если в других постах я обычно стараюсь выдерживать относительно нейтральный тон, то тут я дал волю своему раздражению и щедро сдобрил пост речевой мишурой. Является ли это фактором внимания в силу самого тона как такого или в силу того, что пост столь сильно выбивается среди остальных — мне неизвестно.
А что вы можете сказать по этому поводу? Серьёзно, почему?
Пост про регулярные выражения. Честно говоря, я удивлён. Ну то есть, я писал о куда как более продвинутых вещах, а здесь я даже кода никакого не привёл. В чём же дело? Я вижу две возможные причины.
Во-первых, это тема, понятная и близкая многим разработчикам, да и, в общем-то, также и некоторым из тех, кто программистом не является. Остальные авторские посты у меня погружаются в
Во-вторых, да, тон поста. Если в других постах я обычно стараюсь выдерживать относительно нейтральный тон, то тут я дал волю своему раздражению и щедро сдобрил пост речевой мишурой. Является ли это фактором внимания в силу самого тона как такого или в силу того, что пост столь сильно выбивается среди остальных — мне неизвестно.
А что вы можете сказать по этому поводу? Серьёзно, почему?
Telegram
Блог*
#prog #моё
Если вы используете регулярные выражения — вам должно быть за это стыдно
У регулярных выражений есть куча недостатков, и, на мой взгляд, их слишком часто используют там, где не надо. Сейчас я расскажу о том, что же с ними не так.
Проблемы
1.…
Если вы используете регулярные выражения — вам должно быть за это стыдно
У регулярных выражений есть куча недостатков, и, на мой взгляд, их слишком часто используют там, где не надо. Сейчас я расскажу о том, что же с ними не так.
Проблемы
1.…
#prog #rust #rustreleasenotes
А тем временем вышла версия Rust 1.49.0 🎉. Конечно, вы можете прочитать пост в официальном блоге, но там по традиции пишут не всё, а я, как обычно, нововведения обозреваю выборочно.
Наиболее значимое с точки зрения кровавого энтерпрайза изменение — это поднятие уровня поддержки таргета
Впрочем, для тех, кто разрабатывает на Rust под x86, это не столь интересное изменение. А вот что является универсальным улучшением — так это появившаяся теперь возможность привязывать в одном и том же паттерне одновременно и по значению, и по ссылке — честно говоря, я удивлён, что про это в официальном блоге ничего не сказано. Короткий пример:
Массивы всех размеров теперь реализуют Index{, Mut}<всё, чем можно индексировать слайс>. Казалось бы, мелочь, поскольку индексация работала и до этого через deref coercion, но до влития этого PR реализация для массива индексации собственным типом ломала индексацию через
Ну и наконец, как я уже писал, наконец-то стабилизировали select_nth_unstable{, _by{, _key}}, ю-ху! Теперь можно на изи извлекать n наименьших/наибольших элементов без аллокаций. Дупликации кода тут нет, поскольку это те же алгоритмы, которые и так использовались внутри реализации нестабильных сортировок (что, впрочем, лишь усиливает вопросы о причине долгого срока стабилизации).
Короче — хороший, годный релиз.
P. S.: так как я тоже писал не всё — вот полные записи о релизе.
А тем временем вышла версия Rust 1.49.0 🎉. Конечно, вы можете прочитать пост в официальном блоге, но там по традиции пишут не всё, а я, как обычно, нововведения обозреваю выборочно.
Наиболее значимое с точки зрения кровавого энтерпрайза изменение — это поднятие уровня поддержки таргета
aarch64-unknown-linux-gnu до tier 1, то есть компилятор гарантированно собирает исполняемые файлы для данной платформы, и для этой платформы обязательны прохождения полного набора тестов. Это изменение значимо не только из-за того, что убирает одно из препятствий на пути к использованию Rust на всё растущем количестве ARM-устройств, но и потому, что это первая не-x86 платформа, которая добралась до tier 1. Это не единственный ARM-таргет, получивший внимание — до tier 2 подняли поддержку aarch64-apple-darwin (да, это M1) и aarch64-pc-windows-msvc.Впрочем, для тех, кто разрабатывает на Rust под x86, это не столь интересное изменение. А вот что является универсальным улучшением — так это появившаяся теперь возможность привязывать в одном и том же паттерне одновременно и по значению, и по ссылке — честно говоря, я удивлён, что про это в официальном блоге ничего не сказано. Короткий пример:
let [foo, ref bar] = [String::from("foo"), String::from("bar")];
Неразмеченные объединения (union) теперь могут реализовывать Drop. Стабилизирована эта фича именно так, как и предполагалась: в объединении всё так же не разрешается иметь поля, реализующие Drop, так что их надо заворачивать в ManuallyDrop. Для конечных пользователей языка это означает главным образом то, что всякие SmallVec/SmallString, хранящие элементы на стеке при небольшом их количестве, теперь могут переиспользовать память при помощи union на стабильной версии компилятора и не хранить тег, то есть простое обновление компилятора и библиотеки срежет несколько байт с размеров этих типов вообще без каких-либо дополнительных телодвижений. Ну, в идеале.Массивы всех размеров теперь реализуют Index{, Mut}<всё, чем можно индексировать слайс>. Казалось бы, мелочь, поскольку индексация работала и до этого через deref coercion, но до влития этого PR реализация для массива индексации собственным типом ломала индексацию через
usize и всякие Range*.Ну и наконец, как я уже писал, наконец-то стабилизировали select_nth_unstable{, _by{, _key}}, ю-ху! Теперь можно на изи извлекать n наименьших/наибольших элементов без аллокаций. Дупликации кода тут нет, поскольку это те же алгоритмы, которые и так использовались внутри реализации нестабильных сортировок (что, впрочем, лишь усиливает вопросы о причине долгого срока стабилизации).
Короче — хороший, годный релиз.
P. S.: так как я тоже писал не всё — вот полные записи о релизе.
#prog #rust #article
Статья об особенностях синтаксиса Rust. Не без огрехов: некоторые аргументы откровенно притянуты за уши.
Статья об особенностях синтаксиса Rust. Не без огрехов: некоторые аргументы откровенно притянуты за уши.
Хабр
Так ли токсичен синтаксис Rust?
fn main() { println!("Hello, Rust!"); println!("... Goodbye!"); } Синтаксис — это первое, на что обращают внимание разработчики, впервые столкнувшись с кодом...
Forwarded from oleg_log (Oleg Kovalov)
Вы ведь знаете, что в го надо аккуратно с переменными из for-range обращаться, да?
Наверное каждый хоть раз обжигался о
или что-то похожее, где "захватывается" значение в кложуре. Есть даже пропозал, что давайте от этого уйдём (в го2, когдатотам) https://github.com/golang/go/issues/20733
Там забавный комент добавили, может слышали, Let's Encrypt недавно откатили 3М+ сертификатов. Угадайте из-за чего)))
https://github.com/letsencrypt/boulder/pull/4690/files#diff-d02067a9f9a2bed1110fd4e98641c2effcf5d1d5f18461e35d6ac1535f6e2c21L1411-R1414
Наверное каждый хоть раз обжигался о
for k, v := range foo {
go run(k,v)
}или что-то похожее, где "захватывается" значение в кложуре. Есть даже пропозал, что давайте от этого уйдём (в го2, когдатотам) https://github.com/golang/go/issues/20733
Там забавный комент добавили, может слышали, Let's Encrypt недавно откатили 3М+ сертификатов. Угадайте из-за чего)))
https://github.com/letsencrypt/boulder/pull/4690/files#diff-d02067a9f9a2bed1110fd4e98641c2effcf5d1d5f18461e35d6ac1535f6e2c21L1411-R1414
#prog #go
Несколько более подробно про инцидент. Это к вопросу о том, чем плох Go и почему мутабельность и разделяемость плохо сочетаются.
Суть ошибки состоит в том, что в неправильном коде переменная цикла захватывалась по указателю, то есть та самая переменная, которая меняется на каждой итерации. Это привело к тому, что позднее вместо вызова проверки для каждого из N элементов списка она вызывалась N раз для одного и того же элемента. И это известная ловушка.
Неприятной особенностью этого паттерна ошибки является то, что переменная может быть захвачена по указателю даже в том случае, если от неё не берётся явно адрес — можно вызвать на значении метод, принимающий значение по указателю, и это синтаксически неотличимо от вызова метода, принимающего значение по, собственно, значению. Также можно нарезать слайс, и синтаксически это не выглядит как взятие указателя, хотя и является семантически.
Несколько более подробно про инцидент. Это к вопросу о том, чем плох Go и почему мутабельность и разделяемость плохо сочетаются.
Суть ошибки состоит в том, что в неправильном коде переменная цикла захватывалась по указателю, то есть та самая переменная, которая меняется на каждой итерации. Это привело к тому, что позднее вместо вызова проверки для каждого из N элементов списка она вызывалась N раз для одного и того же элемента. И это известная ловушка.
Неприятной особенностью этого паттерна ошибки является то, что переменная может быть захвачена по указателю даже в том случае, если от неё не берётся явно адрес — можно вызвать на значении метод, принимающий значение по указателю, и это синтаксически неотличимо от вызова метода, принимающего значение по, собственно, значению. Также можно нарезать слайс, и синтаксически это не выглядит как взятие указателя, хотя и является семантически.
The Register
Let's Encrypt? Let's revoke 3 million HTTPS certificates on Wednesday, more like: Check code loop blunder strikes
Tons of TLS certs need to be tossed immediately after Go snafu
Forwarded from Generative Anton
Есть забавная традиция называть проекты/библиотеки именами различных мифических существ и божеств. И у меня давно лежала идея хелпера по подбору таких названий, но реализовал только сейчас.
Я напарсил самый большой список названий божеств из 43 пантеонов, что дало 4096 уникальных имён (и 9000 если считать ещё все алиасы). Ну а чтобы избежать коллизий, проект на лету ищет эти имена в названиях репозиториев на Гитхабе и показывает топ-результаты.
Из интересной инженерии: проект на Svelte, чуть позже опубликую сорцы. И внутри есть база на 1Мб сырого json'a, которая затаскивается в общий бандл приложения и ужимается до 150кб. И из-за этого хака всё успешно хостится как статика на Digital Ocean'e за 0.00$ в месяц. Дизайн тоже корявенько делал я. И запросы к Гитхабу — клиентские, лимиты запросов — только клиентские. Легчайшая поддержка.
Из того, что осталось доделать: стили на небольших экранах немного едут, но не критично.
Во славу NJARANA, австралийского бога сна хороших собак.
https://newprojectname.dev
Я напарсил самый большой список названий божеств из 43 пантеонов, что дало 4096 уникальных имён (и 9000 если считать ещё все алиасы). Ну а чтобы избежать коллизий, проект на лету ищет эти имена в названиях репозиториев на Гитхабе и показывает топ-результаты.
Из интересной инженерии: проект на Svelte, чуть позже опубликую сорцы. И внутри есть база на 1Мб сырого json'a, которая затаскивается в общий бандл приложения и ужимается до 150кб. И из-за этого хака всё успешно хостится как статика на Digital Ocean'e за 0.00$ в месяц. Дизайн тоже корявенько делал я. И запросы к Гитхабу — клиентские, лимиты запросов — только клиентские. Легчайшая поддержка.
Из того, что осталось доделать: стили на небольших экранах немного едут, но не критично.
Во славу NJARANA, австралийского бога сна хороших собак.
https://newprojectname.dev
Forwarded from ya mpa 🌲
Proposal #666
Вместо обычных лайфтаймов переменных в расте использовать:
Вместо обычных лайфтаймов переменных в расте использовать:
fn something<á, е́, ó>(ap: &á T, bp: &é T) -> &ó T#prog #cpp #article
Валидатор (и папир о нём) компиляций, проводимых LLVM, по отношению к многопоточным программам. Поспособствовал выявлению нескольких багов в LLVM.
"We construct a validator that checks whether the transformations performed by LLVM are correct according to the C11 memory model or our inferred LLVM memory model. The validator takes as inputs the programs before and after a set of transformations. It compares them by matching their memory access patterns and reports on whether it could find a matching demonstrating that transformation is correct."
Анализатор, к сожалению, не вполне справляется с циклами и использует для них эвристику, которая может поймать только неправильную компиляцию между первыми двумя итерациями цикла. Это вполне объяснимо, поскольку частью анализа является сопоставление потока исполнения программы до и после трансформаций, а эта задача с введением циклов резко усложняется. Для программ же без циклов проводимый анализ точен и корректен (sound).
Надо отметить, что модель памяти, подразумеваемая LLVM, менее строгая, чем модель памяти C11, поскольку допускает добавление спекулятивных доступов к значениям. В связи с этим валидатор может работать, проверяю корректность трансформаций на основе обоих моделей.
Валидатор (и папир о нём) компиляций, проводимых LLVM, по отношению к многопоточным программам. Поспособствовал выявлению нескольких багов в LLVM.
"We construct a validator that checks whether the transformations performed by LLVM are correct according to the C11 memory model or our inferred LLVM memory model. The validator takes as inputs the programs before and after a set of transformations. It compares them by matching their memory access patterns and reports on whether it could find a matching demonstrating that transformation is correct."
Анализатор, к сожалению, не вполне справляется с циклами и использует для них эвристику, которая может поймать только неправильную компиляцию между первыми двумя итерациями цикла. Это вполне объяснимо, поскольку частью анализа является сопоставление потока исполнения программы до и после трансформаций, а эта задача с введением циклов резко усложняется. Для программ же без циклов проводимый анализ точен и корректен (sound).
Надо отметить, что модель памяти, подразумеваемая LLVM, менее строгая, чем модель памяти C11, поскольку допускает добавление спекулятивных доступов к значениям. В связи с этим валидатор может работать, проверяю корректность трансформаций на основе обоих моделей.
plv.mpi-sws.org
Validating Optimizations of Concurrent C/C++ Programs