Best summary of why Python sucks a lot.
Python as a standalone language is harmless.
But this business of having python creep into other apps as a dependency, then make changes that break things should not be tolerated. It is the distro makers responsibility to prevent one package making changes that break other packages. They are letting us down here. Python3 needs to be blacklisted.
It would seem that python has an updating structure that is incompatible with modern stable computing environments. I wonder how much of this is is due to
pip which allows users to add in packages to their python environment , without any semblance of version control?
Can we get together a list of languages that could be used in places where python is used, hopefully to better effect ?
“That fact and just the simple fact that Python is in my opinion just a cumbersome annoyance to fight with, pushes me toward looking at Julia and hoping most apps will be written by using this language instead of all that Python”
I read your old post.
Yes Julia is probably a good substitute for Python.
A lot of people use Python for statistical work… I am not sure how easily they would convert from a scripting language to Julia ( or R)
My own trials with Julia are not all positive. … Void has a Julia issue… an update to libcurl has broken Julia’s ability to download any packages from the github site… It may be a Void package problem more than a Julia problem, but I have to use Julia in Debian at the moment because of it. Julia maintainers are slow to deal with it.
Apart from that, yes Julia would be workable for writing applications and extensions… Julia does take a long time to precompile stuff… that needs attention. In my opinion it has a lousy workflow when writing code. I have spent a lot of time practicing coding I/O in Julia… it is different and challenging, but it can do the job. It can read stuff from the command line, it can pick up a ‘hereis’ document from the input stream , and it can open files. It would not suit kernel programming… you need a compiler there.
So I agree in principle. we should consider Julia for at least some systems programming tasks that python now monopolizes.
I couldn’t agree more, as Python 2 is installed when I use my AppImage of ClipGrab, which now uses YouTubeDL as it’s downloading script. When you first load it up, it goes off to update YouTubeDL, but you must install a version of Python first
sudo apt install python always installs Python 2 as default. So why Python 3? What is the difference? Python 3 just seems to crash stuff, where as Python 2 says yes every time. It’s like Deb files or Snaps?? Deb file every time for me. What came first the Chicken or the Egg?? The bacteria to make the egg in the first place, or the life form to lay the egg.
It is literally the replacement for Python. The only reason why Python isn’t dead, is because so many old projects use it and then people think “oh Python good, Python is used, so Python good”, which leads them to creating new software with it. Similar problem with C and C++…
If all the Python baggage wouldn’t exist in crucial software, then Julia would straight up replace Python in the chart of most popular languages in the world, without question.
Well, with Jupyter, they are already pretty much inter-changeable.
That said, Julia is like Python. It has the same use cases with statistical work, AI, machine learning, etc… But it does it better, all in all. It’s also an interpreted language, just like Python.
That’s actually a huge topic I am currently interested in. It seems like operating system constantly break otherwise working programming language stuff, mostly dependencies. This issue is actually so huge, I even have to admit, despite all my hate for Python, that some Python issues wouldn’t exist if operating systems wouldn’t force their packaging architecture onto all programming languages.
So, in this case, I would guess it’s more related to Void and if Julia maintainers aren’t that interested in fixing an issue in an operating system, more so in a not most popular one, then that’s probably acceptable. Strictly speaking, it’s not their issue. It’s an issue with how the operating system’s packaging mechanism is dealing with individual needs of programming languages, especially regarding dependency management.
I mean, is it better than Python? Then, they accomplished the mission I personally see for Julia. My view is, if this Python replacement is working better than Python, then it’s already worth using it.
I don’t love Julia and I thnk it’s far from perfect. I also prefer statically compiled languages, to begin with.
However, as a true replacement for Python, it’s a great language. People should just use Julia instead of Python to have a better experience overall, than it is the case with Python.
Yes, but that’s not the main aspect. That’s just optional stuff. The main purpose of Julia is the same of Python. All the statistical work, Jupyter, etc… So, no need to use Julia. There are plenty of alternatives for this different area.
I think the general definition of Systems Programming is referring to low level languages like Rust. I think the term doesn’t fit what the Jupyter languages aim for.
The reason that happens, is that Python 2 is only getting security patches since a long time, while Python 3 is constantly changing. Both are shit, but Python 3 is actually better than Python 2. The only reason why Python 2 still exists, is because it is generally incompatible with Python 3 and some old scripts using Python 2 are still used in production (yes, this excuse annoys me so much…).
Things would generally work slightly better with Python 3, if Python 2 would finally tip its hat and jump down the grave.
Yes. Libcurl made some changes and Julia did not keep up. Then Void put incompatable versions together. Debian escaped because it only updates packages every 18 months.
I expect half the Linux distros have an inoperable Julia at the moment.
Julia will never be used for anything until they fix that sort of rubbish
My Missuses name, she unfortunately still uses Windows 10.
I don’t think that’s a realistic statement. If any package can break any other package, there is always the possibility one package “can’t keep up” with that breakage. Actually, this is also a huge topic on its own.
Some of the posts in this topic describe how any package can just randomly break an arbitrary amount of other packages. This topic is focused on a specific design problem in how Nix’ package management works, but the fundaments of this problem apply to any packaging mechanism, employed by any operating system.
Good saints name.
unfortunately still uses Windows 10.
Convert her to Android. Buy her a tablet.
From what I read, you should not use the installed Python. That is for the operating system and applications delivered with it.
For your own development you should create virtual environments which include their own version of Python and any PIP installed packages. Whatever you do in the virtual environment does not affect what was delivered with the OS.
It makes sense to do it that way, but is a bit of a pain.
That’s for example another thing I don’t like about Python. Python is so inherently broken, it had to create an entire system of isolation, just to work around the fundamental design issues. I mean, operating systems sometimes create issues with programming language tools, but it seems like it breaks the most and easiest with Python. Python seems to be more fragile than an antique vase.
Yes, but this is Julia itself notmkeeping up with other package changes.
And it affects the critical area of access to Julia libraries. Lets say you are programming in C and glibc is located, not in /lib on your computer but on some github site on the other side of the planet. That would be rqther inconvenient, to say the least.
Julia needs to redesign its library system. Lets say you rewrite Inkscape in Julia. Then when someone starts Inkscape, it goes looking for dynamic libraries needed to load, and you get “sorry cant load Inkscape today the internet is down”…It is not workable.
Julia is a good language, but its operating environment is weird and needs some redesign. I cant see it replacing Python until one can write a piece of Julia code, drop it into a package, and have it work… independent of the current Julia support structure.
I had a read of the NixOS discussion. The key statement is
Having a single highly-interconnected body of software is different than have 10’s of thousands of loosely coupled packages. Ideally there’s more maintainers that look to staging, as it’s easier 1 to fix regressions during staging-next than on master.
The thing about Python is it turns independent packages into interconnected packages. It is making itself as important as gcc. The difference is noone modifies gcc in a way which breaks things. We an be thankful for that.
Testing interconnections is almost impossible. To test 20000 packages independently is 20000 jobs. To test their interconnections is
20000 ^2 jobs. I bet there is no distro that does this comprehensively.