←back to thread

Unexpected productivity boost of Rust

(lubeno.dev)
517 points bkolobara | 2 comments | 27 Aug 25 15:48 UTC | HN request time: 0.002s | source
Show context
koakuma-chan ◴[27 Aug 25 16:22 UTC] No.45041723[source]▶
I encourage every one to at least stop writing code in Python.
replies(5): >>45041794 #>>45041941 #>>45042073 #>>45043031 #>>45049992 #
lynndotpy ◴[27 Aug 25 18:13 UTC] No.45043031[source]▶
Pythons power is in the REPL. It's good for when you want to do something ad-hoc that's too much for Bash or a graphing calculator. It has a large enough ecosystem that you can make a PoC for basically anything in a day.

It's really, really good for <1000 LoC day projects that you won't be maintaining. (And, if you're writing entirely in the REPL, you probably won't even be saving the code in the first place.)

replies(1): >>45043325 #
love2read ◴[27 Aug 25 18:37 UTC] No.45043325[source]▶
the problem is that when you write enough <1kloc projects, a couple of them are useful enough to stay used in which case you are now maintaining python in prod.
replies(3): >>45043501 #>>45044951 #>>45049949 #
hnaccount_rng ◴[27 Aug 25 18:52 UTC] No.45043501[source]▶
Yes but the alternative is "not having those projects at all" not "having them in a 'better' language"
replies(1): >>45044244 #
1. love2read ◴[27 Aug 25 19:48 UTC] No.45044244[source]▶
Of course not, the alternate is writing these projects in a more maintainable language
replies(1): >>45048545 #
2. noisy_boy ◴[28 Aug 25 05:00 UTC] No.45048545[source]▶
Or writing them in whatever language gets you going quickly and rewrite the "successful" ones in a more safe language like Rust. Of course write test cases for those ones first and then use LLM help to migrate them, including tests, to a safer language. Problem happens when the velocity of changes is too much and/or there is no appetite for migration - those are a different category of problem.

The ideal scenario is what you are saying but most of the time it boils down to deadline vs familiarity/skill (of the developer and the team) trade-off.