> I think it needs more time and the RFC text needs more work to explain the > basic difference.
I do not mind, but no one is writing anything. (El coronel no tiene quien le escriba :)) > I think it also need to have a good implementation for what is being proposed > to have any chance because there are often voters that will vote down just > because there is no implementation that can be reviewed. > Basically everything that can be addressed should be addressed before the > vote so it's just decisions between the actual approach. Perhaps, but no one has said that the current implementation is bad or needs to be replaced. I mean that so far no one except you has said this. It seems to me that no one except a few people has actually looked at the implementation. I am almost certain of that. There has never been a conversation like “Yes, this RFC is fine, but it needs a different implementation.” > I think this is more that some people clearly prefer coloring and want to > point out the potential issues with this approach. If someone in this discussion had actually written about the real issue of not having colored functions, it would have been great and extremely useful. No one did. Most people simply have not encountered these problems. Colored functions sometimes help localize errors related to global state. Not always, but sometimes. But there is also the opposite situation. The tragedy of the Python async migration which slows down the adoption of async in Python. Speaking more seriously, colored functions are more useful for low-level languages. For high-level languages, the absence of colored functions and full commitment to asynchronous code is actually more beneficial. Languages that follow this path, like Go, have succeeded. Why is that? Because high-level languages can hide contracts. Low-level languages have the opposite requirement: they need to know every contract explicitly. This happens because increasing abstraction relies on hiding details. > That's why I think it might help to have dedicated section about coloring > (more comparison with the current approach) in the RFC. In the early versions there was similar text, but I removed it so it wouldn’t overload the RFC. But in short, the absence of colored functions simply saves time. ---- Best Regards, Ed
