DataDaoDe

> Probably in time to come Rust will be used for some core library development which brings substantial benefits like scipy, not something rewritten as wrapper around C library with unsafe code which can be done with Python much better.

I think a nice situation would be to have all the core scientific libraries and tools written in rust with clean APIs, independent of any particular scripting language but with the clear goal of providing a clean API to wrapper languages. Then any scripting language can wrap these libs and go - essentially something like a universal numpy/scipy/scikit, etc. This would mean Ruby/Python/JavaScript/Julia, etc. would all be able to get to state of the art immediately while minimizing the duplication of effort across languages and creating a standard "ML" or "Scientific" API.

You can have your opinion, but to answer some of your questions, I use vscode and it works amazingly with python, so yes it does know what environment and python version you are using and can show source code, do type checking (if you use the "typing" module, and tons of other nice things that just work out of the box).

As far as the CI-system knowing, there is not much difference in installing a particular version of rust/cargo say in a docker container and having a particular version of python installed in a container, so I don't really know what you are getting at.

Could it be better? Sure, I do some programming in rust and IMHO the best build tool I've ever used is cargo. But compared to some of the other stuff you mentioned which I've used on projects as well (npm, lein specifically) I would say python is on the same level, and I prefer python over them but that's probably just my bad experience with package-lock/caching and long jvm load times speaking.

I solve this whole issue by using pyenv + direnv. I can have a project specific .python-version file and upgrade to a newer python version when necessary. Then I just run python -m venv env once on project creation and have direnv source env/bin/activate and can use pip as usual

The articles arguments against this and for always using python -m pip don't convince me, personally. I never work on windows, so that's a mute point, and b/c I use direnv to automatically activate my env when cd'ing into the directory, I'm never not in the project environment. So basically, its impossible to not be using the correct pip version i.e. I have never once had this problem and I am constantly working on multiple python projects + code bases in various envs and versions.

I completely agree with the sentiment here. As an engineer tasked with building data driven systems and architectures, I'm well aware of the amount of buzzword / enterprise nonsense floating around in this space - and it is enormous. You can couple that with the fact that its really difficult to find any practical books and resources that you can actually apply to solve real-world problems when working in small-teams and on quick deadlines. Getting business to act in a data driven and analytic way, and building the architecture for it - is a non-trivial task. This looks like it could be one of those rare good resources in the space.

Great work by the guys from chartio!