3 ms·

The first time I tried typing some Python code was a little experimental HTML generator, pure functional style, that used the keyword args dict as a kind of mis

The first time I tried typing some Python code was a little experimental HTML generator, pure functional style, that used the keyword args dict as a kind of miscellaneous grab-bag to pass functions and data to sub-functions. You set up a dict and called a top-level function with it and then it worked like a kind of template system, but again all through functions & applications of functions rather than "mail merge" of templates, etc. It was simple, elegant, perfectly cromulent Python code. However, there was no way to specify the type of the dicts because they were so heterogeneous. - - - - I have to say, I was a Python fan for ages, used it professionally for over a decade, so this isn't an outsider's opinion: Python is kind of over. It won't die any time soon, but it has been "improved" out of its sweet spot of applicability, and no longer has a compelling story for adoption going forward. Every niche Python is known for serving well now has even better options: - Rapid Application Development: Nim, Red - Readability: Go, Nim, D, Zig - Science: Julia - Large multi-dev projects: Java, Go - Systems programming (python glue): D, Rust, Zig - Web app backends: Erlang/Elixir And so on... Really, as much as I still love Python (and I do) the only things I feel it's appropriate for these days are small scripts that need to remain flexible (in other words, that are likely to be modified often), things that are too complex to be a CLI command, but less complex or more dynamic than, say, an email client or RSS reader. If the type domain of the program doesn't change rapidly or unpredictably then you don't need Python's dynamic typing. If you need static typing I think you should use a language that supports that out-of-the-box, not tacked on later.

