271–280 of 460 posts
Earlier quoted context omitted.
When you only have so many hours to go around, you concentrate on the main goals.
My point is that you can write fast code just as easily as you can write slow code. So engineers should write fast code when possible. Obviously you can spend a lot of time making things faster, but that doesn't mean you can't be fast by default.
Earlier quoted context omitted.
> Of course one wonders why they haven't been a low-hanging fruit over the past 25 years. Because it's developed and maintained by volunteers, and there aren't enough folks who want to spend their volunteer time messing around with assembly language. Nor are there enough volunteers that it's practical to require very advanced knowledge of programming language design theory and compiler design theory as a prerequisite…
> Because it's developed and maintained by volunteers Who is working on python voluntarily? I would assume that, like the Linux kernel, the main contributors are highly paid. Certainly, having worked at Dropbox, I can attest to at least some of them being highly paid.
Earlier quoted context omitted.
JavaScript doesn't really have C extensions like Python has. PyPy did implement a JIT for Python, and it worked really well, until you tried to use C extensions.
That’s what I meant, if JavaScript hadn’t been trapped in the browser and allowed to call C, maybe there wouldn’t have been so much investment in making it fast. But still, it’s kind of surprising that PHP has a JIT and Python doesn’t (official implementation I mean, not PyPy).
Earlier quoted context omitted.
> I don't see how "asyncio is annoying and can only be used for a fraction of scenarios everywhere else too, not just here" is anything other than reinforcement of what I said. Well, I didn't try to refute what you wrote (for one, it's clearly a personal, subjective opinion). I asked what I've asked merely to clarify whether your issue is with Python's asyncio (e.g. Python got it wrong) or with the tradeoffs inherent…
> I've asked merely to clarify whether your issue is with Python's asyncio (e.g. Python got it wrong) or with the tradeoffs inherent in async io APIs in general (regardless of Python) Both, but the latter part is contextual. > I, for one, am fine with async APIs in JS Correct me if you think I'm wrong, but JS in its native environment (the browser) never had access to the OS thread and process scheduler, so the conce…
One of the biggest features I'm looking forward to is the more specific error messages. I can't tell you how much time I've wasted with cryptic errors that just point to a line that has a list comprehension or similar.
I've been learning Rust recently. There are a number of things about the language that I dislike, but its error messages are an absolute joy. They clearly put an incredible amount of effort into them, and it really shows.
When you get an error there's a verbose explanation you can ask for, which describes the problem, gives example code and suggests how you can fix it. The language has a longer ramp-up period because it contains new paradigms, so little touches like this help a lot in onboarding new devs.
Earlier quoted context omitted.
It depends how you see it https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
This is exactly why Go is a better option for async use cases.
I just learned today that python is 100x slower than C. I have severely lost respect for python.
I just learned today that python is 100x slower than C. I have severely lost respect for python.