Hacker News Reader

Comment by kortex | Hacker News Reader

1. is true, yup people have been ragging on the python install superfund site problem for years, but the rest of those are entirely 3rd party library issues. It's like saying Windows is not a serious operating system because you installed a buggy application.

2. I've used a ton of languages and frankly Python has the best tracebacks hands-down, it's not even close. It's not Python's fault a 3rd party library is throwing the wrong error.

3. Again, why is bad language design a library can do janky things with I/O?

4. FFI is tricky in general, but this sounds like primarily a "read the docs" problem. All of the major numeric acceleration libraries have fixed sized numbers, python itself uses a kind of bigint that can be any size. You have to stay in the arrays/tensors to get predictable behavior. This is literally python being "a thin abstraction layer over C."

View on HN

I'm deliberately not differentiating between the language, the tool-chain, the libraries and the community. They are all closely connected, and in the end you're always buying into the bundle.

2. I would argue that the ubiquity of needing stack traces in Python is the main problem. Why are errors propagating down so deep? In Rust I know I'm in trouble when I am looking at the stack trace. The language forces you to handle your errors, and while that can feel limiting, it makes writing correct and maintainable code much more likely. Python lets you be super optimistic about the assumptions of your context and data - which is fine for prototyping, but terrible for production.

3. I agree that this isn't directly a language design issue, but there's a reason I feel the pain in Python and not in Rust or Java. Dynamic typing means you don't know what side effects a library might have until runtime. But fundamentally it is a skill issue. When I deploy the code of Java, Go or Rust people, they generally know I/O is important, and spent the necessary time thinking about it. JS, Python or Ruby devs don't.

4. The issue is that Python's integer handling sets an expectation that numbers "just work," and then that expectation breaks at the FFI boundary. And once you're of the trodden path, things get really hard. The cognitive load of tracking which numeric type you're in at any moments sucks. I completely agree that this was a skill issue on my part, but I am quite sure that I would not have had that problem if it was in a properly type-set, compiled language.

> Dynamic typing means you don't know what side effects a library might have until runtime.

Static typing (in most industrially popular languages) doesn't tell you anything about side effects, only expected inputs and return values.

I do think some module writers get overexcited about using some dynamic features and it can be hard to understand what's going on. On the other hand....

Dynamic languages let you do a lot of things with meta classes and monkey-patching that allow you to use a library without needing to build your own special version of it. With some C or C++ library that did something bad (like the logging one you mentioned) there's nothing for it but to rebuild it. With Python you may well be able to monkey patch it and live to fight another day.

It is great when you're dealing with 3rd party things that you either don't have the source code for or where you cannot get them to accept a patch.

“Python lets me do horrifying things no one should ever do in production code” isn’t the flex you think it is.

Why should no-one ever do them? They're useful. :-) FastAPI uses this stuff to make itself easier to use for example. They're things I would have killed for when I was writing C++.

It has been a couple of years, but I was working on a rather complex RoR application and trying to fix a bug, where I had serious trouble understanding the underlying behavior. I went through the library docs, gave our code multiple screenings and was just stumped. - Turns out, we were monkey-patching an issue that was a also resolved a couple of years before, in a slightly different way than the library authors, and this was leading to very subtle issues down the line.

Now of course, we should have long removed the monkey-patch, or properly documented it somewhere, or I should have been more knowledgeable about Ruby and known that monkey-patching was a thing, but there's a reason why it is a pretty frowned upon practice.

Reply on news.ycombinator.com