Canvas is cool! - page 106
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Rust itself is very good as a language. But regarding the creation and maintenance of libraries (of Boost.Beast level from C++), I have a feeling that in the world of Rust it is done by one and a half enthusiasts. And this is very fraught.
"We adopted Rust for the sake of security and see a 1000-fold reduction in the density of memory-safety vulnerabilities compared to Android's C and C++ code. But the biggest surprise was the impact of Rust on software delivery. Rust changes have 4 times lower rollback rate and spend 25% less time in code review - the secure path was also fast" - these are the words of Jeff Vander Stoop from Google.
https://blog.google/security/rust-in-android-move-fast-fix-things/
the perception is wrong. New code in Linux and Android is written in Rust, while security-critical modules in Android are point-by-point rewritten
"We adopted Rust for security and see a 1000x reduction in memory-safety vulnerability density compared to Android's C and C++ code. But the biggest surprise was the impact of Rust on software delivery. Rust changes have 4 times lower rollback rate and spend 25% less time in code review - the secure path was also fast" - these are the words of Jeff Vander Stoop from Google.
You may be right. AI writes that I need tokio and reqwest, which are "absolutely immune to the problem of developer burnout".
Nevertheless, I'll wait to sign up as a rastomancer for now)
alas, you can't do that on standard timeframes due to the different time densities.
And there is no need for that in this task. M1 is the main TF in MT5. Other TFs are synthetic from it.
In MT5 you load the history of only M1(!!!), other TFs are calculated in the terminal from M1. In MT4, all TFs are loaded.
It does not matter what is intuitive for a trader. The main thing is that EA is conflict-free. And M1, M4, M16, M64, M256, M1024, M4096 give this conflict-free due to the same uniformity of time density on different scales.
Yes I understand, and that's why I described this method as elegant. But only from the developer's perspective. Not from the user's point of view, in my humble opinion.
I had the idea of candlesticks being zoomed in to show other standard timeframes WHILE maintaining the state of user's drawing, indicators etc. In simple words, you see your original indicators and drawings on other standard timeframes as you zoom in further. You bring a good point that the standard timeframes can't allow you to do it because of unique time densities, and that's precisely what I am trying to tackle. I guess pure ZUI won't work with this, I probably need a middle ground, more like a transition than a continuous zoom, which makes this very feasible but philosophically different..
The feeling is wrong. New code in Linux and Android is written in Rust, and security-critical modules in Android are point-by-point rewritten
"We adopted Rust for the sake of security and see a 1000-fold reduction in the density of memory-safety vulnerabilities compared to Android's C and C++ code. But the biggest surprise was the impact of Rust on software delivery. Rust changes have 4 times lower rollback rate and spend 25% less time in code review - the secure path was also fast" - these are the words of Jeff Vander Stoop from Google.
https://blog.google/security/rust-in-android-move-fast-fix-things/
Yes, I understand, and that's why I called this method elegant. But only from the developer's point of view. Not from the user's point of view, in my humble opinion.
I had the idea of zooming in on candlesticks to show other standard timeframes while preserving the state of custom rendering, indicators, etc. Simply put, when you zoom in, you see your original indicators and drawings on other standard timeframes. You correctly pointed out that the standard timeframes don't allow this due to the unique time density, and that's exactly what I'm trying to solve. I don't think a pure ZUI would work with this, I probably need a golden mean that is more like a transition than continuous zooming, which makes it very realistic but philosophically different...
it's a simpler task than what I've implemented in a smooth dynamic timeframe. I've even seen something like this somewhere. Or even implemented something similar myself.