[deleted]
Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust
21–30 of 132 posts
Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust
#22So 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 not necessarily a performance issue, unless you're Facebook (traffic wise) you might never worry about that, but it's more about the developers who use PHP[0] it's a mixed bag of below junior level to senior level developers. It's hard to know which type of codebase you will get your hands on until you do. There's other issues I personally have with it, though I use it if it's not code I can easily reinvent without investing way too much of my own time on it e.g. a forum or a blog engine.
Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust
#23Hey, the benchmark game got a new website (at some point in the several years since I looked at it last)! Almost simplistic, but nice to read. As someone that works predominantly in a language long considered passé (Perl), I always kinda relish seeing that it is still faster than Python and Ruby for many problems. As Python and Ruby have gotten faster, I'd sort of assumed they were both notably and clearly faster tha…
Python was never really designed for speed. It was designed for simplicity and clarity of behaviour. The beauty of the age we live in is that we have such a broad array of tools to apply to different problems. Performance is often not the problem that needs solving, but when it is, you've got many options too!
Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust
#24Wow, 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.
Erlang's claim to fame at least for me is parallelism. When you scale out to thousands upon thousands of clients. Think about the simple fact it was using all cores on a processor out of the box by design that a computer had available. There's also the whole zero downtime aspect. In Erlang you should be able to design software (again downtime from the software side, not much you can do about hardware failure or server maintenance updates to your OS) that if it needs an update it can update itself without killing off anyone connected to it. There's also it's functional aspects.
Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust
#25Wow, 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.
Erlang makes no claims about being fast in these sorts of tests. They aren't using what it was designed to do. Also some languages like, Ruby, do really well on some of these tests because the C-code underneath has been written well (example regexes are just as fast under ruby as they are anywhere else because the underlying C-library kicks ass though I forget the name of it).
You're probably thinking of PCRE, although Ruby actually uses Onigmo: https://github.com/k-takata/Onigmo
Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust
#26Wow, 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.
Erlang isn't built for computational throughput. It's built for concurrency and fault-tolerance.
Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust
#27Earlier 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.
> There's plenty to not like about JS, but being interpreted and not having integers or arrays is not high on its negatives list.
We are having a discussion is about programming language benchmarks.
A benchmark in this case is a measure of how fast a computer program can run. A computer program is a series of instructions for a computer. These instructions are written in something called a programming language. A programming language which is interpreted is inherently slower than a programming language which is compiled to assembly language. A programming language which does not have integers but must represent all numbers as floating point numbers is inherently slower than a programming language which has integers. A programming language which does not have arrays, but must represent arrays using hash tables, is inherently slower than a language which does have arrays. Thus, Node.js, which is interpreted and does not have arrays or integers, would be expected to be have much lower benchmarks than Go's, and yet node.js has exceptionally high performance.
Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust
#28Earlier quoted context omitted.
Ummmm, that's a somewhat harsh and arrogant reply. I actually enjoy coding in Node.js myself. I just wasn't aware how much faster go is (according to these benchmarks of course).
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.
The JS language as specified is interpreted and doesn't have ints or first-class arrays; the code run by the VM that runs Node.js code is compiled and runs on smallints and arrays and so on.
(Not sure if you already knew this, but if so, you're not being factual, you're being selectively pedantic to make something sound worse than it is. Lack of ints or arrays isn't a big factor in JS performance for non-pathological cases.)
(edit: reasons for downvotes are appreciated!)
Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust
#29Hey, the benchmark game got a new website (at some point in the several years since I looked at it last)! Almost simplistic, but nice to read. As someone that works predominantly in a language long considered passé (Perl), I always kinda relish seeing that it is still faster than Python and Ruby for many problems. As Python and Ruby have gotten faster, I'd sort of assumed they were both notably and clearly faster tha…
Python was never really designed for speed. It was designed for simplicity and clarity of behaviour. The beauty of the age we live in is that we have such a broad array of tools to apply to different problems. Performance is often not the problem that needs solving, but when it is, you've got many options too!
I'm not disparaging Python (or Ruby). Merely taking small pleasures where I find them. I work in Perl because of a huge array of existing code in Perl, not because I hate Python or Ruby (I've built stuff in Python and Ruby, too, and like them both).
Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust
#30Earlier 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.
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?