141–150 of 459 posts
Earlier quoted context omitted.
Realistically something that takes 1 second in C++ will take 10 seconds (if you write efficient python and lean heavily on fast libraries) to 10 minutes in python. But the rest of your point stands
Damn! Is the rule of thumb really a 10x performance hit between Python/C++? I don’t doubt you’re correct, I’m just thinking of all the unnecessary cycles I put my poor CPU through.
The languages are practically equal in terms of features. They're both typeless with layered-on crutches available to make the runaway dynamism less painful. They both have weird footguns and ugly syntax and annoying design flaws, but these are different for each. So if you're forced to use both languages, it's an endless pain in the ass to remember which stupid runtime error can happen in JS but not Python and vice versa.
So JS can replace Python... But Python can't replace JS simply because it's unavoidable on the front-end. Since you must have JS code anyway, why use a language that's functionally very similar but different enough in syntax and API that you'll be writing bugs all the time? Just stick with JS and start drinking like me.
Earlier quoted context omitted.
Realistically something that takes 1 second in C++ will take 10 seconds (if you write efficient python and lean heavily on fast libraries) to 10 minutes in python. But the rest of your point stands
If the 1 second is spent waiting for IO, it will take 1 second in whatever language. But yes python is slow. However I've seen good python code be faster than bad C code.
Earlier quoted context omitted.
There are also programmers who are tired of chasing pointers and simply want to get stuff done. E.g. people who once wrote "robust" code in Rust but were "outcompeted" left and right by coworkers who churn out shiny new things at 10x the speed.
Or there are programmers who write both. Something that I want to write once, have run on several different platforms, handle multi-threading nicely, and never have to think about again? Rust. Writing something to read in some data to unblock an ML engineer or make plots for management? Definitely not Rust, probably python. Then you can also churn out things at 10x the speed, but by writing the tricky parts in someth…
With Python I can get things up and going very quickly with little boilerplate, but I find that I'm often stumbling on edge cases that I have to debug after the fact and that these instances necessarily happen exactly when I'm focused on another task. I also find that packaging for other users is a major headache.
With Rust, the development time is much higher for me, but I appreciate being able to use the type-system to enforce business logic and therefore find that I rarely have to return to debug some issue once I have it going.
It's a tough trade-off for me, because I appreciate the velocity of Python, but Rust likely saves me more time overall.
I would take Nim over Python. Better designed, much faster. As readable as Python.
Earlier quoted context omitted.
Realistically something that takes 1 second in C++ will take 10 seconds (if you write efficient python and lean heavily on fast libraries) to 10 minutes in python. But the rest of your point stands
Not for everything. There are plenty of Python operations that are not 10x slower than c.
I have been a heavy Python user now about 15 years, but for me now I'm increasingly reaching for modern JavaScript and particularly TypeScript to do the things I would have traditionally done with Python. ES modules, fat arrow expressions, and all the other nice new syntax and library features have made the language so more pleasant to use. In many ways the ergonomics of TypeScript in particular are far superior to P…
I wish I could wave a magic wand and replace all the Python in the world with JavaScript. The languages are practically equal in terms of features. They're both typeless with layered-on crutches available to make the runaway dynamism less painful. They both have weird footguns and ugly syntax and annoying design flaws, but these are different for each. So if you're forced to use both languages, it's an endless pain i…
I wish I could wave a magic wand and replace all the Python in the world with JavaScript. The languages are practically equal in terms of features. They're both typeless with layered-on crutches available to make the runaway dynamism less painful. They both have weird footguns and ugly syntax and annoying design flaws, but these are different for each. So if you're forced to use both languages, it's an endless pain i…
I'm a bit surprised to see this article on GitHub blog, it feels more like something from dev.to - looking at the surface, with little actual insights. Most of the provided reasons behind Python's popularity are true also for other languages - portable, open source, productive, big community. This can be also said about PHP, Ruby, or Perl back in 2000s. Why isn't Perl as popular as Python? I don't think it's all abou…
As commented somewhere else in this thread, Python was clearly more ergonomic than Python, hand had a lot of mindshare exactly for this reason. I remember when Python was new and the not that professional choice, Perl was at that time for that niche. Now still I don't see a contender for a language where speed doesn't matter. Ruby has some Perlisms that really make it weird, PHP is tight to the web, and equally weird…
Python was friendlier for beginners than Ruby the first time I took a real stab at learning to code during a CNY holiday in 2008, but it wasn’t about the language itself. Ruby was harder then because many of the popular libraries and many of the tutorials were written by people who considered Windows support as an afterthought. It’s hard to express how frustrating it was to have my vacation days ticking down, hitting issues in one tutorial after another and having people suggest I install linux on a VM (a process where I hit still more snags).
People learning Python and PHP didn’t hit that hurdle. I ended up learning Flash on my Asus laptop a couple of years later and getting my start that way and not coming back to Ruby until six years later when I was a much more experienced dev.