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.
VS Code
Haha. Looking away is just what we need in our rapidly changing times.
More and more real working programmers tell me that they haven't written a single line of code lately.
Times are changing and programming fields are changing rapidly.
Yes, as long as we are limited by a context of 1 million tokens, programming skills are still relevant.
But when the context size increases to tens or tens of millions of tokens, I have a feeling that programming skills will become irrelevant.
Alas, this is sad to realise, as I get high from the programming process. But these are realities.
Diggers are no longer needed, as the excavator has already been invented and its production is in full swing.
That is why horizontal knowledge and creative abilities to generate new things become the main value nowadays.
Understanding the main vectors of knowledge in all areas of IT. This is a very long multi-dimensional list of knowledge. But it is important to understand what the MoD has under the bonnet, cloud concepts of scaling, orchestration, automation and more.
And depth in one narrow area no longer provides the advantage that it did even five years ago. AI closes any vertical hole faster and more accurately than the most experienced specialist. But linking five different fields into one working system, seeing an unobvious analogy between concepts from different worlds, putting the right question where others can't even see the problem - that's still left to humans. And that's what it pays to do now.
So my advice to those who are confused: don't try to catch up with the narrow specialists in their verticals. That race is already lost. Instead, learn to see the whole system. Understand how Transformer is built from the inside out so you know where it will break. Know why Kubernetes is the way it is and not the other way round, and where it just doesn't need to be. To understand the difference between CAP and BASE so you can choose the right tool. To feel when you need Rust with its zero-cost abstractions and when Python with a script on your lap will suffice. This is the horizontal map that makes a programmer valuable today.
The second value is the ability to articulate. AI is a mirror of your thinking. If you can't explain a task to a human, you won't explain it to a model either. Good prompts are simply well-worded TORs translated into the right case. Whoever knew how to write TORs wins. Those who only knew how to close tickets are at risk.
The third is critical evaluation of the result. AI hallucinates, flatters the user, takes the path of least resistance. Without understanding how it should work in reality, you will get a beautiful code that quietly breaks in a fortnight. This is where you need the very basic knowledge: algorithms, data structures, understanding of complexity, a sense of architecture, an idea of how memory, network, file system work. Not to write byte-perfect code by hand - but to understand at each particular moment whether the model is lying to you now or not. Without this base, you become a courier between the AI and the compiler, and your value in the market tends to zero.
As for your interest in Rust - that's absolutely the right view, and I totally understand you. You don't need to study it as an end in itself. You need to understand its place in the ecosystem: where Python slows down, where C is insecure, where Go is not expressive enough, where the JVM is too memory-hungry. Solana is a great reason, especially since the entire modern blockchain stack is looking towards Rust precisely because of memory safety without a rubbish collector. But even if there is no specific task - play a couple of weekends with Bevy or some embedded on ESP32. When you get a feel for the idiom of the borrow checker, you'll realise where languages in general will evolve in the next ten years. It's not an investment in Rust, it's an investment in understanding trends.
And most importantly, don't be afraid that the thrill of programming is going away. It's not going away. It's shifting. The thrill used to be in writing an algorithm. Now the thrill is to design a system where five agents talk to each other and it works. It's a different level of fun - an order of magnitude higher. The digger is sad that his shovel is lying in the garage. But the foreman who runs ten excavators at once - he's building cities, not digging holes. The only question is who you want to be in this new construction site.
What does this have to do with "Canvas is cool"?
//---
I don't think anyone's against such a discussion. But we need to think about where to move it so it doesn't become completely off-topic.
@Ivan Butko deleted his comment, probably because he realized it was off-topic. A duplicate comment is still available here .
I don't want to stifle the discussion. I suggest we postpone it.
Yes, this is technically off-topic, and we've gone off-topic in my discussion thread.
But everything is highly interconnected. Trying to categorize messages by topic and move them there will only lead to chaos.
It's important to understand why I became interested in Canvas in the first place. It was an obsession. I started creating complex algorithms that required step-by-step verification through visualization of processes and data arrays—to ensure I was moving in the right direction and hadn't made a mistake at any stage. But MT5's standard visualization capabilities weren't enough for this. So I had to improve my skills in this area. My current knowledge of Canvas technology is a byproduct of my research, not an end in itself.
Visualization in Rust is a link in the same chain. Discussing AI is a logical continuation of this topic, as the modern development of complex algorithms is no longer separate from the question of what tools we use and where they are heading. For me, all these topics are part of a single research trajectory and naturally flow into one another.