3 ms·

It's really too bad too. Most of the languages we've settled on have glaring problems, but I guess "critical mass" doesn't really care. Python's packaging is a

It's really too bad too. Most of the languages we've settled on have glaring problems, but I guess "critical mass" doesn't really care. Python's packaging is a mess (and a host of other problems), JavaScript has almost as much baggage as Java with much worse design decisions, over-complicated tooling, etc. (but has arguably some of the best runtime implementations in existence). Rust is good, but has sharp edges and a steep learning curve. Both Rust and JS have adopted some FP concepts that are pretty nice, so there's that.

eptcyka 4y ago
Python's packaging mess have nothing to do with the language itself, most definitely from the perspective of programming language theory.
- packetlost 4y ago
  It is related, but not in a way that matters much. My main issues with Python are related to the language itself, primarily around duck-typing, lack of good lambdas, import side-effects, etc..
- throwaway894345 4y ago
  As I understand it, it's related to the decision to make the entire interpreter part of the public C extension interface which drove everyone to write C extensions for anything that was remotely performance sensitive (and the breadth of the extension interface and the pervasiveness of C extensions in the Python ecosystem made it really difficult to make substantial backwards compatible performance improvements in the interpreter). Since so much of the ecosystem is C, Python package management has had to try and figure out how to distribute arbitrary versions of C software to arbitrary target systems which is really hard in large part because C projects don't have any standard build tooling or dependency management. As far as I know, no one has figured out how to do this well given Python's constraints (the best language package managers just absolve themselves from Python's original sin--pushing the ecosystem toward FFI rather than making the core runtime model fast enough for native code).
  - packetlost 4y ago
    Yeah, this matches up pretty much exactly with my understanding of the issue. Python as a language is "pretty good" but far from perfect, and it's really unfortunate that C's packaging/building ecosystem is in such a horrible state.
    - throwaway894345 4y ago
      > it's really unfortunate that C's packaging/building ecosystem is in such a horrible state. This is a recurring theme in my career. It's one of my cornerstone grievances with Nix as well (any time I need to write a Nix package I end up having to package some obscure C dependency that my package transitively depends on). :)
  - eptcyka 4y ago
    None of the above is an argument as to why pip, poetry, virtual envs and half a dozen other tools and methods are needed to manage packages with Python. I'd go so far as to say that this isn't even a language level issue, as much as it's an implementation detail, a rather important one. However, for some context, Python first came out in 1991. Back then, nobody was really focusing on making anything run well on multiple cores, best you could get was multiple CPUs in somewhat esotheric systems. It's far easier to understand the design decisions for a programmer friendly (and hardware hostile) language in the 90s.
    - thesz 4y ago
      Tcl was born three years earlier. The AOLServer, which was heavily multithreaded and based on Tcl, was developed in 1995: https://en.wikipedia.org/wiki/AOLserver https://en.wikipedia.org/wiki/AOLserver You also can easily guess who of these two get i18n right earlier. The AOLServer was made possible by the decisions to have an API to have specific versions of interpreters (including highly constrained safe ones), by forcing extensions to have per-interpreter state and make interpreters communicate by messaging on Tcl level. This resulted that if your extension worked with several interpreters in single thread execution, it would work with several threads ruunning in parallel. The same is for just Tcl code, which does not even know which thread it gets executed on. Thus, Python developers did not do any looking around.