oblvious-earth 5y ago
I think what is missing from all of those languages you suggest is them providing an intersection of those niches. Yes I am quite sure for any specific niche there is a language that is better suited than Python (though I would argue with a lot of your choices there). But let's say I want a readable language that is good at data science, web backend, and provides a system glue. Python handles that much better than all the others you mentioned. Also the one choice I am going to explicitly call out is Rust as a good systems glue language. In fact a very common practise I see now is all the good Rust libraries are getting Python bindings and made available on PyPI so all that power of Rust for systems programming can be used in Python as the glue language.
- carapace 5y ago
  You've got a point in re: Python being good enough for several niches. However, I think the set of people who want to do all those things but don't want to use multiple languages is pretty small, like it's a hobbyists' market, eh? A scientist typically wouldn't write web backend, a sysadmin doesn't do a lot of statistical stuff, etc. A small startup might do well to make their MVP in Python, but as the code grows the implicit costs (of using Python) do too. - - - - In re: Rust, sorry I wasn't clear above. I don't mean that Rust is a glue language, I mean that people write e.g. grep replacements in it and things like that. Python does systems programming by being glue, Rust does it by being, well, Rust. It makes sense to me that Rust libs would get Python wrappers, but it also seems to me that that adds to my argument: Python is good for small glue, but crunchy things (like grep) should be written in e.g. Rust or Go or something. (I feel I should mention in this connexion my favorite bit of obscure Python trivia: Python was originally meant to be the shell language of the Amoeba distributed OS! https://en.wikipedia.org/wiki/Amoeba_(operating_system) https://en.wikipedia.org/wiki/Amoeba_(operating_system) ) - - - - One other thing about Python is that the packaging & distribution "story" is ridiculous now. The people in charge of that call themselves the Python Packaging Authority (which name, given what they're doing, reminds me of Brazil the movie) and they seem to me to be running amok, cargo-culting the crap out of what should be a pretty simple and straightforward problem. I could go on but I feel a rant brewing, so I'll cut it off there. It's not just the PyPA folks that are having problems packaging and distributing Python. The Conda folks ship Tkinter in a broken state for five years now: https://github.com/ContinuumIO/anaconda-issues/issues/6833 https://github.com/ContinuumIO/anaconda-issues/issues/6833 That's the default GUI system that's in the Python Standard Library. Compare and contrast with Rust's Cargo, or Nim's Nimble, or Erlang's Rebar, etc.
cb321 5y ago
Nim is a systems programming language [1] just with very decent ergonomics. Interfacing to C/C++ is trivial (just a declaration) and to others (e.g. Rust) is possible. E.g., there is code that interfaces to a custom Linux kernel module for fast file tree walking. [2] { That same github account has several other "systems programming in Nim projects" - low overhead syslogd, color ps/color top, ls, fast symspell/edit distances, a prototype search engine, an alternative to on-disk protobuffers with online random access, etc. There are also a lot over at https://github.com/treeform https://github.com/treeform and surely many others. } You can also export Nim impls to Python easily, though I very much agree Python's time in the sun is over (and I say this having been a user since ~1993). It now seems more a generator of problems/complexity than of simplifying solutions. Nim can also compile to Javascript letting you do both front- & back-ends in Nim. Science is an almost unbounded fractal set of human investigations. Nim is usable for science (e.g. ask questions here [3]), but the ecosystem is undeniably much smaller than Julia or Python's. (Julia's is much smaller than Python's, and for some things R can be much bigger, actually.) So, a "depends what you need" caveat just has a much stronger "caveat force" here. What "large, multi-dev" needs is honestly harder to say/more subjective/maybe manager-subjective. If it is "cheap, just out of school programmers with which to replace expensive, departing mess-makers", I think Java may have always had more plentiful options than Python. ;-) This is closer to a human-organization-complete kind of concern and almost intrinsically "very dependent upon circumstances/context". I just didn't want to ignore it. At least Stefan Salewski [4] thinks Nim is suitable or teaching people introductory programming, though. [1] https://nim-lang.org/ https://nim-lang.org/ [2] https://github.com/c-blake/cligen/blob/master/cligen/dents.nim#L073 https://github.com/c-blake/cligen/blob/master/cligen/dents.n... [3] https://app.element.io/#/room/#nim-science:envs.net https://app.element.io/#/room/#nim-science:envs.net [4] https://ssalewski.de/nimprogramming.html https://ssalewski.de/nimprogramming.html
coward123 5y ago
Your post fits with a conversation I had with someone last week, so let me ask - why would you choose Erlang / Elixir over Python for web backends? I've got my reasons for both camps, but since you point out the above information I'd love to hear your thoughts.
- carapace 5y ago
  The semantics of the BEAM VM and Erlang Run-Time System (ERTS) are much closer to the typical semantics of a large dynamic web app backend than those of Python. No surprise there, it was designed to support telephone exchanges. It provides facilities natively that have to be "bolted on" to Python. I might still write a prototype or proof-of-concept web app in Python, but for anything more serious it seems to me that the advantages of Erlang loom large (and that's before you get to Phoenix LiveView: https://www.phoenixframework.org/ https://www.phoenixframework.org/ )
digisign 5y ago
"No one goes there anymore, it's too crowded." Silly, Python was always second-best at everything and promoted as a prototyping language from the beginning. But that's more powerful than you've given credit for. You get extreme productivity up front, and a growing number of exit strategies for the fraction of projects that outgrow it.
- carapace 5y ago
  FWIW, I still use Python as a prototyping language, it's just so flexible and you can model things in it in so many neat ways. > a growing number of exit strategies for the fraction of projects that outgrow it. I like that formulation. Cheers!
azth 5y ago
I wouldn't put golang under readability nor Large multi-dev projects, it fails spectacularly on both counts.

oblvious-earth 5y ago

I think what is missing from all of those languages you suggest is them providing an intersection of those niches. Yes I am quite sure for any specific niche there is a language that is better suited than Python (though I would argue with a lot of your choices there). But let's say I want a readable language that is good at data science, web backend, and provides a system glue. Python handles that much better than all the others you mentioned. Also the one choice I am going to explicitly call out is Rust as a good systems glue language. In fact a very common practise I see now is all the good Rust libraries are getting Python bindings and made available on PyPI so all that power of Rust for systems programming can be used in Python as the glue language.

carapace 5y ago
You've got a point in re: Python being good enough for several niches. However, I think the set of people who want to do all those things but don't want to use multiple languages is pretty small, like it's a hobbyists' market, eh? A scientist typically wouldn't write web backend, a sysadmin doesn't do a lot of statistical stuff, etc. A small startup might do well to make their MVP in Python, but as the code grows the implicit costs (of using Python) do too. - - - - In re: Rust, sorry I wasn't clear above. I don't mean that Rust is a glue language, I mean that people write e.g. grep replacements in it and things like that. Python does systems programming by being glue, Rust does it by being, well, Rust. It makes sense to me that Rust libs would get Python wrappers, but it also seems to me that that adds to my argument: Python is good for small glue, but crunchy things (like grep) should be written in e.g. Rust or Go or something. (I feel I should mention in this connexion my favorite bit of obscure Python trivia: Python was originally meant to be the shell language of the Amoeba distributed OS! https://en.wikipedia.org/wiki/Amoeba_(operating_system) https://en.wikipedia.org/wiki/Amoeba_(operating_system) ) - - - - One other thing about Python is that the packaging & distribution "story" is ridiculous now. The people in charge of that call themselves the Python Packaging Authority (which name, given what they're doing, reminds me of Brazil the movie) and they seem to me to be running amok, cargo-culting the crap out of what should be a pretty simple and straightforward problem. I could go on but I feel a rant brewing, so I'll cut it off there. It's not just the PyPA folks that are having problems packaging and distributing Python. The Conda folks ship Tkinter in a broken state for five years now: https://github.com/ContinuumIO/anaconda-issues/issues/6833 https://github.com/ContinuumIO/anaconda-issues/issues/6833 That's the default GUI system that's in the Python Standard Library. Compare and contrast with Rust's Cargo, or Nim's Nimble, or Erlang's Rebar, etc.

cb321 5y ago

Nim is a systems programming language [1] just with very decent ergonomics. Interfacing to C/C++ is trivial (just a declaration) and to others (e.g. Rust) is possible. E.g., there is code that interfaces to a custom Linux kernel module for fast file tree walking. [2] { That same github account has several other "systems programming in Nim projects" - low overhead syslogd, color ps/color top, ls, fast symspell/edit distances, a prototype search engine, an alternative to on-disk protobuffers with online random access, etc. There are also a lot over at https://github.com/treeform https://github.com/treeform and surely many others. } You can also export Nim impls to Python easily, though I very much agree Python's time in the sun is over (and I say this having been a user since ~1993). It now seems more a generator of problems/complexity than of simplifying solutions. Nim can also compile to Javascript letting you do both front- & back-ends in Nim. Science is an almost unbounded fractal set of human investigations. Nim is usable for science (e.g. ask questions here [3]), but the ecosystem is undeniably much smaller than Julia or Python's. (Julia's is much smaller than Python's, and for some things R can be much bigger, actually.) So, a "depends what you need" caveat just has a much stronger "caveat force" here. What "large, multi-dev" needs is honestly harder to say/more subjective/maybe manager-subjective. If it is "cheap, just out of school programmers with which to replace expensive, departing mess-makers", I think Java may have always had more plentiful options than Python. ;-) This is closer to a human-organization-complete kind of concern and almost intrinsically "very dependent upon circumstances/context". I just didn't want to ignore it. At least Stefan Salewski [4] thinks Nim is suitable or teaching people introductory programming, though. [1] https://nim-lang.org/ https://nim-lang.org/ [2] https://github.com/c-blake/cligen/blob/master/cligen/dents.nim#L073 https://github.com/c-blake/cligen/blob/master/cligen/dents.n... [3] https://app.element.io/#/room/#nim-science:envs.net https://app.element.io/#/room/#nim-science:envs.net [4] https://ssalewski.de/nimprogramming.html https://ssalewski.de/nimprogramming.html

coward123 5y ago

Your post fits with a conversation I had with someone last week, so let me ask - why would you choose Erlang / Elixir over Python for web backends? I've got my reasons for both camps, but since you point out the above information I'd love to hear your thoughts.

carapace 5y ago
The semantics of the BEAM VM and Erlang Run-Time System (ERTS) are much closer to the typical semantics of a large dynamic web app backend than those of Python. No surprise there, it was designed to support telephone exchanges. It provides facilities natively that have to be "bolted on" to Python. I might still write a prototype or proof-of-concept web app in Python, but for anything more serious it seems to me that the advantages of Erlang loom large (and that's before you get to Phoenix LiveView: https://www.phoenixframework.org/ https://www.phoenixframework.org/ )

digisign 5y ago

"No one goes there anymore, it's too crowded." Silly, Python was always second-best at everything and promoted as a prototyping language from the beginning. But that's more powerful than you've given credit for. You get extreme productivity up front, and a growing number of exit strategies for the fraction of projects that outgrow it.

carapace 5y ago
FWIW, I still use Python as a prototyping language, it's just so flexible and you can model things in it in so many neat ways. > a growing number of exit strategies for the fraction of projects that outgrow it. I like that formulation. Cheers!

azth 5y ago

I wouldn't put golang under readability nor Large multi-dev projects, it fails spectacularly on both counts.