[vessenes]

Python developers would almost all upgrade in a single minute for 30%+ better performance.

It's interesting that performance wasn't a topic at this rump session as reported; I moved over to Go about a year ago, and while I miss Python's expressivity at least once a week, I'm just not willing to slow down all my programs by 5x.

On the other hand, if Python could double in speed, I'd likely try to rework it into our workflows. Well, maybe. I really dig Go.

[hurin]

>Python developers would almost all upgrade in a single minute for 30%+ better performance.

But strangely they don't - PyPy has hardly gained traction (albeit the python2->python3 switch didn't help) and looking at the benchmarks that's more like 5-7x performance.

I suspect that most often, in places where performance matters enough in a way that would warranted refactoring a code-base from cpython to PyPy, they already rewrote the botte-neck parts in C anyways.

[xioxox]

A lot of the problem is that PyPy isn't completely compatible with C extensions.

[danieloaks]

I want to use PyPy, and I have used it for a biggish server-based project I've been a part of.

The issue I've usually had with it is just small things – maybe an module we depend on doesn't work with PyPy yet, maybe PyPy3 isn't 3.3-compatible yet and can't use "yield from", which we use in our code or which our libraries use.

Dealing with those sort of small issues (and/or waiting for PyPy to fix them), worrying about whether the project I'm currently working on can use PyPy or if I need to use CPython instead, etc makes me stop worrying about trying to use it after a while. In my dev environment at least.

I do really love what the PyPy guys are doing though, and when it works it works damn well. Building it from source is also super pretty.

[stock_toaster]

pypy is great (we use it at work for a few services), but it has slow startup/jit warm up, and uses crazy lots of ram. Once it warms up though, it is pretty darn fast (for python).

[vessenes]

I like PyPy, it's great work. But, it doesn't always work. Our last project that used python seriously used tornado and occasionaly numpy. Getting it all glued together was lots and lots of frustration, confusion about versions, and so on. PyPy just isn't mainline python. Which is really what the 2 vs 3 debate is about, in the end. If you have a 'batteries included' language, making breaking changes could take a long time.

[beagle3]

Have you tried Nim[rod]? Seems to be pythonesque in almost every way, except speed, in which it is goesque.

[kibwen]

Aside from having whitespace-sensitive syntax, Nim isn't Python-esque at all. Nim very much encourages TIMTOWTDI over Python's there-should-be-preferably-one-way-to-do-it. Nim also has extremely flexible syntax where Python is rigid. See Nim's pervasive use of metaprogramming via macros, or its inclusion of user-defined symbolic operators (as per Haskell and Scala), or the fact that it considers `foo` and `Foo` and `FOO` and `f_O__o` to be equivalent identifiers, or its inclusion of UFCS.

Nim is a neat language, but comparisons to Python solely because it has semantic indentation are completely shallow (especially so when you consider that Guido doesn't even think that whitespace sensitivity is an important feature).

[beagle3]

I agree that idiomatic Nim (if there is such a thing) is very different than idiomatic Python.

What I meant (and did not express clearly) is that you can write mostly pythonesque code in Nim, and it will perform as well as Go. You don't have to modify the syntax, use macros, define symbolic operators, operational transforms, etc any more than you have to use metaclasses in Python.

At it's core, if you write "typed python" code in Nim, it will work, be readable, and perform well.

[vessenes]

I haven't, but I have tracked Nim since announcement. It might be a great language, but I don't think it will ever be appropriate for my use case, which is reasonably performant mid-size codebases that junior/journeyman developers can be productive in almost immediately.

If you read the "Why Nim" posts, they are highly salient points for a 'journeyman' or better developer that wishes to be highly productive on a small project; I read the list of 'better than Go' stuff with that hat on, and it's very appealing.

But, there's too much rope to hang oneself in Nim for my use case. Getting a language stripped down just enough that team productivity over years is maximized is a very, very hard thing to do. I think the go folks have the best take on it right now, and it's run by courteous and responsive grownups who do what they say they'll do. That's a total win in my book.

Add in go fmt, a very good (not without warts) module import system, reasonable testing and a multi processor programming model that's easy to reason about, and it is a very, very good solution for my needs.

[swinglock]

If you need better performance you'd be looking at PyPy instead of CPython. If Python 3 runs faster on PyPy as well that could make a difference.