Если я правильно понимаю посыл доклада и расшифровки, то из Python в Rust собираются выносить вовсе не 2+2 и «Hello, World», а именно ресурсоёмкие CPU bound задачи => «алгоритмы и структуры данных». Причём, вероятно, те, что собираются писать сами (если они есть НЕ на Rust, то Rust, разумеется, теряет ценность).
Именно это я и написал — сначала попробуйте написать на Rust какой-нибудь ваш (или не ваш) алгоритм. Конечно его надо писать не по туториалу tokio.rs (опять смотрим на цель). И да, не исключено что это будет условный «двусвязный список», которого нет.
Я не противник Rust на самом-то деле. Просто написанное в статье показалось через чур оптимистичным.
Хорошая расшифровка. Я бы добавил только обеспокоинов выбирающим Rust. Маловато написано страшных слов про него. В качестве упражнения (если хотите понять что такое Rust вообще) — попробуйте что-нибудь написать на нём. Что-нибудь из алгоритмов вашей предметной области, или просто хоть каких-нибудь алгоритмов. Я когда-то попробовал бинарный поиск с предикатом (generic разумеется). С горы в карьер это заняло у меня дня 2-3 пока оно скомпилилось (точно не помню, сейчас это уже только смутные воспоминания, пробовал в 2016ом). Такой себе learning curve. Злющий. Но написано всё верно — если оно компилится, то падает оно на 99% только в тех местах, где вы сказали ему падать. Это круто.
Какие-то странные у них расчёты. 700млрд минут в кодеке GSM в одном канале занимают 62петабайта. Это примерно в 82 раза меньше чем приведённые цифры. Даже если каналы раздельно положить, чтобы легче было анализировать, получится в 41 раз меньшая цифра. Плюс всякие накладные и СМС — пусть ещё в 4 раза больше. На порядок точно цифры завышены.
В расчётах использовалась константа GSM => 13 kbit/s.
Даже и не думал смущать никого.
Как уже написал чуть ниже — год назад реализовал данный алгоритм для продукта Naumen Phone.
Он по первым нескольким секундам (не 20-30, как шазам) телефонного разговора определяет является ли удалённая сторона шаблонным приветствием какого либо оператора связи (всякие абонент недоступен и тп). Шаблонов и правда немного — несколько десятков. Но работает всё прекрасно. Основное отличие — сравнение «потока частотных характеристик» с шаблоном (а не «фингерпринта») сделано для уменьшения длительности требуемого участка звука.
Код по понятным причинам опубликовать не могу… :)
Описанный алгоритм точно работает. Конечно в шазаме всё сложнее. Но базовый алгоритм именно такой (или как минимум был таким). Я использовал данный подход для автоматического определения стандартных приветствий автоответчиков. На российских операторах мобильной связи работает «на отлично». Преимущественно из-за того, что приветствия голосовых почтовых ящиков изменять нельзя (или никто этого не делает).
Прекрасная статья, спасибо!
Есть одно небольшое замечание — я бы слова «вот этот программист» заменил на что-нибудь более уважительное. Год назад писал библиотеку для распознавания приветствий стандартных автоответчиков операторов связи для продукта Naumen Phone и статья, на которую вы ссылаетесь, буквально howto. И, насколько я могу судить по вашему коду, она вам тоже очень помогла. Не сочтите за «наезд» — просто мнение и очень трепетное отношение к «нетикету»
Кстати «вот этот программист» долго бодался чтобы эта статья не была «выпилена» самим шазамом — можете почитать соседние посты в блоге. Дорогого стоит.
Как же все любят громкие заголовки… К переводчику: как Вы лично думаете — соотносятся ли заголовок и текст данного творения? Есть ли какая-то полезная информация в этом тексте? Я просто коллцентрами занимаюсь уже 15 лет и на мой взгляд это просто в.сер. Печально.
Эх... Говорил нам bobuk, "не ходите в нижний интернет"... Спасибо, я "засыпался" на вашем вопросе. :-)
Проекты Apache: https://en.wikipedia.org/wiki/List_of_Apache_Software_Foundation_projects
Apache: https://ru.wikipedia.org/wiki/Apache_Software_Foundation
Jupyter: https://jupyter.org/ (довольно крупный пример его использования - https://colab.research.google.com/)
Видать такие проекты переводите. Что-то Apache Airflow или Jupyter никто не торопится переводить на C++ (проекты от балды взял, просто из L1 кеша).
Именно это я и написал — сначала попробуйте написать на Rust какой-нибудь ваш (или не ваш) алгоритм. Конечно его надо писать не по туториалу tokio.rs (опять смотрим на цель). И да, не исключено что это будет условный «двусвязный список», которого нет.
Я не противник Rust на самом-то деле. Просто написанное в статье показалось через чур оптимистичным.
В расчётах использовалась константа GSM => 13 kbit/s.
Как уже написал чуть ниже — год назад реализовал данный алгоритм для продукта Naumen Phone.
Он по первым нескольким секундам (не 20-30, как шазам) телефонного разговора определяет является ли удалённая сторона шаблонным приветствием какого либо оператора связи (всякие абонент недоступен и тп). Шаблонов и правда немного — несколько десятков. Но работает всё прекрасно. Основное отличие — сравнение «потока частотных характеристик» с шаблоном (а не «фингерпринта») сделано для уменьшения длительности требуемого участка звука.
Код по понятным причинам опубликовать не могу… :)
Есть одно небольшое замечание — я бы слова «вот этот программист» заменил на что-нибудь более уважительное. Год назад писал библиотеку для распознавания приветствий стандартных автоответчиков операторов связи для продукта Naumen Phone и статья, на которую вы ссылаетесь, буквально howto. И, насколько я могу судить по вашему коду, она вам тоже очень помогла. Не сочтите за «наезд» — просто мнение и очень трепетное отношение к «нетикету»
Кстати «вот этот программист» долго бодался чтобы эта статья не была «выпилена» самим шазамом — можете почитать соседние посты в блоге. Дорогого стоит.