311–320 of 459 posts
I branched out to C++ and other languages to stay above the curve. Python is becoming like english, required to know, and not really a deep skillset employers are looking for now.
Earlier quoted context omitted.
I use mostly Python, and a bit of Rust. With Python, testing, good hygiene and a bit of luck you can write core that is maybe 99% reliable. It is very, very hard to get to (100-eps)% for eps Anything else, especially if there isn't a huge premium on speed, meh - Python is almost always sufficient, and not in the way.
I use the same combo: lots of Python to analyse problems, test algos, process data, etc. Then, once I settle on a solution but still need more performance (outside GPU's), I go to rust.
Earlier quoted context omitted.
This is just a property of having libraries. If you've got the same libraries in Java then the code looks identical except that you stick to word "var" in front of lines 4 and 6 and you don't have named arguments. Python does have a great data processing ecosystem. But that isn't really a property of the language.
Creating a new venv, installing a few needed libraries that you know the names of with a simple command and writing a quick low-ceremony script that uses those libraries is frictionless in Python. Doing that repeatedly in nearly every other major language is not as easy. Some languages have a good integrated tool chain (Rust, Go) but are not as approachable and forgiving. Some are approachable but lack the friction-f…
Someone else identified Ruby's fatal flaw as not having good C tooling, and I think that's probably accurate.
Earlier quoted context omitted.
A bit off topic, but what would you use for data "mangling"? Like joining csvs on complex conditions, cleaning tables etc. Pandas seems to be the wrong tool for this, but I still often find myself using it as in contrast to something like Excel, my steps are at least clearly documented for future use or verification.
I still use perl for some of that stuff, or even awk, but those are barely reusable or readable.
Earlier quoted context omitted.
I completely agree - but you say that like it's a bad thing. I work as a developer alongside data scientists, who might have strong knowledge of statistics or machine learning frameworks rather than traditional programming chops. For the most part they don't need to know about concurrency, memory efficiency etc, because they're using a library where those issues have been abstracted away. I think that's what makes py…
> without having to take on a whole bunch of the footguns that would come from working directly in a language like c++ or Rust. Don't forget the footguns of working with developers who do those things. Ask them to do something simple and you get something complex and expensive after months of back and forth about what is wanted. You're likely to a framework for a one off SQL query. I hear it being said already, "You'…
This whole take assumes bad intention on both sides. Nobody's job is easy in this situation. Leadership's job is to set everyone up for success. If things go off the rails and end up with months of back and forth leading to nobody being happy despite good intentions and honest effort, then the problem lies with leadership.
Earlier quoted context omitted.
I fully agree with the description. What worries me, though, is that the features that make Python quite good at prototyping make it rather bad at auditing for safety and security. And we live in a world in which production code is prototyping code, which means that Python code that should have remained a quick experiment – and more often than not, written by people who are not that good at Python or don't care about…
I sometimes think about what Python would be like if it were written today, with the hindsight of the last thirty years. Immutability would be the default, but mutability would be allowed, marked in some concise way so that it was easy to calculate things using imperative-style loops. Pervasive use of immutable instances would make it impossible for libraries to rely on mutating objects a la SQLAlchemy. The language…
Earlier quoted context omitted.
At some point, every engineer has heard this same argument but in favor of all kinds of dubious things such as emailing zip files of source code, not having tests, not having a build system, not doing IaC, not using the type system, etc. I'm sure Rust was the wrong tool for the job in your case but I find this type of get shit done argument unpersuasive in general. It overestimates the value of short-term delivery an…
> It overestimates the value of short-term delivery For an early stage start up this is almost the only relevant factor for success.
> underestimates how quickly an investment in doing things "the right way" pays off.
What time horizon should a startup optimize delivery for? Minutes, hours, days, weeks? Say you're a startup dev in a maximalist "get shit done now" mindset so you're skipping types, tests, any forethought or planning so you can get the feature of the week done as fast as possible. This makes you faster for one week but slower the week after, and the week after, and the week after that.
Say a seed stage startup aims for 12 months runway to achieve some key outcomes. That's still a marathon. It still doesn't make sense to sprint the first 200 meters.
One thing I’d add to this conversation, though I’m certain it’s already been stated: As many have mentioned, there is a large subset of the user base that uses Python for applied purposes in unrelated fields that couldn’t care less about more granular aspects of optimization. I work as a research assistant for international finance faculty and I would say that compared to the average Hackernews reader, I’m technologi…
This was already posted at https://news.ycombinator.com/item?id=35000415 , I don't know why it didn't detect the duplicate. I'll repost my comment from there: This is a strange article. It's got the talking point about Python that we were hearing about 10 years ago - "tired of those pesky curly brackets in Java, try this new language you might not have heard of: Python!". Who reading the GitHub blog has not heard of…
The GitHub blog became a strange place recently(-ish). It went from a factual blog describing fancy new GitHub features and interesting technical stuff (as it was a decade ago) to mostly a place full of incoherent marketing fluff like this post (with some real technical content interspersed).
I just wish that I enjoyed using it. I've been doing a fair amount of Python work over the years because it's been required by my employers, but to be honest, I kind of hate it. I think the thing I hate the most about it is that white space is significant. It's like we travelled back in time to the early days, and picked up one the bad things about them and brought it back. I find that makes it more difficult for me…
If you’re having trouble with them, use a programmer's editor with indentation guides like notepad++ or geany. These are considered basic features these days.
Other simple things which reduce Python annoyances are tools like pyflakes and the blue formatter.