PyCon 2024 showcased a number of ways to speed the pokey Python programming language including sub-interpreters, immortal objects, just-in-time compilation and more.
Yup, I guess not. But if I was on the product team, the customers and director ate the bosses. And on it goes up to the CEO, where the board and shareholders are the boss.
If I can justify the change, we’ll do it. That’s close enough for me. And I did do a POC w/ Rust and could’ve switched one service over, but I campaigned against myself since we got good enough perf w/ Python (numpy + numba) and I was the only one who wanted it. That has changed, so I might try again with another service (prob our gateway, we have 3 and they all kinda suck).
I’ll have to check out Deno again. I remember looking at it (or something like it) a couple years ago when first announced on Reddit.
Yeah I have yet to really use Deno in anger because so many people are like “but Python exists!” and unsurprisingly we now find ourselves with a mess of virtual environments and pip nonsense that has literally cost me weeks of my life.
Though if you’re using Numpy that source like “proper work” not the infrastructure scripting we use Python for so I probably would go with Rust over Deno. I don’t know of mature linear algebra libraries for Typescript (though I also haven’t looked).
IMO probably the biggest benefit of Rust over most languages is the lower number of bugs and reduced debugging time due to the “if it compiles it probably works” thing.
You don’t have to convince me that Rust rocks. I just need to convince my team that it’s worth the investment in terms of time to onboard everyone, time to port out application, and risk of introducing bugs.
We have a complex mix of CRUD, math-heavy algorithms, and data transformation logic. Fortunately, each of those are largely broken up into microservices, so they can be replaced as needed. If we decide to port, we can at least do it a little at a time.
The real question is, does the team want to maintain a Python or Rust app, and since almost nobody on the team has professional experience with low-level languages and our load is pretty small (a few thousand users; b2b), Python is preferred.
Yup, I guess not. But if I was on the product team, the customers and director ate the bosses. And on it goes up to the CEO, where the board and shareholders are the boss.
If I can justify the change, we’ll do it. That’s close enough for me. And I did do a POC w/ Rust and could’ve switched one service over, but I campaigned against myself since we got good enough perf w/ Python (numpy + numba) and I was the only one who wanted it. That has changed, so I might try again with another service (prob our gateway, we have 3 and they all kinda suck).
I’ll have to check out Deno again. I remember looking at it (or something like it) a couple years ago when first announced on Reddit.
Yeah I have yet to really use Deno in anger because so many people are like “but Python exists!” and unsurprisingly we now find ourselves with a mess of virtual environments and pip nonsense that has literally cost me weeks of my life.
Though if you’re using Numpy that source like “proper work” not the infrastructure scripting we use Python for so I probably would go with Rust over Deno. I don’t know of mature linear algebra libraries for Typescript (though I also haven’t looked).
IMO probably the biggest benefit of Rust over most languages is the lower number of bugs and reduced debugging time due to the “if it compiles it probably works” thing.
You don’t have to convince me that Rust rocks. I just need to convince my team that it’s worth the investment in terms of time to onboard everyone, time to port out application, and risk of introducing bugs.
We have a complex mix of CRUD, math-heavy algorithms, and data transformation logic. Fortunately, each of those are largely broken up into microservices, so they can be replaced as needed. If we decide to port, we can at least do it a little at a time.
The real question is, does the team want to maintain a Python or Rust app, and since almost nobody on the team has professional experience with low-level languages and our load is pretty small (a few thousand users; b2b), Python is preferred.