7 ms·

I don't know much about Rust, but I have a hard time believing python's standard library wouldn't have all the required functionality covered (whether performan

I don't know much about Rust, but I have a hard time believing python's standard library wouldn't have all the required functionality covered (whether performance would be adequate is different question). I for one, really really like python for its comprehensive standard library.

sayanarijit 4y ago
As long as there's no need to ship standalone binaries without shared libraries.
- mgunyho 4y ago
  Indeed, Python would be a good language to implement this in terms of ease of development, but it's very difficult to distribute a standalone binary (which I wanted to do). The built-in curses support of Python is also not cross-platform I think.
  - nibbleshifter 4y ago
    Standalone Python apps as binaries tend to be poorly performant, and huge (due to shipping an interpreter, stdlib, deps, etc) in my experience. Assuming you get it working at all.
    - jonnycomputer 4y ago
      I'd prefer an informative rebuttal if people disagree with nibbleshifter, because I want to learn.
      - nibbleshifter 4y ago
        I'm also kind of hoping someone comes along and says I'm wrong with a solution that doesn't suck tbh.
  - chrismorgan 4y ago
    It’s a funny thing I’ve noticed about scripting languages: they’re generally easier to get going with yourself, but they’re horrible for distribution/deployment, and if you have to integrate code written in other languages (even C libraries with Python bindings, or similar—things like wxWidgets or GTK), that rapidly escalates to a nightmare. Meanwhile, ahead-of-time compiled languages like Rust and Go are simply a breeze to distribute/deploy.
    - mgunyho 4y ago
      That's true, although I think in the case of Go, it is a central design decision to make single-binaries easy so it's more of an exception to the rule. I don't think it's an inherent feature of scripting languages that they are hard to distribute. I'm pretty sure it's possible to package up a tiny Lua interpreter (or e.g. QuickJS) and all necessary scripts into a standalone file.
      - sayanarijit 4y ago
        Lua is only a configuration language without luarocks. With luarocks, we're back to the root of the argument - dependency vs standard library.
    - mixmastamyk 4y ago
      There are several working options for packaging Python apps, some existing for twenty years. Sure, while a little more complicated than compiling a static executable, it is hardly a "nightmare." It's basically writing a config file, and adding another stanza to a Makefile or modern equivalent. Reminds me of the idea regularly pushed here that you need a virtualenv even for thirty-line scripts. I read these kind of takes here often and am a bit baffled by them. Maybe it is because developers have lost administrator skills over time, that this feels like an insurmountable challenge?
      - sayanarijit 4y ago
        That static executable will basically contain the whole python interpreter with a huge standard library. Maybe makes sense for a gui app, but I'd avoid installing a whole python interpreter for each of my little cli tools. Don't forget the startup time overhead of first loading a whole interpreter into memory, then loading a python program into the interpreter.
wongarsu 4y ago
Yes, Rust has a very different philosophy to the standard library. As soon as something enters the standard library its API is basically set in stone, since there's no versioning for the standard lib. As a consequence, Rust choses to keep a lot of "must-have" functionality in crates, where it can evolve and compete. (rather than just adding more and more HTTP clients to the standard lib like Python did :) )
- mxben 4y ago
  > As soon as something enters the standard library its API is basically set in stone Is that really all that different from Python?
  - chrismorgan 4y ago
    No, that’s the point: if you put this stuff in the standard library, it gets frozen forever, and that’s why Rust doesn’t.
    - infinityio 4y ago
      To quote the python developers guide: > Because of Python’s conservative nature when it comes to backwards-compatibility, when a module is added to the stdlib its API becomes frozen. So it sounds like they do do something fairly similar, but just a different mindset on adding libraries
nibbleshifter 4y ago
Python is "batteries included", Rust isn't. Different design choices entirely. You can do a lot with pythons stdlib, and a lot of popular libraries (requests, for example) largely are just usability wrappers for underlying stdlib stuff. Whereas with Rust, you have a very minimal std, and things you want to achieve are imported specifically.
- mixmastamyk 4y ago
  requests is a wrapper around urllib3, which re-implements quite a bit.
chrismorgan 4y ago
No, actually. Of the direct dependencies, Python’s standard library has equivalents of regex (re), serde/serde_json (json), clap (argparse) and the boring half of textwrap (textwrap, which is only suitable for ASCII, and possibly curses providing a buggy and incomplete version of Unicode- and column-awareness, but I’m not sure of even that much, and I don’t think it’s properly cross-platform either), and some parts of crossterm (curses, of uncertain availability and reliability). But it completely lacks equivalents of most of crossterm and textwrap, and all of dirs and unicode-segmentation, providing in the latter two cases only functionality pretty much exactly equivalent to what Rust’s standard library contains. This is the sort of thing that I meant by “doing things properly rather than half-heartedly”. You could make something like this by reimplementing half the libraries in an inferior fashion, full of bugs, cross-platform inconsistencies and missing functionality. Or you can take an extra dependency. Even in Python, the recommendation would be firmly to add dependencies like appdirs for dirs and I dunno what for the rest.

