"а не вот эти мамкины программисты с 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.
Мы изучили ваше замечание. Действительно, эта форма не должна быть обязательной и галочка: «Я ознакомлен и принимаю условия конфиденциальности персональной информации, в том числе в части обработки и использования моих персональных данных» — не нужна.
Наши специалисты сделали ошибку — в ближайшее время мы её устраним.
Спасибо за пост, очень интересно и полезно.
"а не вот эти мамкины программисты с 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С-Битрикс».
Мы изучили ваше замечание. Действительно, эта форма не должна быть обязательной и галочка: «Я ознакомлен и принимаю условия конфиденциальности персональной информации, в том числе в части обработки и использования моих персональных данных» — не нужна.
Наши специалисты сделали ошибку — в ближайшее время мы её устраним.
Спасибо за вашу внимательность!
Внимательно прочли вашу статью.
Обновление «1С: Синхронизация Битрикс24 для Управление торговлей для» (Беларусь, редакция 3.4) было выпущено и размещено в открытом доступе 14 января.
Скачать его вы можете тут: 1c.1c-bitrix.ru/intranet/download.php?section=105303.
Всем клиентам продукта были отправлены уведомления в чаты.
Искренне сожалеем о негативном опыте, вообще, мы стараемся выпускать обновления максимально оперативно, насколько это возможно.
С уважением, команда «1С-Битрикс».