Live data from Hacker News

Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust

benchmarksgame.alioth.debian.org

41–50 of 132 posts

Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust

#41
post #8

So PHP is faster on most of those test than python or ruby ? I'm I missing something ? I thought everyone hating PHP ( also) because it was slow.

It's slow to develop with, which is a much more costly problem.

As slow as it might be to develop something from scratch in c++, perhaps. But, if you're using a framework and/or good libraries, all of that underlying work and ecosystem is standardized for you. Now, the ecosystem with things like Symfony are really great.

Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust

#42
post #8

So PHP is faster on most of those test than python or ruby ? I'm I missing something ? I thought everyone hating PHP ( also) because it was slow.

Nobody that I'm aware of has ever hated PHP because it was slow. They hated it for a variety of other reasons.

Many of them covered in: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust

#43

Earlier quoted context omitted.

There's plenty to not like about JS, but being interpreted and not having integers or arrays is not high on its negatives list. The little bit of good far outweighs the whole lot of bad. If you don't enjoy JS, it's because you haven't taken the time to learn what's great about it and have gotten hung up on the stupid things other people do with it or you're copying their mistakes.

I don't know, I rank not having integers pretty high on the list of faults. Wasn't there just a huge debacle with node being unable to represent inodes properly?

The inodes thing was about lack of 64-bit ints specifically. As I understand it, it was a bug where Node converted inode values to floats (instead of using strings or pairs of 32-bit ints or whatever). One could argue that the bug wouldn't have happened if JS had 64-bit ints, but anyway it's not a foundational thing.

The performance implication of JS not having ints is a different matter. In practice, if you write code that treats a variable like an int, modern JS engines will correctly compile that into bytecode where it really is an int, and performance will be as expected.

So the lack of an int type doesn't really hurt performance, though one can argue that it makes it harder to write performant code.

Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust

#44
I see that the point of this site is supposed to be that a change in implementation (keeping the language itself held constant) greater affect on performance than rewriting in another language.

My problem with this site it makes poor support of that claim. The data is hidden behind loads of links, and none of the data is visualized at all. Even a few simple bar charts, keeping the hierarchy of the site otherwise unchanged would vastly aid comprehension. The points being made would come across much more easily.

This sort of data is the poster child for visualization, yet this site relegates the data to tables of numbers.

Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust

#46

Earlier quoted context omitted.

I program in Go and JavaScript, but don't enjoy it. I assure you that JavaScript is an interpreted language, and it does not have arrays or integers. This is not a harsh statement but a factual one.

There's plenty to not like about JS, but being interpreted and not having integers or arrays is not high on its negatives list. The little bit of good far outweighs the whole lot of bad. If you don't enjoy JS, it's because you haven't taken the time to learn what's great about it and have gotten hung up on the stupid things other people do with it or you're copying their mistakes.

That last paragraph is a logical fallacy, because it posits that one's distaste for JavaScript could only come via ignorance. I will offer my own anecdotal experience to refute that assertion. I've been forced to use JavaScript since the 1990s, and have done significant amounts of work in Node for several companies. I dislike Node and JavaScript because JavaScript has a weak standard library, ugly syntax, is slow, is a pain to scale, and a pain to write complex code with. I will absolutely give credit to the Node community for improving JavaScript, in both speed and syntax, and admit that JavaScript is better now than it ever has been; however, so are most popular languages. Personally, I've removed JavaScript from my resume, and turn down jobs that use it. If I have to use it for some reason, I can, but right now, I typically avoid it altogether by using Elm, and real server-side languages on the backend. I can't speak for anyone else, but I know JavaScript and still don't like it.

Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust

#47

Wow, I expected Erlang to score better, considering the claims of Elixir community how fast it is... compared to Ruby. OTOH maybe that tells more about Ruby.

This is why benchmarks really don't mean much. They are a myopic view of the complex nature of language selection. For example, I would never recommend Java for a bulletproof app that had to scale, because OTP is so much better at scalability, fault tolerance, live debugging, and hot code deployments. At the same time, I would never opt for Elixir for doing screen-scraping, because it is slow at it. Sometimes, developer productivity is more important than speed and scalability. It is important to know the strengths and weaknesses of various languages, and the most important aspects of your project, in order to pick the right tool for the job, I think. Performance benchmarks are but a small part of the selection process.

Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust

#48
Years ago i was naive enough to believe these benchmarks. Now i know these are Potemkin-village level stunts and political maneuvering by language activists and staff of that site. If you really want actual benchmarking you have to do it yourself and read the .asm output for comparison. Another caveat is that some languages are genuinely faster in one hyperoptimized case(even faster than C) but fail horribly when things go more complicated and abstraction creep makes them much slower in most cases.
Post reply on HN