Python is the most popular language now, and that gives it a huge leverage relative to anything else. And there are efforts (numba, pypy, etc) that are solving many of the performance problems. So I do think that someone with a couple of years of python experience will more and more be comfortable where they are.
If numba and others were mature as they are now when I first started playing with Python, perhaps I would have dedicated more time to it and would not start learning Julia at all (it took me a while, even coming from Fortran). Now I donât want to leave because simply I like the Julia syntax better, I like multiple-dispatch, the expressiveness, Revise is fantastic, distributing packages to students or everyone else is a piece of cake, and my programs turn out to be faster than what I was able to do with Fortran (which tells more about how crappy I was writing Fortran, perhaps), because writing, optimizing and testing programs in Julia for performance is much more fun. And I was able to learn a lot about computer programming in general by learning Julia.
In the long term it is likely that most of the problems of every language will be solved, languages will be highly inter-operable, and people will chose one or another for the syntax, paradigms, and expressiveness. Those are somewhat subjective, but Julia is in a good position there, in my opinion.
no it is not, if you are using linux or macos you have python beforehand so you do not need do anything to type in python. if you are using windows (like me) installing python in windows is very straightforward.
if you want to use scientific packages just install anaconda and thatâs it, you do not need do anything else.
I am using matplotlib for 3 years and not, even one, time this not happened to me.
Python credit is not something we give it. If Python is so popular, itâs because of the efforts of so many people who have been working for it for thirty years.
Just a note in case thereâs any confusion caused by this, ModelingToolkit.jl (and Symbolics.jl) are not reliable replacements for SymPy in every context. They are pretty young projects and can simplify far fewer expressions than SymPy (e.g. integration).
However, SymbolicUtils.jl, the library that those are built on at least at the present seems like a very good foundation for building up symbolic ecosystems, but itâll take time. ModelingToolkit.jl is a great and poweful package that can do some things that SymPy canât do, but part of the reason itâs docs are so domain specific is that it just doesnât have the huge wealth of rules available to it that SymPy has and so wonât be able to simplify as many expressions. Itâs main advantages are domain specific advantages.
Well, that is not completely true. Recently I spent a whole afternoon trying to use PyPy to run a code, because of bizarre issues with configuration files, conda environments, and I donât know what else. I was quite impressed by how good was PyPy in accelerating the code, but the installation experience was horrible. Of course, for someone that already knows how to solve all the problems or configure things, none of those are actual problems. But that is what Mason said, when you know how to do stuff, the problems stop being problems.
Official Python implementation is CPython and your problem with pypy, jython, brython, iron-python or micropython does not relate to the subject. this projects are not maintained very well like official CPython even a lot of the C packages, which is a huge share, can not be used in this implementations.
What you said here is the resistance or passiveness of a community against developing new features and enduring the problems they face as discussed before. If a deficiency bothers, itâs better to work on it, try to solve it and share it. This makes open source community powerful against closed source. Also a community includes beginners to experts, anyone can contribute, so if most of a community have this perspective to their problems, their product would someday be obsolete or outdated. What you said in general was not a productive feature for a community.
Iâm not saying itâs a good thing or a bad thing. Iâm saying itâs a psychological fact that as we get used to things that are uncomfortable, we cease to recognize them as uncomfortable.
I agree, What gives a programming language its character is its community, not its syntax or performance. All problems can be fixed with a healthy community, as Python did.
My problem was with conda, something about its environments, about my terminal not being configured to it. I felt like trying to use gfortran in Windows. I do not know if Conda is official or not.
But your answer just illustrates the same thing you somewhat implied in previous posts concerning the Julia manual, the Julia IDE, or others: that people that are comfortable with one thing tend to attribute the problems others experience to their fault, third-parties fault, etc. The thing is that you are used to one tool, that is fine, you will be more comfortable with that tool because you know how to deal with the weakness of that tool.
We could start and endless similar discussion on operating systems, text editors, linux distributions, etc.
I agree with this. But in this context when you (in general) are free to choose any language to code in and you choose to use to deficiencies, you finally make a passive community where problems wonât handle.
However, this feature is not true among python community, because they handled lots of problems in years of their activity.
IMO, you seem to overly interpret and generalise things here to the Julia community which, correct me if Iâm wrong, you donât know very well. I donât know anyone in our community that is against developing new features or addressing problems mentioned in this thread (such as time-to-first-plot for example). Quite the contrary. Perhaps you find the current state of the language, in comparison to Python, not good enough. Thatâs unfortunate. But let me tell you that lots of people, often in there free time, are improving these pain points from Julia version to Julia version and there has been significant progress. Will we ever reach the snappy Python feeling when you power up your IDE? I donât know. But I donât like that you just seem to claim that we as a community are passive and donât care.
You canât be serious. What about itâs slowness and lack of proper multithreading? What about the bad numerical/linear algebra syntax? What about performance and much functionality being limited to builtin types?
This is exactly the sort of weaknesses in python that is dismissed by those who are used to working around it.
This effect concerns all languages to a greater or smaller degree, and certainly python as well.
Letâs slow this down a bit. Discourse recently added a âslow mode;â this seems like a good time to try it out. Please take time to consider your replies as you wonât be able to post for a little while afterwards.
This isnât a venue for bashing on either Python or Julia or either community. Constructive commentary is always welcome.
Fully agree with Carsten here - anyone interested in this should just spend a few days working in Julia 1.0 with the then-current version of Atom/Juno, and then move to 1.6RC1 with the current version of Juno or the VSCode extension.
Or if you donât want to do this just read Lyndonâs recent blog post: Julia 1.6: what has changed since Julia 1.0? which gives an excellent overview. In my opinion the rate of improvements is quite stunning, and if anything seems to me as someone whoâs been around since 0.3 to be picking up.
But ultimately this discussion is becoming a bit fruitless I fear, it started with some well-made points, many of which are well known to the Julia community (latency, lack of documentation, gaps in the ecosystem) and are actively worked on. Itâs always helpful to hear from newcomers because - as has also been established now - experienced users can easily forget about the pain points, but as the blog post above hopefully makes clear, despite (maybe) appearances in this thread, there is active work on all of these fronts.
Finally, generalizations about either the Python or the Julia community, or even the languages themselves, are unlikely to really help anyone. Itâs usually best to be clear about oneâs own requirements and then evaluate concrete strengths and weaknesses of languages against those.
Wow. Didnât expect to be totally dismissed. Do you think Iâm lying? Have you considered that my workflow is much different from yours and I possibly explore a different part of the parameter space?
Also using the package manager to handle python on Linux is a very bad idea Iâve learned. I now only use pip and virtual environments to avoid issues where the Ubuntu provided numpy is out out of date. Do you know that if you âpip listâ to see your dependency versions, that doesnât actually reflect what will be loaded? If youâve for example installed numpy via pip and apt, it will list the pip version but load the apt version.
Just from the last week I ran into this bug https://github.com/ipython/ipython/issues/12740 and had to manually downgrade Jedi (related to autocomplete) to even start ipython. Iâve had many issues with Jesus, to the point where the first tab autocomplete upon launching ipython can take 20 seconds or so.
I guarantee you there are many warts in the python eco system. Itâs still great, but there are many warts and I donât appreciate being dismissed when your coming in here to point out warts in Julia.
i was answering to @Mason statement about enduring what bothers and it was in general. It was mininterpreted that i was talking about julia community. I barely know julia developers but all of them were so considering and professional.