Wan-Derer

Докину 5 коп.

Я думаю что никто такую задачу вобщем-то не ставит. И никогда не поставит. Тут не то что Java
а я прошу прощения Cobol не могут никак заменить. Языку - уде более 50 лет возраста.
И хотя проблема касается в основном США, но это просто пример того что код живет очень долго.
У джунов уже седые бороды отрасли :)

Язык Rust вобщем-то создавалася как язых обще-системного программирования с правильным
механизмом управления памятью. И уже если ему и где-то конкурировать - так это там где нужен
отклик (игры или реал-тайм приложения).

Сильные стороны Java сегодня - это большой репозитарий библиотек на все случаи жизни.
Статистика по maven https://mvnrepository.com/ заявляет что 35 миллионов артифактов
имеется в наличии. Можно наверное найти любой драйвер или парсер или любую
либу поддержки сетевых протоколов. Большая часть из них проверена временем.
Production ready. Можно ли говорить о production-ready для Rust - библиотек я не знаю.
Пускай знающие отпишут.

Java - машина с развитым рантаймом. Рефлексия позволяет делать позднее инстанциирование
компонентов через конфиги. И этим очень сильно пользуются во фреймворках. Фактически
если проводить сравнительные анализы Rust и Java - мы встанем перед дилеммой - чем заменить
механику рефлексии в Rust? Создавать рантайм? Но это противоречит идеям системного программирования
или все таки принять как факт что Spring и ему подобные фреймворки принципиально нельзя
воспроизвести в языке статической компилляции таком как Rust.

Если-бы я сравнивал этот язык (Rust) - то ставил бы ему в одну весовую категорию Nim, Zig и прочие
языки "пост-плюсового" периода. И в качестве задач я-бы ставил - разработку игр и драйверов
для операционок. Вот там и тестируйте.

Самому финтеху не всегда нужен рилтайм. Иногда - даже вообще не нужен. В батч-джобах биг-даты
и python нормально работает. Специфика своя там. А критичные части бигдаты (Apache Arrow, Databricks Photon)
- и так переписаны на сях чтобы быстринько search + join работал. В стриминге биг-даты - тоже вобщем-то
CPU не сильно критичен. Там и Node и C# тоже годится в качестве языков. Вобщем задачи - I/O bounded.

Нужно понимать логику развития языков.

С создавался что бы переносить программы между компами
С++ что бы делать большие программы
Java - что бы не иметь проблем с памятью
C# - Мы поругались с SUN и запилим свою яву с куртизанками и казино (вышло кстати клево)
Rust - ну типа мы для тупых программеров C++ добавим Jail

Вот примерно так. В итоге остается Java и C# это стандарт, типа красной и синей пилюли

Раст же вроде планируется как замена С/С++ и является более низкоуровневым.
Ему прямой путь в системное программирование. А финтех это немного другое

Нет. У них разные области применения. Java проектировалась именно как предельно простой и лёгкий для восприятия язык, максимально препятствующий выстрелу в ногу. Никогда этим параметрам не будет соответствовать язык одновременно пригодный к системному программированию. И это не учитывая тот фактор, что инвестиции в переписывание всего финтеха с Java на Rust потребуются больше, чем планетарный ВВП.

На Java пишется очень много разных вещей, в тч не требовательных к утилизации ресурсов и задержкам так что предположу, что многие вещи просто нецелесообразно переписывать.

Кроме Java в финтехе вообще много разных языков используется. Даже такая экзотика как Haskell и F# бывает.

Могу сказать, что сейчас работаю в большой корпорации и мы как раз пишем на Rust штуки, которые отвечают за работу с платёжными системами.

Раньше примерно то же самое писалось на плюсах.

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

На сколько я знаю, на сегодняшний день у раста проблемы с интеграциями. Брошеные либы, зависимости от версии и платформы и вот это все... (я рад бы ошибаться, возможно, г-н Василий Банников меня поправит).
В джаве же есть спринг-бут, который умеет интегрировться хоть с чертом лысым, при этом поддерживается, развивается, выходят новые версиии...
В большом энтерпрайзе это важно.

