Looks very much like a python without the legacy and a touch of ruby, ipython as the default shell, better multiprocessing, better os/system access, decorators and mathematics. Nice clear documentation too.
Given how similar to python they are their main competitor is pypy, which isn't too far behind them in performance I'd suspect (absent from the benchmarks though). I was fully expecting someone to make a non-compatible fork of pypy to create a faster python-like lang/something like julia. They should quickly get some elegant small libraries like sinatra/bottle and requests (access to dbs with http interfaces as well). A robust requests+lxml library built-in would be simply amazing.
PyPy is missing complex support in numpy (on trunk anyway) and numpy.random to run those benchmarks. Those that run:
fib - roughly the same time as CPython
parse_int - 10x over CPython which is extrapolating to their python vs julia about 20% slower
quicksort - 4x faster than cpython much slower than julia.
pi_sum - 20x faster than cpython, a bit faster than julia?
Those are very unscientific measurments. Both fib and qsort are recursive benchmarks (why would you write qsort recursively??), so I guess the JIT does not have time to kick in (and PyPys support kinda sucks for recursion at least in terms of warmup times).
On a slightly unrelated note - a modified lxml library runs on pypy albeit a lot slower right now.
Well you are being a bit nitpicky as pypy is both the python implementation and the JIT/Rpython/framework bit. What I mean was someone holding very close to the python implementation in almost everything (syntax etc.) but streamlining it/breaking compatibility/giving it a new name ("python3-as-it-should-have-been" perhaps?).
Further, if we are going to be nitpicky, when you use something like that for its intended purpose it's still a fork - I forked Twitter bootstrap for my new project/I used Twitter bootstrap for my new project - so "you wouldn't fork PyPy" is a false statement.
> if we are going to be nitpicky, when you use something
> like that for its intended purpose it's still a fork
No. Fork is definitely not semantically congruent with use. You're only forking Bootstrap if you create a path that diverges from its mainline; don't get confused by GitHub parlance.
Pypy most commonly refers to the python implementation anyway, as can be easily seen by going to the pypy website[1]. Daslch abused the fact that "pypy" points to two things to make a meaningless nitpick. Now you are claiming that I have claimed that fork and use are semantically congruent, where do I claim that? I think you are nitpicking and parsing "it" wrong. In either case a question asking for clarification would be more polite than going on attack.
There seems to be a disease, let's call it Eric Raymond Disease (ERD), on HN in particular[2] of people busting in rudely to declare with supreme confidence on the usage of quite generic words and/or slang. Let's start by tabling the fact that a particular "software definition" of "fork" has not yet reached the OED, or online dictionaries like Merriam-Webster for that matter. Going from that I can't see how you can declare it to only have one definition when you already admit there is a competing one ("GitHub parlance"). The base concept of the word fork is a divergence, a branch, which seems to me to cover any copy+modify move for software so someone copy+modifying bootstrap is forking it, someone copy+modifying the implementation of python called pypy is forking it.
Are you and Daslch really contributing to HN or are you taking a rather banal comment and turned it into a 100% useless thread by bickering over semantics?
Given how similar to python they are their main competitor is pypy, which isn't too far behind them in performance I'd suspect (absent from the benchmarks though). I was fully expecting someone to make a non-compatible fork of pypy to create a faster python-like lang/something like julia. They should quickly get some elegant small libraries like sinatra/bottle and requests (access to dbs with http interfaces as well). A robust requests+lxml library built-in would be simply amazing.