Это уже 27я версия бота (26 бэкапов держу).

Михаил, да, об этом читал, но пока не применял Пометил себе на будущее попробовать использовать.

СПАСИБО!

Михаил, ну вот о том и речь, разрабер такой и был (не тот, который друг, а тот который дальше мне проект развивал): ушлый и не великих скиллов, получается. Много считать мне наверное не понадобится, по крайней мере в боте. А вот в бэктесте (БТ)… Там сплошь расчеты. БТ на питоне работает у меня сейчас, но тоже медленно.

Пример: рассчитываю один торговый набор по одному тикеру в одном БэкТесте, с разными тейками и стопами и разными параметрами входа просчитываю таймфрейм и тикер. Это примерно 15000 сетапов для расчета (бывает и больше). А главная задача бэктесту — это разбирать свечи на более мелкие и смотреть где точно был вход, что случилось раньше тейк или стоп, время в сделке, просадки до тейка и т.д… Там много ценного можно увидеть.

Так вот: считаем всю историю какого нибудь LINK, это 3 года и 9.5 месяцев, сделок примерно 150 (±). Один сетап и 15000 рассчитывается сильно по-разному, зависит от конфигурации компа напрямую!
1) на core i3-13XXX один сетап считается около 20 секунд, и расчет не тупит пока нагрузка не превышает запущенных задач до 3 шт., дальше 100% загруз и замедляет частоты.
2) на core i7-13XXX уже 12 секунд на тот же сетап и задачек можно запустить до 7-8 штук без потери времени на каждую. Ну то есть они конечно суммируются, и при 7 запущенных бэктестах сетап считается не 12 секунд, а примерно 80 сек., но так как их запущено 7, то на 1 получается примерно то же самое.
3) а вот на камне i9-14900 один сетап считается уже за 9 секунд, а не за 12, и нагрузку камень тянет в 13 задач!

Это то, на чем я уже считал и фиксировал быстродействие. Горизонты обсчета параметров можно сильно расширить.

Как будет на Go — не знаю. БТ в планах пока. Может скормить код ИИшке и попросить переделать его в многопоточный режим? Посмотрим. Пока я ботом занят. Ну вот… Примерно так. Спасибо за добрые слова!

Михаил, спасибо вам за добрые слова!

Благодарен Вам за желание помочь, правда, но все же тут без погружения в нюансы бота помочь не получится — а их много, бот не простой.

Подытожим: я сам пайтон не писал, мне на пайтоне код писал другой программист. Я тестировал. Написано монолитом, файлы бота огромные и трудночитаемые, по 900-1200 строк. Все последовательно, даже свечи загружаются последовательно, один тикер за другим, баз данных там нет, все в RAM, именно по этому при 2 и более сетапах на одном тикере возникают долгие задержки и даже ошибки логики. но там отдельная песня, продолжу по теме.

Для сравнения, на Го сейчас уже параллельно все тикеры в базу залетают, на 5-летней истории часовики например (а это порядка 45 тыс. свечей на тикер) залетают около 20 секунд включая запросы и запись в SQL параллельно! А там на 10 сетапах сбор составляет 4-5 минут. Это раз.

Дописывание часовиков в реалтайме происходит менее секунды в записью а базу, на пайтоне разработчик меня лечил что биржа долго отдает свечу, поэтому только через 10 секунд ордер ставится, а мог ставится через 1 секунду. 

Далее: при торговле, в пайтоне используется конфиг.пай, там мы прописываем все параметры торговой системы и торгуем например 10 тикеров. Пайтон идет последовательно по коду конфига, опрашивая один сетап за другим, проверяя позиции, следя за ценой, раскидывая ордеры (а вход там стоп-лимитами, иначе математика ТС «поедет»), и проход по одному конфигу (для 10 сетапов) занимает около минуты! Минута, «Карл»! Частенько возникали ситуации, когда цена была рядом — она могла и убегала от ентри поинта, приходилось покупать маркетами, иначе пропуски входов… В общем проблемы, проблемы, проблемы… Именно из-за быстродействия. Я решал это всё примерно год, но в итоге все заканчивалось фразой разработчика «сделаю в несколько потоков, дай денег». Объяснять думаю не надо, как дальше наглели разработчики.

Го может параллельно разными рутинами все это делать. На агрегаторе торговых ТФ я уже убедился как это быстро может работать и уже (!) работает. Часть параметров слушаем вебсокетом, позициями управляем через REST API. и так далее. 

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

Ладно, думаю — понятно. Дальше расписывать не буду. Быстродействие кода во главе угла. И спасибо за помощь, еще раз.  

Михаил, а вы посмотрите внимательно на картинку с командной строкой и командами SQL, там видно какие свечи собираются (по продолжительности) и из каких они собираются. И почему собираются такие нестандартные интервалы… У меня очень не банальная система и очень нестандартная логика бота. Вот её и предстоит реализовать. Это все подготовка, тут еще даже условия входа не начал прописывать. Впереди много труда.

А сетапов у меня в интерфейсе будет примерно 50 (это когда я буду уверен что логика бота работает хорошо — пока я не дошел до этого). Пайтон на 10 уже опухал в плане отправки ордеров, опроса позиций, слежкой за ценой, а когда добавили сетку… вообще туши свет. Скорость как на бейсике.
А еще представьте у меня на одном и том же тикере одновременно торгуется 3-4 разных торговых сетапа с разными условиями. Если вы со стороны посмотрите что бот там делает с ордерами — вам это покажется вовсе каким-то мракобесием! но тем не менее. Поверьте в торговых системах я далеко ушел и обсчитывать их научился давно. Это вовсе не то, чтобы гадать куда пойдет цена.

Зачем вам в это вникать? Я то одну и ту же задачу реализую на другом языке по той же логике, и уже вижу разницу, даже на этапе параллельного сбора данных и их агрегации — все делается сразу, есть только небольшие вопросы над усилением конфигурации сервера. Смысл спорить с этим?

Михаил, мне трудно спорить, я начинающий совсем. Да и зачем об этом спорить, холивары программеров давно известны. Выбор языка это же ВЫБОР, вот я и выбрал Go. Скорость ОЧЕНЬ важна. На Питоне мне писали, результат очень слабый по скорости. На Rust писать сильно сложнее, сказали опытные ребята, вообще не лезь в это. Плюсы — тем более. Предлагали еще C#, тоже хороший и быстрый язык, но я выбрал Go, dot.Net может потом, если понадобится. Так и сказали, если надо быстро и многопоточно, то по скорости после плюсов и раста — только Go. Я уже вижу как летает Go в агрегации свечей параллельно в 10 потоков — это раз в 20 быстрее, чем делал код на питоне. Может быть его так написали, возможно. Не вижу смысла дальше обсуждать, думаю вопрос можно закрыть. И я — не компания, я сам по себе, пока что.

P.S. Упомянутый вами комментарий являлся ответом про зарплаты программистов в компании, а не про то, лучше go или хуже. Зарплаты программистов мне не актуальны пока.