Ну и у джавы, нерешаемых проблем довольно мало, чтобы от нее отказываться. На рынке есть много персонала разной квалификации, JVM - прекрасная, развивающяяся платформа.
На расте же писать никто не умеет (по сравнению с джавой), не понятно какие у технологии перспективы, есть вышеуказанные проблемы. Чем он может заинтересоваться большой бизнес?
Производительностью? Так и jvm достаточно производительна, во-первых, а во вторых, есть куча приложений, для которых никакой хай-лоад и никакое лоу-латенси не предусмотренно...

Вот такой вариант playground

type Coord =`${number}.${number}`;
type Zipcode =`${number}-${number}`;

let a: Coord = '-3.3' // ok
let b: Coord  = "-81." // error
let c: Coord  = "123.00" // ok

let d: Zipcode = '4565' // error
let e: Zipcode = '4565-' // error
let f: Zipcode = '4565-2' // ok
let g: Zipcode = '4565-2-2' // error

Сайт блокируется провайдером, либо вышестоящим провайдером. Вот и всё. Куда бежать - хз даже, раз его в списках нету...
tracert явно показывает на 1 моем провайдере - блокировку на последнем из шлюзов(ДО вышестоящего, видимо ТСПУ стоит)
на втором провайдере блокировка идет через вышестоящего - РТ ))

Кстати - через впн, даже с российких хостингов - работает. Например с таймвеба с локаций СПБ и новосиб... и со сберовского тоже)

Первое скинь ссылку на курс просто интересно.

По теме:

Полетный контроллер по сути тупой автомат имеющий на входе
* GPS
* датчик положения
* возможно датчик скорости

Пишется он на С причем это хардкорный С без этих ваших memoryallocation
Как правило используется либо самописная система либо RTOS с адаптацией под задачи

Итак что имеем верхнее ограничение сервомашинки 20 Мс - 500 раз в секунду ( на самом деле от 20 до 200)
GPS - 10 -20 раз в секунду
В этих пределах и молотит полетный контроллер, он намеренно сделан сильно тупым что бы отрабатывать очень быстро. Все остальные системы это приятные дополнения.
Поиграться и не только можно скачав https://pixhawk.org/

Отдельный вопрос это главные контроллеры. Тут языки высокого уровня, часто с использованием CUDA

Пример для моторов квадрокоптера на Матлабе.

Дополню коллег выше. Еще неплохо бы изучить теорию бесплатформенных навигационных систем. Это основной датчик для БПЛА(хотя наверняка на тяжелых могут стоять и платформенные НС). Это затрагивает, хоть и чуток, теория гироскопов и акселерометров.

В вашей задаче все определит какой именно нужно делать анализ

Съем показаний, их запись и простой анализ должны происходить за 1 секунду.

Если я верно понимаю, анализ происходит со всеми собранными данными за период, значит и хранить их можно этими методами (вручную по таблицам или автоматически), получается единственная индекс тут только время.

Хранить записи агригированно, т.е. скопом по факту записи, например если анализ проводит не средствами базы данных а снаружи то и хранить не обязательно по полям на значение, на этом можно очень хорошо сэкономить. Например можно писать данные бинарным блобом именно так как они приходят от датчиков. База данных в этом походе будет отвечать только за хранение и будет способна принимать гигабайты данных в секунду, сколько там чисел в запросе будет уже не важно

Кстати полный или частичный анализ можно проводить фоном, параллельным процессом или несколькими (у меня была задача где данные собирались одним машинами, а обрабатывались другими, с некоторым лагом)

P.s. и кстати, не важно какая база данных хоть файлы, все решить алгоритм анализа

Проблемы интенсивных нагрузок обычно решают комплексно. Не только выбором подходящих СУБД, брокеров и т.п., но и архитектурно. Например Tesla используют Akka Cluster Sharding для работы с сенсорами своих авто, а работу с базой организовали через event sourcing, так что база данных у них не очень сильно нагружена, несмотря на миллионы запросов в секунду.

Успех мероприятия будет зависеть от двух факторов.
1) Успеете ли вы грузить трафик? Тут я думаю будет все ОК при использовании TimeSeriesDB.
2) Успеете ли вы делать их анализ? И что за анализ? Нужно ли вам для анализа видеть консистентность
между всех приборов? Что за сложные типы данных? Как они будут участвовать в запросе.

Передавать-то на Wi-Fi частоте ты может и сможешь... а вот как телефон спутнику отвечать будет? Антенну и батарейки придётся в рюкзаке носить. =)