throwaway894345 4y ago
Rust has a steep learning curve, but I'm not sure what its "sharp edges" are? Certainly it has fewer sharp edges than a fully dynamic language? FWIW, I'm not a Rust evangelist or anything; my background is largely Python, Go, C/C++ with a smattering of Rust and JS/TS.
- bobbylarrybobby 4y ago
  I would say the sharp edges aren't unexpected runtime behavior — compiles => works as expected, barring off by one errors — but rather things like “I just spent an hour figuring out the best way to build a tree out of nested HashMaps because the borrow checker didn't want me to do overlapping mutable borrows” or “what's the right way to be agnostic with regard to owned or borrowed data in my struct/function”. I don't consider these to be part of the learning curve because the problems are inherently more complicated than just “how do I use rust”.
  - tialaramex 4y ago
    Conventionally we use "sharp edges" to mean things which are dangerous in a surprising way. For example freshly cut paper has a sharp edge, it's very easy to cut yourself painfully on a sheet of blank paper. The things you've described don't threaten to be dangerous or surprising. They're not good but they don't strike me as "sharp edges".
  - throwaway894345 4y ago
    I see what you mean. As the sibling noted, I think you're using "sharp edges" in an unconventional way, but Rust definitely has a sort of unpredictable developer experience. Some things go really fast and the programmer finds themselves thinking, "wow! this is as easy as Python/Go/whatever!" and other times something that seems to be easy fails to compile and you get a compiler error that says you need to fix one seemingly small thing, so you try and fix that small thing and you get another seemingly-easy-to-fix compiler error and you just keep pulling on that thread until you've forgotten the problem you were originally setting out to solve. (: I don't think this is a "sharp edge" (maybe "indeterminately long threads to pull") but it definitely is an unpleasant experience. If anyone knows of any good names for this category of frustration, I'd be happy to hear them!

eptcyka 4y ago

Python's packaging mess have nothing to do with the language itself, most definitely from the perspective of programming language theory.

packetlost 4y ago
It is related, but not in a way that matters much. My main issues with Python are related to the language itself, primarily around duck-typing, lack of good lambdas, import side-effects, etc..
throwaway894345 4y ago
As I understand it, it's related to the decision to make the entire interpreter part of the public C extension interface which drove everyone to write C extensions for anything that was remotely performance sensitive (and the breadth of the extension interface and the pervasiveness of C extensions in the Python ecosystem made it really difficult to make substantial backwards compatible performance improvements in the interpreter). Since so much of the ecosystem is C, Python package management has had to try and figure out how to distribute arbitrary versions of C software to arbitrary target systems which is really hard in large part because C projects don't have any standard build tooling or dependency management. As far as I know, no one has figured out how to do this well given Python's constraints (the best language package managers just absolve themselves from Python's original sin--pushing the ecosystem toward FFI rather than making the core runtime model fast enough for native code).
- packetlost 4y ago
  Yeah, this matches up pretty much exactly with my understanding of the issue. Python as a language is "pretty good" but far from perfect, and it's really unfortunate that C's packaging/building ecosystem is in such a horrible state.
  - throwaway894345 4y ago
    > it's really unfortunate that C's packaging/building ecosystem is in such a horrible state. This is a recurring theme in my career. It's one of my cornerstone grievances with Nix as well (any time I need to write a Nix package I end up having to package some obscure C dependency that my package transitively depends on). :)
- eptcyka 4y ago
  None of the above is an argument as to why pip, poetry, virtual envs and half a dozen other tools and methods are needed to manage packages with Python. I'd go so far as to say that this isn't even a language level issue, as much as it's an implementation detail, a rather important one. However, for some context, Python first came out in 1991. Back then, nobody was really focusing on making anything run well on multiple cores, best you could get was multiple CPUs in somewhat esotheric systems. It's far easier to understand the design decisions for a programmer friendly (and hardware hostile) language in the 90s.
  - thesz 4y ago
    Tcl was born three years earlier. The AOLServer, which was heavily multithreaded and based on Tcl, was developed in 1995: https://en.wikipedia.org/wiki/AOLserver https://en.wikipedia.org/wiki/AOLserver You also can easily guess who of these two get i18n right earlier. The AOLServer was made possible by the decisions to have an API to have specific versions of interpreters (including highly constrained safe ones), by forcing extensions to have per-interpreter state and make interpreters communicate by messaging on Tcl level. This resulted that if your extension worked with several interpreters in single thread execution, it would work with several threads ruunning in parallel. The same is for just Tcl code, which does not even know which thread it gets executed on. Thus, Python developers did not do any looking around.

throwaway894345 4y ago

Rust has a steep learning curve, but I'm not sure what its "sharp edges" are? Certainly it has fewer sharp edges than a fully dynamic language? FWIW, I'm not a Rust evangelist or anything; my background is largely Python, Go, C/C++ with a smattering of Rust and JS/TS.

bobbylarrybobby 4y ago
I would say the sharp edges aren't unexpected runtime behavior — compiles => works as expected, barring off by one errors — but rather things like “I just spent an hour figuring out the best way to build a tree out of nested HashMaps because the borrow checker didn't want me to do overlapping mutable borrows” or “what's the right way to be agnostic with regard to owned or borrowed data in my struct/function”. I don't consider these to be part of the learning curve because the problems are inherently more complicated than just “how do I use rust”.
- tialaramex 4y ago
  Conventionally we use "sharp edges" to mean things which are dangerous in a surprising way. For example freshly cut paper has a sharp edge, it's very easy to cut yourself painfully on a sheet of blank paper. The things you've described don't threaten to be dangerous or surprising. They're not good but they don't strike me as "sharp edges".
- throwaway894345 4y ago
  I see what you mean. As the sibling noted, I think you're using "sharp edges" in an unconventional way, but Rust definitely has a sort of unpredictable developer experience. Some things go really fast and the programmer finds themselves thinking, "wow! this is as easy as Python/Go/whatever!" and other times something that seems to be easy fails to compile and you get a compiler error that says you need to fix one seemingly small thing, so you try and fix that small thing and you get another seemingly-easy-to-fix compiler error and you just keep pulling on that thread until you've forgotten the problem you were originally setting out to solve. (: I don't think this is a "sharp edge" (maybe "indeterminately long threads to pull") but it definitely is an unpleasant experience. If anyone knows of any good names for this category of frustration, I'd be happy to hear them!