4 ms·

It seems like this could depend on what is already in your tool belt. If I want productivity, I use Python. If I want raw speed and low overhead, there's Rust

It seems like this could depend on what is already in your tool belt. If I want productivity, I use Python. If I want raw speed and low overhead, there's Rust. So Go ends up eclipsed on both sides.

zellyn 9y ago
Hmmm. If you know Rust well already, sure. But both Go and Rust have a much better binary a distribution story than Python once you stray from the standard library...
skybrian 9y ago
There's another dimension to this: how big is the codebase you have to maintain? This is a "pets versus cattle" thing. If you like artistically crafting small bits of code, Python may work fine. If you're building something to last and need to shovel large amounts of code around while migrating API's, a statically typed language with a fast compiler will do more to help. Python in the large is not very maintainable. I expect that a Rust codebase will eventually be pretty nice to maintain, after the tooling matures more. Currently, Go is probably easier, and quicker to write.
- deleted 9y ago
  [deleted]
- baq 9y ago
  side note: check out mypy for a powerful type system in Python; i'm a happy user in a largeish project for a year or so and it really works.
- depressedpanda 9y ago
  > Python in the large is not very maintainable. Could you elaborate on that? I hear this a lot, but I work on a large Python project, and I don't think it is hard to maintain. We do have some strict requirements, though: 1. Test coverage; if it's testable there must be tests for it 2. Type hinting; for large projects it's actually really nice to know at a glance what the expected type is 3. PEP8 & Pylint; how we write code should be standardized and easy for others to read
  - skybrian 9y ago
    Well, (2) seems important and uncommon for Python in my experience, but it's been a while. Maybe it's more common these days? Here's the sort of scale I'm thinking of: consider a company with many teams, many apps, and many shared libraries. Some of the apps and libraries won't have anyone working on them, because it's generally not the case that a company is willing to fund maintenance forever on everything; people need to drop them for a while (to work on more important stuff) and someone else will come back to them later. (This is being "walk-away friendly".) Suppose you need to fix a security bug in a shared library and update all the apps, most of which you haven't seen before. How easy is that to do?
- Walkman 9y ago
  > Python in the large is not very maintainable. Yes, very much it is. It just need good developers, not only juniors...

It seems like this could depend on what is already in your tool belt. If I want productivity, I use Python. If I want raw speed and low overhead, there's Rust. So Go ends up eclipsed on both sides.

zellyn 9y ago

Hmmm. If you know Rust well already, sure. But both Go and Rust have a much better binary a distribution story than Python once you stray from the standard library...

skybrian 9y ago

There's another dimension to this: how big is the codebase you have to maintain? This is a "pets versus cattle" thing. If you like artistically crafting small bits of code, Python may work fine. If you're building something to last and need to shovel large amounts of code around while migrating API's, a statically typed language with a fast compiler will do more to help. Python in the large is not very maintainable. I expect that a Rust codebase will eventually be pretty nice to maintain, after the tooling matures more. Currently, Go is probably easier, and quicker to write.

deleted 9y ago
[deleted]
baq 9y ago
side note: check out mypy for a powerful type system in Python; i'm a happy user in a largeish project for a year or so and it really works.
depressedpanda 9y ago
> Python in the large is not very maintainable. Could you elaborate on that? I hear this a lot, but I work on a large Python project, and I don't think it is hard to maintain. We do have some strict requirements, though: 1. Test coverage; if it's testable there must be tests for it 2. Type hinting; for large projects it's actually really nice to know at a glance what the expected type is 3. PEP8 & Pylint; how we write code should be standardized and easy for others to read
- skybrian 9y ago
  Well, (2) seems important and uncommon for Python in my experience, but it's been a while. Maybe it's more common these days? Here's the sort of scale I'm thinking of: consider a company with many teams, many apps, and many shared libraries. Some of the apps and libraries won't have anyone working on them, because it's generally not the case that a company is willing to fund maintenance forever on everything; people need to drop them for a while (to work on more important stuff) and someone else will come back to them later. (This is being "walk-away friendly".) Suppose you need to fix a security bug in a shared library and update all the apps, most of which you haven't seen before. How easy is that to do?
Walkman 9y ago
> Python in the large is not very maintainable. Yes, very much it is. It just need good developers, not only juniors...