Guido van Rossum

> But keeping the current half-baked async implementation doesn't make the language smaller or simpler. It just makes the language worse.

I can't disagree more.

In fact, I think that the current state of async Rust is the best implementation of async in any language.

To get Pin stuff out of the way: it is indeed more complicated than it could be (because reverse compatibility etc), but when was the last time you needed to write a poll implementation manually? Between runtime (tokio/embassy) and utility crates, there is very little need to write raw futures. Combinators, task, and channels are more than enough for the overwhelming majority of problems, and even in their current state they give us more power than Python or JS ecosystems.

But then there's everything else.

Async Rust is correct and well-defined. The way cancellation, concurrent awaiting, and exceptions work in languages like JS and Python is incredibly messy (eg [1]) and there are very few people who even think about that. Rust in its typical fashion frontloads this complexity, which leads to more people thinking and talking about it, but that's a good thing.

Async Rust is clearly separated from sync Rust (probably an extension of the previous point). This is good because it lets us reason about IO and write code that won't be preempted in an observable way, unlike with Go or Erlang. For example, having a sync function we can stuff things into thread locals and be sure that they won't leak into another…

> More importantly, Lua has a crucial feature that Javascript lacks: tail call optimization. There are programs that I can easily write in Lua, in spite of its syntactic verbosity, that I cannot write in Javascript because of this limitation. Perhaps this particular JS implementation has tco, but I doubt it reading the release notes.

> [...] In my programs, I have banned the use of loops. This is a liberation that is not possible in JS or even c, where TCO cannot be relied upon.

This is not a great language feature, IMO. There are two ways to go here:

1. You can go the Python way, and have no TCO, not ever. Guido van Rossum's reasoning on this is outlined here[1] and here[2], but the high level summary is that TCO makes it impossible to provide acceptably-clear tracebacks.

2. You can go the Chicken Scheme way, and do TCO, and ALSO do CPS conversion, which makes EVERY call into a tail call, without language user having to restructure their code to make sure their recursion happens at the tail.

Either of these approaches has its upsides and downsides, but TCO WITHOUT CPS conversion gives you the worst of both worlds. The only upside is that you can write most of your loops as recursion, but as van Rossum points out, most cases that can be handled with tail recursion, can AND SHOULD be handled with higher-order functions. This is just a much cleaner way to do it in most cases.

And the downsides to TCO without CPS conversion are:

1. Poor tracebacks.

2. Having to…

> Don't know if it should be a method or an attribute? Python has properties now, the user doesn't have to care.

Python didn't have properties when the len protocol was implemented. What exactly will be gained if Python replaces len(a) with a.length(where a.length translates to a.__len__())? If properties were there from the beginning, that would have been the implementation; but since they weren't, len(a) is just fine and I don't see any reason for it to be changed.

> The 'special meaning' section that follows seems a bit confused as well. Why is it so special to get the length of a collection?

Personally I would have preferred __len__ to be just length, because length of a sequence is part of it's public interface, as opposed to other special methods viz. __getattr__, __getitem__. Apart from that, his 'special meaning' section is just saying that following a weird naming convention for the special methods permits programttacily differentiating between public interface and special methods.

> I can feel it working within me too, I'm more and more on the fence about explicit self.

The main reason it is that way is decorators.

http://neopythonic.blogspot.in/2008/10/why-explicit-self-has-to-stay.html

> However this is complete and utter bullshit.

This isn't an appropriate response to a well thought out article.

http://neopythonic.blogspot.co.il/2011/06/depth-and-breadth-of-python.html

"The contrast with my visitor the next day couldn't be greater. Through a former colleague I got an introduction to Drew Houston, co-founder and CEO of the vastly successful start-up company Dropbox.

Python plays an important role in Dropbox's success: the Dropbox client, which runs on Windows, Mac and Linux (!), is written in Python. This is key to the portability: everything except the UI is cross-platform. (The UI uses a Python-ObjC bridge on Mac, and wxPython on the other platforms.) Performance has never been a problem -- understanding that a small number of critical pieces were written in C, including a custom memory allocator used for a certain type of objects whose pattern of allocation involves allocating 100,000s of them and then releasing all but a few. Before you jump in to open up the Dropbox distro and learn all about how it works, beware that the source code is not included and the bytecode is obfuscated. Drew's no fool. And he laughs at the poor competitors who are using Java."

Sometime after that, Drew poached Guido from Google. I remember this post. :)

Why is there even an argument about this? Not being able to make a recursive call without potentially blowing the stack is a major drawback in any language. I'd venture to say it's a "bug.”

You aren’t going to like Python:

I don't believe in recursion as the basis of all
programming. This is a fundamental belief of certain
computer scientists, especially those who love Scheme
and like to teach programming by starting with a "cons"
cell and recursion. But to me, seeing recursion as the
basis of everything else is just a nice theoretical
approach to fundamental mathematics (turtles all the
way down), not a day-to-day tool.

http://neopythonic.blogspot.com/2009/04/tail-recursion-elimination.html

(I’m not advocating this view, just pointing out that there are programmers who appear in all other respects to be reasonable, intelligent, contributing members of computing society who actually feel that TCO is a bug, that 1000 calls ought to be enough for anybody, and so forth.)

As long as we're on this subject, I'd like to strongly encourage programmers to adopt a "pen-and-paper" approach to problem solving. Just like mentionned in the article, there are great benefits coming from actually writing down the problem.

For the past year or so, every time I worked on a non-trivial problem, I did it on a sheet of paper. It definitely took discipline at first but now I couldn't do it any other way.

My motivation for adopting this approach came from reading a blog post by Guido Van Rossum (http://neopythonic.blogspot.fr/2011/07/before-python.html).

Then I went to university in Amsterdam to study mathematics and they had a computer that was free for students to use!

(Not unlimited though. We were allowed to use something like one second of CPU time per day. :-)

"One second of CPU time per day" got me thinking. Sure there are benefits to having modernly cheap computers, but how did they do it before?