Я не могу этим не поделиться
Недавно я делал внутреннюю тулзу, для которой хотелось запускать питон код
Я решил попробовать сделать это не с помощью процессов, а запускать питон прям в этом же процессе (язык для скриптов же все дела) (плюс можно было шерить память за очень быстро)
Для раста есть прекрасная либа под названием pyo3 (а еще там же есть биндинги numpy)

И мне надо было сделать datetime numpy array (массив дат)
Ну я и пишу какой-то код аля

PyArray1::<PyDateTime>::from_iter(dates...);

И что бы вы думали

1. Компилятор(!) знал и понял, что PyDateTime нельзя пихать в numpy array
2. Но он не только сказал, что нельзя, но написал мне ошибку со скрина

А именно, он мне сказал:
"PyDateTime" нельзя сувать в numpy array, но есть несколько других типов, которые можно, например numpy::DateTime

Оказывается, что у нампая свой тип дат (что логично, вместо всей структуры с полями типа year, month, day и т.д., там просто хранится timestamp)
И если я хочу быстро, то мне нужно использовать его.

И УЗНАЛ Я ОБ ЭТОМ НЕ ИЗ РАНТАЙМ ОШИБКИ, НЕ ИЗ ГУГЛА, А ОТ КОМПИЛЯТОРА
АААААААА

К слову, часто раст рекламируют как "memory safety", но на самом деле его система типов позволяет делать намного больше, как, например, тут, правильно описывать апи вообще другого языка.
Помимо этого, мой экспириенс с питоном в расте был мега приятный. Я не знал, можно ли в структурах, которые будут экспортироваться в питон, использовать обычные типы из раста (условно, нужно ли использовать PyString, или можно String), и вместо того, чтобы гуглить, безопасно ли это, можно ли так, я просто писал такой код, и он компилировался, и я был уверен, что так можно (и да, все ок)
И такого рода вещей было очень много. Я глядел совсем чутка на то, как это делается в плюсах, и понял, что там просто UB на UB (C api все таки), и был в шоке, наскольно приятно это делается тут.

В общем, это довольно хороший пример большой библиотеки с кучей сложных вещей, которая при этом позволяет добиваться того самого волшебного момента "компилируется - значит работает"