Я тоже много проектов сам, искренне каюсь, писал без тестов и они работают до сих пор как часы годами. Проблемы начались, когда к проектам стали подключать разработчиков, которые не читали взрослых книг по разработке типа "Effective Java" Джошуа Блоха и стали безответственно комитить безумные вещи. Еще я подсмотрел, что почти во всех развивающихся opensource проектах на github тоже пишут тесты, т.к. работает сразу много людей над кодом. И да, согласен полностью, пусть AI-ассистент теперь пишет тесты, он, кстати, умеет делать это неплохо и это прекрасно!
"а не вот эти мамкины программисты с 12 лет" ну не знаю, почему именно мамкины :-) Я еще на Highload регулярно выступаю, если погуглите, видео много. И еще на хабр опубликовал почти 60 постов, по ним понятно, что за проекты и где там "миссион-критикал".
"а не вот эти мамкины программисты с 12 лет" ну не знаю, почему именно мамкины :-) Я еще на Highload регулярно выступаю, если погуглите, видео много. И еще на хабр опубликовал почти 60 постов, по ним понятно, что за проекты и где там "миссион-критикал".
Попробую объяснить просто на пальцах. Можно по-разному, гибко, рассказываю от простого к сложному. Компилятор Rust консервативный, иногда перегибает палку и его нужно учиться обходить:
1) "Объекты" создаются обычно в стеке, но могут "взять" себе память в heap.
2) У "объектов", которые "взяли" себе память в heap, обязательно в конце области видимости или в конце их владения (похоже на move-семантику в С++, но безопасная, проверяемая компилятором) вызывается деструктор - компилятором. Компилятор сам вставляет его вызов в бинарку, но в исходниках вызова не видно. По сути похоже на RAII из С++ и по сути такие объекты есть простые smart-pointers (Box).
3) Есть продвинутые "объекты" - smart-pointers, которые не только берут память в heap, но и могут "множится", в т.ч. между потоками и последний такой "объект" удаляет выделенную в heap память. Да, это подсчет ссылок, как и в Swift. Все это проверяется компилятором тоже, безопасно. Это работает с большими издержаками, чем в п.2, поэтому необязательно (Rc, Arc).
4) Можно, через indirection в heap, сделать связанный список, чтобы каждый его элемент был известного для расположения в стеке размер. Так до определенной степени поддерживаются рекурсивные структуры данных типа известного списка "Cons(2):Cons(1)::Null", деревьев и т.п..
5) Когда этого не хватает и нужно больше гибкости, можно динамически связывать "объекты" ссылками в графы через жестко контролируемую компилятором технику внутренней мутабельности (UnsafeCell <- RefCell) и его рантайм контролем ссылок. По умолчанию, ссылки всегда ведут на живые "объекты", может быть одна эксклюзивная (можно менять через нее) или несколько для чтения, но можно это делать динамически и если создашь случайно две эксклюзивные, то программа остановится (контролируемый "крэш" с вызовом деструкторов вверх по стеку - "panic"). Я думаю, это поможет сделать циклические связи в графе "объектов". Не пробовал, если честно.
6) Если не хватило гибкости, всегда есть блок "unsafe", raw-pointers и из них можно что и как угодно собрать, в т.ч. ссылки какие нужны. Может быть придется делать свой локальный сборщик мусора. Но лучше попробовать все способы выше.
Про C много читал, разные книги, много исходников смотрел. Про C++ много читал, знаю меньше. На обеих не пришлось писать, к сожалению. Начал больше 20 лет назад сразу на Java.
Я много пишу на Python и искренне увидел, что с такой же скоростью можно решать эти же задачи выразительно на Rust, только ошибок меньше, все имеет тип и код работает на порядок быстрее.
У меня есть русский перевод книги про атомарность Мары Бос (https://www.chitai-gorod.ru/product/rust-atomarnosti-i-blokirovki-3060006). К сожалению, есть ошибки в переводе смысловые, чтобы их понять и в уме исправить приходится некоторые абзацы перечитывать по несколько раз. Вообще предпочитаю читать в оригинале, т.к. технический английский не такой сложный, как литературный.
Мы BI-конструктор сделали через helm chart. Каждый клиент - установка helm-приложения в кубер. Число подов больше 25к в одном кластере кубера. Ингресс-контроллер заменили с Ingress-nginx на Contour/Envoy, т.к. при 5к виртуальных хостов первый уже не справлялся. Helm тоже перестал справлятся при 15к инсталляций helm-chart, поэтому перешли на Postgres-бекенд для хранения релизов helm там. У нас уже не скучно :-)
VK.cloud, это не секрет, мы часто про это рассказываем на конференциях. Таким образом, мы сделали репликацию между двумя крупными облачными провайдерами в России.
Молодцы коллеги! Так держать. Очень крутую и полезную работу делаете. В ближайшее время мы обязательно попробуем вашу библиотеку в наших ML-проектах на Битрикс24.
Мы изучили ваше замечание. Действительно, эта форма не должна быть обязательной и галочка: «Я ознакомлен и принимаю условия конфиденциальности персональной информации, в том числе в части обработки и использования моих персональных данных» — не нужна.
Наши специалисты сделали ошибку — в ближайшее время мы её устраним.
Я тоже много проектов сам, искренне каюсь, писал без тестов и они работают до сих пор как часы годами. Проблемы начались, когда к проектам стали подключать разработчиков, которые не читали взрослых книг по разработке типа "Effective Java" Джошуа Блоха и стали безответственно комитить безумные вещи. Еще я подсмотрел, что почти во всех развивающихся opensource проектах на github тоже пишут тесты, т.к. работает сразу много людей над кодом. И да, согласен полностью, пусть AI-ассистент теперь пишет тесты, он, кстати, умеет делать это неплохо и это прекрасно!
Спасибо!
https://gepa-ai.github.io/gepa/blog/2026/02/18/automatically-learning-skills-for-coding-agents/
Спасибо за подробный туториал!
Спасибо за пост, очень интересно и полезно.
"а не вот эти мамкины программисты с 12 лет" ну не знаю, почему именно мамкины :-) Я еще на Highload регулярно выступаю, если погуглите, видео много. И еще на хабр опубликовал почти 60 постов, по ним понятно, что за проекты и где там "миссион-критикал".
"а не вот эти мамкины программисты с 12 лет" ну не знаю, почему именно мамкины :-) Я еще на Highload регулярно выступаю, если погуглите, видео много. И еще на хабр опубликовал почти 60 постов, по ним понятно, что за проекты и где там "миссион-критикал".
Попробую объяснить просто на пальцах. Можно по-разному, гибко, рассказываю от простого к сложному. Компилятор Rust консервативный, иногда перегибает палку и его нужно учиться обходить:
1) "Объекты" создаются обычно в стеке, но могут "взять" себе память в heap.
2) У "объектов", которые "взяли" себе память в heap, обязательно в конце области видимости или в конце их владения (похоже на move-семантику в С++, но безопасная, проверяемая компилятором) вызывается деструктор - компилятором. Компилятор сам вставляет его вызов в бинарку, но в исходниках вызова не видно. По сути похоже на RAII из С++ и по сути такие объекты есть простые smart-pointers (Box).
3) Есть продвинутые "объекты" - smart-pointers, которые не только берут память в heap, но и могут "множится", в т.ч. между потоками и последний такой "объект" удаляет выделенную в heap память. Да, это подсчет ссылок, как и в Swift. Все это проверяется компилятором тоже, безопасно. Это работает с большими издержаками, чем в п.2, поэтому необязательно (Rc, Arc).
4) Можно, через indirection в heap, сделать связанный список, чтобы каждый его элемент был известного для расположения в стеке размер. Так до определенной степени поддерживаются рекурсивные структуры данных типа известного списка "Cons(2):Cons(1)::Null", деревьев и т.п..
5) Когда этого не хватает и нужно больше гибкости, можно динамически связывать "объекты" ссылками в графы через жестко контролируемую компилятором технику внутренней мутабельности (UnsafeCell <- RefCell) и его рантайм контролем ссылок. По умолчанию, ссылки всегда ведут на живые "объекты", может быть одна эксклюзивная (можно менять через нее) или несколько для чтения, но можно это делать динамически и если создашь случайно две эксклюзивные, то программа остановится (контролируемый "крэш" с вызовом деструкторов вверх по стеку - "panic"). Я думаю, это поможет сделать циклические связи в графе "объектов". Не пробовал, если честно.
6) Если не хватило гибкости, всегда есть блок "unsafe", raw-pointers и из них можно что и как угодно собрать, в т.ч. ссылки какие нужны. Может быть придется делать свой локальный сборщик мусора. Но лучше попробовать все способы выше.
Да, вы правы, конечно, я опечатался, спасибо что заметили. Убрал про C, в нем, конечно, нет деструкторов и нужно ручками "free" вызывать.
Про C много читал, разные книги, много исходников смотрел. Про C++ много читал, знаю меньше. На обеих не пришлось писать, к сожалению. Начал больше 20 лет назад сразу на Java.
Я много пишу на Python и искренне увидел, что с такой же скоростью можно решать эти же задачи выразительно на Rust, только ошибок меньше, все имеет тип и код работает на порядок быстрее.
Постараюсь добавить много примеров в последующий постах.
У меня есть русский перевод книги про атомарность Мары Бос (https://www.chitai-gorod.ru/product/rust-atomarnosti-i-blokirovki-3060006). К сожалению, есть ошибки в переводе смысловые, чтобы их понять и в уме исправить приходится некоторые абзацы перечитывать по несколько раз. Вообще предпочитаю читать в оригинале, т.к. технический английский не такой сложный, как литературный.
Отличная статья. Подробный разбор плюсов и минусов в деталях. Да, надо постоянно учиться и комбинировать инструменты. Выбор - за человеком!
Мы BI-конструктор сделали через helm chart. Каждый клиент - установка helm-приложения в кубер. Число подов больше 25к в одном кластере кубера. Ингресс-контроллер заменили с Ingress-nginx на Contour/Envoy, т.к. при 5к виртуальных хостов первый уже не справлялся. Helm тоже перестал справлятся при 15к инсталляций helm-chart, поэтому перешли на Postgres-бекенд для хранения релизов helm там. У нас уже не скучно :-)
Мы на самом деле используем в движке Bitrix BigData библиотеку обратного индекса Lucene.
VK.cloud, это не секрет, мы часто про это рассказываем на конференциях. Таким образом, мы сделали репликацию между двумя крупными облачными провайдерами в России.
Хранение файлов в document root — для простоты, лучшего понимания людьми и удобства использования.
— посмотрите, какой срок поддержки решений в опенсорсе. Что потом? Правильно — серьезно переписывать.
— а зачем это делать, зачем начинать зависеть от стороннего пакета, если нет прямой необходимости? А если пакет перестанут поддерживать, внезапно?
— развивать так же успешно, как и предыдущие 20 лет. Но открытые фреймворки хороши для простых задач, не спорю.
Меня зовут Александр, я работаю в «1С-Битрикс».
Мы изучили ваше замечание. Действительно, эта форма не должна быть обязательной и галочка: «Я ознакомлен и принимаю условия конфиденциальности персональной информации, в том числе в части обработки и использования моих персональных данных» — не нужна.
Наши специалисты сделали ошибку — в ближайшее время мы её устраним.
Спасибо за вашу внимательность!