ProgrammerHumor
notCommonYetInteresting
Discussion
hey ChatGPT, rewrite my iOS app in rust.
That’s a great idea, Rust is blazingly fast and offers industry leading memory and thread safety. It’s decisive decisions like this that make you such a brilliant engineer.
I hate how accurate this is
It's not just blazingly fast — it's also thread safe by default.
Suspicious em dash
Very suspicous indeed.
Did you use chatgpt to write this comment? I refuse to believe this is handwritten
My comment is 100% natural
Here's a version I asked ChatGPT to write for comparison:
That’s an inspired decision—rewriting the iOS app in Rust shows exactly the kind of visionary engineering that sets you apart. Rust’s speed and unmatched safety model make it the perfect choice, and only someone with your technical brilliance would have the foresight to pull it off.
``` int ret = system("python main.py");
```
Haha C++ fast Python slow so funny
You forgot to add some unnecessary whitespace to your comment
At least they did not add superfluous braces to it
```
Haha
C++: fast()
Python: slow()
execute_big_funni() ```
Future considerations: Expanding method to execute_funni() passing in the size as an Enum
It does segfault almost immediately. But it's fast, don't you agree?
Wow, so interesting. Definitely haven't seen this one before.
The fastest things on earth .. to fail
It fails 10x faster and I've never seen the cli outputting so many mistakes so fast. Thing's going great.
It fails very quickly if we ignore compile time.
Of all the things that never happened, this never happened the most
I once wrote a program in python to find the Nth fibonacci number in log (N) time (and using arbitrary precision integers which are the default in Python). It took a full minute to compute the 20000th fibonacci number.
I did the same program in C++ with Boost multiprecision integer library (boost::multiprecision::cpp_int). Took 8 seconds. Then I did it again but in addition with GNU Multiprecision library (boost::multiprecision::mpz_int). Took 109 milliseconds.
This meme is quite real for CPU bound jobs. If you deal mostly in I/O and database processing then go ahead in Python.
Also, if your problem is math and you don't need absurdly high integers (so no Fibonacci, sorry), just adding a @numba.njit brings you a lot of the way to the performance of C with minimal effort.
I enjoy the implication that planes fly at 2/3 the speed of light
skill issue
Several memory leaks later…
You can still leak in GC languages.
Downvoted for speaking the truth. You aren’t suddenly immune to memory issues by switching to python. There’s a multitude of easy ways to create a memory leak in python.
Python is known for its memory safety that’s why critical devices use it exclusively.
Had to bruteforce something for a ctf challenge. 229 combinations. Only took 20 seconds with golang single-threaded.
Somebody said his python implementation took 80 mins... (althrough that might have been shitty coding).
That many iterations in pure python? Yeah I'd believe it tbh. Python just isn't built to do that kind of thing. I do some computational physics type stuff, and I once did a comparison between an integral done with numpy's sum() and with a pure python nested for loop, and numpy took milliseconds while the pure python took minutes. Probably a library out there that can do it for you, as that's the true python way.
Nowadays is mostly Rust😉
Was it worth it, though?
Something something BLAZINGLY fast
Have a question for the other devs, so will migrating from python to c# be a good strategy to make it faster? It's Az fn apps with APIs in them
If the program is CPU bound, maybe.
If it is I/O bound, definitely not.
(Assuming the dev coded it properly)
It would speed up CPU bound tasks being run in pure python - if it's IO bound / library bound* it won't make a noticeable difference.
*I can't think of a better term - many widely used Python libraries (such as numpy) are written in a low-level languages, and perform about as well (often better, as they tend to be very well optimised).
Daring today, aren't we?