Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Rust сам по себе весьма хорош как язык. Но по поводу создания и поддержки в рабочем состоянии библиотек (уровня Boost.Beast из С++) возникло ощущение, что в мире раста этим занимаются полтора энтузиаста. А это весьма чревато.
«Мы приняли Rust ради безопасности и видим 1000-кратное снижение плотности memory-safety уязвимостей по сравнению с C и C++ кодом Android. Но самым большим сюрпризом стало влияние Rust на доставку ПО. Rust-изменения имеют в 4 раза меньший rollback rate и тратят на 25% меньше времени в code review — безопасный путь оказался ещё и быстрым» — это слова Джеффа Вандер Стопа из Google.
https://blog.google/security/rust-in-android-move-fast-fix-things/
ощущение ошибочное. Новый код в Linux и Android пишется на Rust, а критичные по безопасности модули в Android точечно переписываются
«Мы приняли Rust ради безопасности и видим 1000-кратное снижение плотности memory-safety уязвимостей по сравнению с C и C++ кодом Android. Но самым большим сюрпризом стало влияние Rust на доставку ПО. Rust-изменения имеют в 4 раза меньший rollback rate и тратят на 25% меньше времени в code review — безопасный путь оказался ещё и быстрым» — это слова Джеффа Вандер Стопа из Google.
Возможно вы и правы. ИИ пишет что мне нужны tokio и reqwest, которые "абсолютно защищены от проблемы выгорания разработчиков".
Тем не менее, пока подожду записываться в растоманы)
Увы, на стандартных таймфреймах этого сделать нельзя из-за разной плотности времени.
А в данной задаче это и не нужно. М1 - это основной ТФ в МТ5. Остальные ТФ являются синтетическими от него.
В МТ5 вы загружаете историю только М1(!!!), остальные ТФ рассчитываются в терминале от М1. В МТ4 загружаются все ТФ.
Не важно, что интуитивно понятно трейдеру. Главное, чтобы советник был бесконфликтным. А M1, M4, M16, M64, M256, M1024, M4096 дают эту бесконфликтность за счет одинаковой равномерности плотности времени на разных масштабах.
Да, я понимаю, и именно поэтому я назвал этот метод элегантным. Но только с точки зрения разработчика. А не с точки зрения пользователя, по моему скромному мнению.
У меня была идея увеличить масштаб свечей, чтобы показать другие стандартные таймфреймы, сохранив при этом состояние пользовательской отрисовки, индикаторов и т.д. Проще говоря, при увеличении масштаба вы видите свои оригинальные индикаторы и рисунки на других стандартных таймфреймах. Вы правильно заметили, что стандартные таймфреймы не позволяют этого сделать из-за уникальной плотности времени, и это именно то, что я пытаюсь решить. Я думаю, что чистый ZUI не будет работать с этим, мне, вероятно, нужна золотая середина, больше похожая на переход, чем на непрерывное масштабирование, что делает это очень реалистичным, но философски другим...
Это ощущение ошибочно. Новый код в Linux и Android пишется на Rust, а критически важные для безопасности модули в Android точечно переписываются
"Мы приняли Rust ради безопасности и увидели 1000-кратное снижение плотности уязвимостей безопасности памяти по сравнению с кодом Android на C и C++. Но самым большим сюрпризом стало влияние Rust на доставку программного обеспечения. Изменения на Rust имеют в 4 раза меньший процент откатов и на 25 % меньше времени тратится на проверку кода - безопасный путь был также быстрым" - это слова Джеффа Вандер Ступа из Google.
https://blog.google/security/rust-in-android-move-fast-fix-things/
Да, я понимаю, и именно поэтому я назвал этот метод элегантным. Но только с точки зрения разработчика. А не с точки зрения пользователя, по моему скромному мнению.
У меня была идея увеличить масштаб свечей, чтобы показать другие стандартные таймфреймы, сохранив при этом состояние пользовательской отрисовки, индикаторов и т.д. Проще говоря, при увеличении масштаба вы видите свои оригинальные индикаторы и рисунки на других стандартных таймфреймах. Вы правильно заметили, что стандартные таймфреймы не позволяют этого сделать из-за уникальной плотности времени, и это именно то, что я пытаюсь решить. Я думаю, что чистый ZUI не будет работать с этим, мне, вероятно, нужна золотая середина, больше похожая на переход, чем на непрерывное масштабирование, что делает это очень реалистичным, но философски другим...
это более простая задача, чем та, что я реализовал в плавном динамическом таймфрейме. Я даже где-то видел нечто подобное. Или даже сам реализовал нечто подобное.
Николай, а как давно Вы изучаете Rust? Я тоже все смотрю в его сторону, но пока дальше смотрения дело не идет. Останавливает то, что у меня нет задач по него, разве что Solana. И интересно, какой идешкой Вы пользуетесь, если не секрет. Спасибо.
VS Code
Хаха. Смотреть в сторону - это как раз то, что нужно в наше стреметельно меняющееся время.
Все больше реально работающих программистов говорят мне, что за последнее время не написали ни одной строчки кода.
Время меняется в области программирования меняются стремительно.
Да, пока мы ограничены контекстом в 1 млн токенов, скилы программирования все еще остаются актуальными.
Но когда размер контекста увеличится до десятка или десятков млн токенов, у меня такое ощущение, что скилы программирования уже станут не актуальны.
Увы, это грустно осознавать, так как я кайфую от процесса программирования. Но это реалии.
Землекопатели уже больше не нужны, так как экскаватор уже изобретен и его производство идет полным ходом.
Поэтому в наше время главной ценностью становится горизонтальные знания и креативные способности генерировать новое.
Понимание основных векторов знаний во всех областях ИТ. Это очень длинный многомерный список знаний. Но важно понимать что у МО под капотом, облачные концепции масштабирования, оркестрации, автоматизации и многое другое.
Причем глубина в одной узкой области уже не дает того преимущества, что давала еще пять лет назад. ИИ закрывает любую вертикальную яму быстрее и точнее, чем самый опытный специалист. А вот связать пять разных областей в одну работающую систему, увидеть неочевидную аналогию между концепциями из разных миров, поставить правильный вопрос там, где другие не видят даже проблемы — это пока остается за человеком. И именно за это сейчас платят.
Поэтому мой совет тем, кто в замешательстве: не пытайтесь догнать узких специалистов в их вертикалях. Эта гонка уже проиграна. Вместо этого учитесь видеть систему целиком. Понимать, как трансформер устроен изнутри, чтобы знать, где он сломается. Знать, почему Kubernetes именно такой, а не другой, и где его как раз не нужно. Понимать разницу между CAP и BASE, чтобы выбирать правильный инструмент. Чувствовать, когда вам нужен Rust с его zero-cost абстракциями, а когда хватит Python со скриптом на коленке. Это и есть та горизонтальная карта, которая делает программиста сегодня ценным.
Вторая ценность — умение четко формулировать. ИИ — это зеркало вашего мышления. Если вы не можете объяснить задачу человеку, вы не объясните ее и модели. Хорошие промпты — это просто хорошо поставленные технические задания, переведенные в нужный регистр. Кто умел писать ТЗ — тот выигрывает. Кто умел только закрывать тикеты — тот в группе риска.
Третье — критическая оценка результата. ИИ галлюцинирует, льстит пользователю, идет по пути наименьшего сопротивления. Без понимания, как должно работать на самом деле, вы получите красивый код, который тихо ломается в проде через две недели. Вот здесь-то и нужны те самые базовые знания: алгоритмы, структуры данных, понимание сложности, чувство архитектуры, представление о том, как работает память, сеть, файловая система. Не для того, чтобы писать байт-перфектный код руками — а для того, чтобы в каждый конкретный момент понимать, врет ли вам сейчас модель или нет. Без этой базы вы превращаетесь в курьера между ИИ и компилятором, и ваша цена на рынке стремится к нулю.
Что касается вашего интереса к Rust — это абсолютно правильный взгляд, и я вас полностью понимаю. Не нужно изучать его как самоцель. Нужно понимать его место в экосистеме: туда, где Python тормозит, где C небезопасен, где Go недостаточно выразителен, где JVM слишком прожорлива по памяти. Solana — отличный повод, тем более что весь современный блокчейн-стек смотрит в сторону Rust именно из-за memory safety без сборщика мусора. Но даже если конкретной задачи нет — поиграйте пару выходных с Bevy или с каким-нибудь embedded на ESP32. Когда вы прочувствуете идиоматику borrow checker, вы поймете, куда вообще эволюционируют языки в ближайшие десять лет. Это вложение не в Rust, это вложение в понимание трендов.
И главное — не бойтесь, что кайф от программирования уходит. Он не уходит. Он смещается. Раньше кайф был в том, чтобы написать алгоритм. Теперь кайф в том, чтобы спроектировать систему, в которой пять агентов друг с другом разговаривают, и оно работает. Это другой уровень удовольствия — на порядок выше. Землекопатель грустит, что его лопата лежит в гараже. Но прораб, который управляет десятью экскаваторами одновременно — он-то строит города, а не копает ямы. Вопрос только в том, кем вы захотите стать в этой новой стройке.
Какое это имеет отношение к "Canvas - это круто"?
//---
Никто не против такого обсуждения, я думаю. Но нужно подумать, куда его перенести чтобы это не был откровенный оффтопик.
@Ivan Butko удалил свой комментарий наверное из-за того, что понял, что это оффтопик. Дубликат комментария все еще доступен здесь.
Я не хочу душить обсуждение. Я предлагаю перенести его.
Да, это формально оффтоп и вышло за тему моей ветки.
Но все очень взаимосвязано. Пытаться классифицировать посты по темам веткам и переностить их туда создадут только хаос.
Важно понять, почему я в свое время вообще занялся Canvas. Это была вынужденная мера. Я начал создавать сложные алгоритмы, которые требовали поэтапной проверки через визуализацию процессов и массивов данных — чтобы видеть, что иду в правильном направлении и не допустил ошибку на каком-то шаге. А штатных возможностей визуализации в MT5 для этого не хватало. Именно поэтому пришлось прокачивать скилы в этом направлении. Мое текущее знание технологий Canvas — это побочный эффект исследовательской работы, а не самоцель.
Визуализация на Rust — звено той же цепи. Обсуждение ИИ — её логичное продолжение, потому что современная разработка сложных алгоритмов уже неотделима от вопроса, какими инструментами мы пользуемся и куда они движутся. Для меня все эти темы — части одной исследовательской траектории, и они естественно перетекают одна в другую.