Hacker News Reader

Comment by fnord123 | Hacker News Reader

>JS with JIT is waaay faster than Python. Not “between python and java” as purported.

You are correct that JS is not between Python and Java. Python is faster than Java which is faster than JS. Though some people seem to think calling APIs written in C is "not Python" but if the ecosystem provides the library and I call it from Python then it's Python enough for me!

View on HN

By that logic, Python, Javascript, and Java are all the same speed, just call out to C, or assembly perhaps if you really want to tune some code.

No, not at all. Java FFI is extremely expensive.

Yeah. And so is JS’s. I think CPython’s design makes it a champ at native interop and a loser at pure compute perf. That’s a valid trade off for lots of important situations.

Are you referring to V8's/Node's C FFI? Why is that extremely expensive?

It's not a trade-off. There's no reason why you can't have a blazing fast and expressive language that also has good C FFI. A single good programmer could make a language that was as expressive as Python (that is, not very), faster, and with a good C FFI in under 6 months.

Aren't you saying it's possible to make a perfect language with no tradeoff, and all that in just 6 months?

No I'm saying it's easy to make a language better than Python in six months.

Then where is it?

You couldn’t be more wrong. Java and JS have expensive FFI because of the specific costs of synchronizing the VM entry/exit with the GC and JITs.

What you're implying is that the "speed" of a language is purely defined by the speed of the C FFI? This view is absolutely ridiculous and I don't think you would find a single other programmer on this green earth that would agree with you.

I think everyone agrees that when they want to do some data analysis they pip install numpy and get to work. It's only the navel gazers who are concerned about cpythons performance instead of treating python as a 'race to C' wherever performance is concerned.

Get used to this approach since it crops up everywhere. If you target a gpu, you try to keep the work in the gpu. When we move to use bpf and io_uring things will be a race to the next kernel program. If you target the CPU then your code is a race to C or a race to the function that calls the relevant cpu instruction that will make your code fly.

Reply on news.ycombinator.com