Live data from Hacker News

Python Is Eating the World

zdnet.com

561–570 of 993 posts

Re: Python Is Eating the World

#561
post #257

Earlier quoted context omitted.

> Or something that works with PyPI directly Poetry is python specific and does not solve the problems that pip/pypi has with native C/C++/Rust/etc modules. Nix/guix solves all of that

Indeed. We have some Python modules written in Rust. It needs Rust nightly, because pyo3 requires Rust nightly. The Rust crate relies on libtensorflow. Unit tests for the Python module use Python and pytest. And we use our own build of libtensorflow (optimizations for AVX and FMA). The dependencies of such projects are easy to specify in Nix. Moreover, it's easy to reproduce the environment across machines by pinning…

I installed Nix operating system on an old lap top earlier this year, and indeed it does solve a lot of development and devops problems. I retired this spring, so I only played with Nix out of curiosity, but if I still had an active career as a developer I would use Nix.

Re: Python Is Eating the World

#562
post #83
post #33

Python has a lot of problems that really slow down development, but they are all fixable. The biggest issue, in my opinion, is in dependency management. Python has a horrible dependency management system, from top-to-bottom. Why do I need to make a "virtual environment" to have separate dependencies, and then source it my shell? Why do I need to manually add version numbers to a file? Why isn't there any builtin way…

Pipenv has felt to me like a pretty solid solution. It's not perfect but it's a lot better than the other options.

from poetry docs: https://github.com/sdispater/poetry/blob/master/README.md#de...

"

Let's take an example:

  pipenv install oslo.utils==1.4.0
will fail with this error:

  Could not find a version that matches pbr!=0.7,!=2.1.0,=0.6,>=2.0.0
while Poetry will get you the right set of packages

"

Re: Python Is Eating the World

#563
post #547

Holy Crap! What a lot of irrational, hyperbolic hate for Python. I think everybody should spend their first couple of years working in Fortran IV on IBM TSO/ISPF. No dependency management because you had to write everything yourself. Or maybe [edit: early 90's] C or C++ development where dependency management meant getting packages off a Usenet archive, uudecoding and compiling them yourself after tweaking the config…

Are you saying that python is good for the 90s? VB6 was good for the 90s. But that's not really relevant to what language to use now.

No, not at all, I'm saying if you had been a C programmer in the 90's you would have some perspective on some of the complaints and comments about python in 2019.

Re: Python Is Eating the World

#564

Earlier quoted context omitted.

I've worked in so many languages and environments in my career and Django/python/virtualenv has to be one of the least painful. I tried Rails which is very similar but feels "inside out", a good friend of mine loves Rails and hates Django and has the exact same feeling about Django. That's kind of my point, you may like other environments better, such as React/Node/NPM but that doesn't mean Python is a horror show. I…

How stable is python to run a full trading / quantitative algorithm on? I feel there are benefits for every language. I am just curious if super stable and scalable conditions can be met on python.

What do you mean by "stable"?

FORTRAN will give you super scalable conditions. I don't think you really meant that either... do you have a GPU cluster at work?

Re: Python Is Eating the World

#565
post #102

Earlier quoted context omitted.

It seems to value my time quite highly, as I can achieve most things more quickly and easily in Python than any other language I know. Can you be more specific about how it increases your burnout? Is it the language, or someone forcing you to use that linter and settings?

I'm not the person you're responding to but what they say resonates with me as a Python developer. I believe Python is quite possibly the best language for a few things * Exploratory programming - such as what data scientists do * Writing programs that will never grow beyond 150LOC, or roughly what fits on a screen + one page down When I have those two constraints met I am almost always choosing Python. Here are some…

> and multiprocessing is a dead end.

Why is multiprocessing a dead end?

Re: Python Is Eating the World

#566

Earlier quoted context omitted.

Go's new system addresses them all too. This is the other frustrating thing: there is this stockholm syndrome effect, because people are so used to dependency management being horrible, they think there are just no good dependency management systems, and they give up.

What system is this? Isn't the built in package system still just pulling from github URL's?

GitHub is still the host for many of them, but there are Modules, so you get proper versioning and all that even when the place you end up getting them from is GitHub.

Re: Python Is Eating the World

#567
post #496
post #471

Earlier quoted context omitted.

Isn't it also just as much about Python is having it's day, granted a day long in the waiting but many langs go through this (Ruby, PHP) and then it tapers off and the next language has it's day. Probably Go will be the next hotness in 5 years.

Actually, Golang isn't so great. Try to change something lower level, for example in their socket implementation. Also, it's trying to promise a sane concurrency and all code I've seen use mutex all over the place.

> Also, it's trying to promise a sane concurrency and all code I've seen use mutex all over the place.

I think that's a fault of the devs, more than the language. In many cases (not all, of course) Go gives you multiple ways to achieve concurrent safety. Channels, being the big secondary. Yet it generally (in my experience) requires a very different implementation and in general has a lot of pitfalls. Over all I don't like Go these days, but I prefer it over Python (mostly due to at least having basic types)

I've switched everything to Rust though. Just as productive as Go (to me), with more tooling. Though, Rust will be much better in a couple years with some additional baking on new features (GATs, Futures, etc).

Re: Python Is Eating the World

#568
post #500

Earlier quoted context omitted.

So? Nothing is stopping you from using it in your projects, thus solving your problem for good.

If a project you want to depend on isn't using a dependency management framework, how would you then make it work in your project? You will have to do extra work to define the transitive dependencies! What needs to happen is standardization - this has been done in java because of it's maturity. There's almost no java project that isn't using the standard maven dependency management (even projects that don't use maven…

There are two main ways:

First of all, Poetry locks every dependency (even transitive ones) to the version you know works. This solves the problem of the project not using dependency management properly.

Secondly, setup.py allows you to specify your dependencies there, so most libraries use and specify that, which means that that isn't that much of a problem in Python. Sure, sometimes it is, but I haven't run into that particular problem very often.

Re: Python Is Eating the World

#569
post #513

Earlier quoted context omitted.

Agreed. I really don't understand all these buckets filth being poured on Python in this thread. It's a first language I worked with in my life that just clicked with my brain and doesn't just drain me. I would take a Python job over a Java/C/C++/Go/Rust any day. There's some languages that could pull me away from Python (Nim, Crystal) but they're nowhere popular enough to move wholesale to them.

> I would take a Python job over a Java/C/C++/Go/Rust any day it's funny, I feel the exact opposite. I work on a team that maintains a digital catalog, and a lot of what we write is about taking in asset- and metadata files, asynchronously processing them, and then publishing that to a denormalized read-optimized data store. We often joke that we mostly take data from 'over here' and put it 'over there'. All our stuf…

I know that this is not strictly static typing but in Python 3.5 they added an optional type system. See https://docs.python.org/3/library/typing.html

Re: Python Is Eating the World

#570

Reading this got me thinking and I wonder if other people feel like me about this, so I'm going to share it. This is not serious, but not entirely unserious... I try to be a good sport about it, but every time I write python I want to quit software engineering. It makes me angry how little it values my time. It does little for my soured disposition that folks then vehemently lecture me about the hours saved by future…

>that infernal pep-8 linter insisting 80 characters is a sensible standard in 2019

So change the limit or disable that check. If someone is keeping you from doing that they're the one who's insisting on 80 characters, not the language. Who uses any linter without making some changes to its default settings?

Post reply on HN