←back to thread

160 points todsacerdoti | 3 comments | | HN request time: 0s | source
Show context
jpalawaga ◴[] No.41898791[source]
Anyone who has done a programming contest, advent of code, etc knows that the language doesn’t matter so much as your algorithm.

Yes, the language can bring a nice speed up, or might give you better control of allocations which can save a lot of time. But in many cases, simply picking the correct algorithm will deliver you most of the performance.

As someone who doesn’t JavaScript a lot, I’d definitely prefer a tool written in go and available on brew over something I need to invoke node and its environment for.

replies(12): >>41898816 #>>41898879 #>>41898890 #>>41898952 #>>41899000 #>>41899028 #>>41899401 #>>41901158 #>>41901185 #>>41901525 #>>41902030 #>>41904514 #
tyree731 ◴[] No.41898816[source]
Lots of very smart people have worked very hard on Python tools written in Python, yet the rust rewrites of those tools are so much faster. Sometimes it really is the programming language.
replies(6): >>41898834 #>>41898859 #>>41898913 #>>41898949 #>>41899003 #>>41899226 #
1. jvanderbot ◴[] No.41898913[source]
This is a very nice counterexample, but it's not actually a counter example without an example.

Also, this was a thing before Rust. I've rewritten several things in C or Cpp for python back ends, and most pytbon performance-critical code is already an API to a shared library. You'd be surprised to run OR tools and find Fortran libraries loaded by your python code.

replies(1): >>41898995 #
2. runesoerensen ◴[] No.41898995[source]
Ruff is one example https://astral.sh/ruff
replies(1): >>41902025 #
3. aragilar ◴[] No.41902025[source]
But can I write plugins for it? My understanding it is only implements a subset of the common plugins (and does not do any of the linting that pylint is useful for), so it avoids scanning the filesystem for plugins?