sayanarijit 4y ago

As long as there's no need to ship standalone binaries without shared libraries.

mgunyho 4y ago
Indeed, Python would be a good language to implement this in terms of ease of development, but it's very difficult to distribute a standalone binary (which I wanted to do). The built-in curses support of Python is also not cross-platform I think.
- nibbleshifter 4y ago
  Standalone Python apps as binaries tend to be poorly performant, and huge (due to shipping an interpreter, stdlib, deps, etc) in my experience. Assuming you get it working at all.
  - jonnycomputer 4y ago
    I'd prefer an informative rebuttal if people disagree with nibbleshifter, because I want to learn.
    - nibbleshifter 4y ago
      I'm also kind of hoping someone comes along and says I'm wrong with a solution that doesn't suck tbh.
- chrismorgan 4y ago
  It’s a funny thing I’ve noticed about scripting languages: they’re generally easier to get going with yourself, but they’re horrible for distribution/deployment, and if you have to integrate code written in other languages (even C libraries with Python bindings, or similar—things like wxWidgets or GTK), that rapidly escalates to a nightmare. Meanwhile, ahead-of-time compiled languages like Rust and Go are simply a breeze to distribute/deploy.
  - mgunyho 4y ago
    That's true, although I think in the case of Go, it is a central design decision to make single-binaries easy so it's more of an exception to the rule. I don't think it's an inherent feature of scripting languages that they are hard to distribute. I'm pretty sure it's possible to package up a tiny Lua interpreter (or e.g. QuickJS) and all necessary scripts into a standalone file.
    - sayanarijit 4y ago
      Lua is only a configuration language without luarocks. With luarocks, we're back to the root of the argument - dependency vs standard library.
  - mixmastamyk 4y ago
    There are several working options for packaging Python apps, some existing for twenty years. Sure, while a little more complicated than compiling a static executable, it is hardly a "nightmare." It's basically writing a config file, and adding another stanza to a Makefile or modern equivalent. Reminds me of the idea regularly pushed here that you need a virtualenv even for thirty-line scripts. I read these kind of takes here often and am a bit baffled by them. Maybe it is because developers have lost administrator skills over time, that this feels like an insurmountable challenge?
    - sayanarijit 4y ago
      That static executable will basically contain the whole python interpreter with a huge standard library. Maybe makes sense for a gui app, but I'd avoid installing a whole python interpreter for each of my little cli tools. Don't forget the startup time overhead of first loading a whole interpreter into memory, then loading a python program into the interpreter.

wongarsu 4y ago

Yes, Rust has a very different philosophy to the standard library. As soon as something enters the standard library its API is basically set in stone, since there's no versioning for the standard lib. As a consequence, Rust choses to keep a lot of "must-have" functionality in crates, where it can evolve and compete. (rather than just adding more and more HTTP clients to the standard lib like Python did :) )

mxben 4y ago
> As soon as something enters the standard library its API is basically set in stone Is that really all that different from Python?
- chrismorgan 4y ago
  No, that’s the point: if you put this stuff in the standard library, it gets frozen forever, and that’s why Rust doesn’t.
  - infinityio 4y ago
    To quote the python developers guide: > Because of Python’s conservative nature when it comes to backwards-compatibility, when a module is added to the stdlib its API becomes frozen. So it sounds like they do do something fairly similar, but just a different mindset on adding libraries

nibbleshifter 4y ago

Python is "batteries included", Rust isn't. Different design choices entirely. You can do a lot with pythons stdlib, and a lot of popular libraries (requests, for example) largely are just usability wrappers for underlying stdlib stuff. Whereas with Rust, you have a very minimal std, and things you want to achieve are imported specifically.

mixmastamyk 4y ago
requests is a wrapper around urllib3, which re-implements quite a bit.

chrismorgan 4y ago

No, actually. Of the direct dependencies, Python’s standard library has equivalents of regex (re), serde/serde_json (json), clap (argparse) and the boring half of textwrap (textwrap, which is only suitable for ASCII, and possibly curses providing a buggy and incomplete version of Unicode- and column-awareness, but I’m not sure of even that much, and I don’t think it’s properly cross-platform either), and some parts of crossterm (curses, of uncertain availability and reliability). But it completely lacks equivalents of most of crossterm and textwrap, and all of dirs and unicode-segmentation, providing in the latter two cases only functionality pretty much exactly equivalent to what Rust’s standard library contains. This is the sort of thing that I meant by “doing things properly rather than half-heartedly”. You could make something like this by reimplementing half the libraries in an inferior fashion, full of bugs, cross-platform inconsistencies and missing functionality. Or you can take an extra dependency. Even in Python, the recommendation would be firmly to add dependencies like appdirs for dirs and I dunno what for the rest.