Hacker News Reader

Hacker News

Comment by eddd | Hacker News Reader

Full thread

eddd

I use python on daily basis for 5 years now. It's a really cool language, but:

* Packaging is horrible

* Releasing python code is a non-standarised nightmare. Every solution has it's own flaws

* Big and complex projects in python are really hard to reason about

* Poor support for concurrency (fixed in py3)

Don't get me wrong, python is really cool as a proof-of-concept scripting language. But for mature and complex stuff, I'd recommend something with type checking and better support for release process.

View on HN

Do you really think packaging is still horrible? I tend to agree with Glyph Lefkowitz [0]. What issues are you still having?

[0] https://glyph.twistedmatrix.com/2016/08/python-packaging.htm...

Fully agree. After spending quite some time working on a medium-sized Python codebase I went from being agnostic about static vs. dynamic typing to favor static typing. In a small side project I've used Python 3.5 with type annotations and it's an improvement, IMHO.

I've been a Python developer for years and I also agree that static typing is fantastic. I'm very much looking forward to the recent optional typing in 3.5 improving.

I've been really happy using Pex[1] for releases, but it's not 100% perfect. It definitely feels less painful than other ways of doing things. At one point I used bdist_rpm for all of my projects, and then made sure I had all the dependencies installed (also through RPM, using FPM to create an RPM if it didn't exist). It was a nightmare.

1: https://github.com/pantsbuild/pex

Yeah, I created an issue on github about the lack of support for pex on uwsgi. Proposed solution (https://github.com/unbit/uwsgi/pull/1297#issuecomment-240200...) will work, but again, this is not standardised at all. This is one big hack comparing to the way how Erlang boots up their apps. Erlang here is a good comparison, because it is much more complex and harder to learn, but it is complete in terms of release process. You don't have to hack your way out to production, just read the docs and you know what to do. Python wasn't designed to run this way, so everyone tries to create their on standard.

I've programmed in a few other languages than Python. I'm curious to know which languages you think have an easier time managing mature and complex stuff?

It really depends on the type of project that you are working on. For backend services that don't require much data processing (OCR, some complex matrix calculations) I'd recommend erlang or elixir. Here is why:

* type annotation + awesome tool for analysing code (dialyzer)

* immutability, list cannot become a dict out of nowhere

* great support for concurrency

* concept of application (OTP) gives out ability to run many loosely coupled apps on one VM. I believe "microservices" is the buzzword that matches the concept.

* distribution by design.

* great monitoring tools

* I could go on... really.

Statically typed languages. Personally, java or C#.

I've worked with large C++ projects and large C# projects (both at large software corporations) and the code was not particularly less unwieldy than an equivalent Python projects I've worked on.

I think static typing alone doesn't make managing complexity easier.

I'd like to know what other features people think Python is lacking that make it much worse than C# or Java when handling large projects.

I'm often frustrated with python packaging but after trying a few other languages' equivalents' (npm, go, etc.) I'm starting to think it's really not so bad.

Just yesterday I had a frustrating issue. Digital Ocean VM with Ubuntu 16.04 and pip 8.1.1 installed via apt. "pip install -r requirements.txt" with pinned (recent) versions failed. I think it triggered this issue https://github.com/pypa/pip/issues/3687. Didn't investigate though, since this was just a side project and it was 11pm. Made it work somehow. :-/

I'm curious as to what issue you're running into with npm? npm install pug --save , installs to your local project, and adds to package.json. Not sure how that can get any easier! Makes deployments silly simple as well, and the ecosystem is massive surrounding it.

* I sometimes had to run "npm i" twice in order to get it to work.

* It would often fail randomly.

* node_modules has a fixed location.

* There is a ludicrous number of dependencies even for the simplest projects. ~1000 is not unusual. Reasoning about that dependency tree simply isn't possible.

* There was even a package to detect if a number was negative. It had a version 2 because there was a bug!

* In general even small projects took an age to build.

I'm sure this isn't all the craziness, it's just the stuff I ran into during my (fairly limited) exposure to npm packaging.

Certainly any dependency manager has its issues, and I've run into a lot of them with other ones as well. But yes, I will agree, the dependency hell comes from requiring duplicates for each package you install. Though NPM is working on resolving that. Not sure what you mean by age to build though? What are you building after package install?

Reply on news.ycombinator.com