3 ms·
It's not that Python always wins but that it wins in the context of a work environment with deadlines and other constraints. If you make time outside of that e
by Dowwie 8y ago
It's not that Python always wins but that it wins in the context of a work environment with deadlines and other constraints. If you make time outside of that environment for learning Rust, you can give yourself permission to develop new competencies without losing the productivity argument.
- StavrosK 8y agoIt's a personal argument, I get frustrated and lose motivation when I have an idea I want to create and it takes way too long... Especially when I think "with python, it would have been done by now".
- Dowwie 8y agoBroaden your scorecard. Time to completion is only one measure (although it is a very important one in many scenarios). You can email me if you want to explore Rust for your work or interests. I have a Python background, too, and have open sourced work.
- StavrosK 8y agoThanks, I might! The "time to completion" metric is important for my continued enjoyment, mostly, as I get frustrated otherwise.
- orzig 8y agoAlso the "bus number" consideration - companies are (reasonably) wary to add things to their codebase that only one developer knows how to maintain. Getting a group of devs to commit to >6mo learning Rust could kickstart a real change. There needs to be critical mass.
- Dowwie 8y agoKey man risk is a real challenge. No doubt. Python wasn't always so popular. There was a time when Java was safer for resourcing and Python was risky. What did managers do, if anything, to manage the risk that their sole Python programmer would one day likely leave?