This is more like Go's defer, and is far more appropriate for my use cases.

For example:

  #include <vector>
  #include <iostream>

  class Scope {

  private:
    typedef std::vector<void (*)()> FV;
    FV fv;
  public:
    void on_return(void (* f)()) {
      fv.push_back(f);
    }

    ~Scope() {
      for (FV::iterator it = fv.begin(); it != fv.end(); ++it) {
        (*it)();
      }
    }
  };

  void foo() {
    std::cout << "Hello ";
  }

  void bar() {
    std::cout << "World" << std::endl;
  }

  int main() {
    Scope scope;

    scope.on_return(foo);
    scope.on_return(bar);

    std::cout << "Hi" << std::endl;
  }

Expanding that into something providing at least most of what Go's "defer" does shouldn't be too hard.

  #include <cstdio>

  template <typename tFunc>
  class ScopeFunc {
  private:
    tFunc mFunc;

  public:
    ScopeFunc(tFunc func) : mFunc(func) {}

    ~ScopeFunc() {
      mFunc();
    }
  };

  template <typename tFunc>
  ScopeFunc<tFunc> on_return(tFunc func)
  {
    return ScopeFunc<tFunc>(func);
  }

  int main() {
    auto first = on_return([]() { std::puts("first"); });
    auto second = on_return([]() { std::puts("second"); });

    std::puts("Hello");
  }

It also optimizes nicely, which yours may not because the loop unrolling may be complicated and there's a higher chance of aliasing of the function pointers in the vector:

  0000000000400600 <main>:
    400600:	53                   	push   %rbx
    400601:	bf e4 07 40 00       	mov    $0x4007e4,%edi
    400606:	e8 b5 ff ff ff       	callq  4005c0 <puts@plt>
    40060b:	bf ea 07 40 00       	mov    $0x4007ea,%edi
    400610:	e8 ab ff ff ff       	callq  4005c0 <puts@plt>
    400615:	bf f1 07 40 00       	mov    $0x4007f1,%edi
    40061a:	e8 a1 ff ff ff       	callq  4005c0 <puts@plt>
    40061f:	31 c0                	xor    %eax,%eax
    400621:	5b                   	pop    %rbx
    400622:	c3                   	retq

I would still prefer a C extension... Perhaps I should just use Go these days, though ironically all these memory allocation policies are useless in a GC language.

From Microsoft's press release: "Nokia will continue to own and manage the Nokia brand."

http://www.microsoft.com/en-us/news/press/2013/sep13/09-02An...

Take for instance: "I'm not going to let some bitch tell me what to do" vs. "Hey bitches, whats up?"

the first statement could communicate that the speaker has issues with females telling him what to do. The second statement is playful and affectionate.

However, because the word bitch is so generic and well used, the first speaker could easily only have issues with unpleasant people, not females. Its not clear.

That's why it is better to talk about a person's pattern of behavior, rather than labeling an isolated incident as sexism.

Where the hell did you pull that from? I suppose there's a "dearth" of men in nursing too? Can I infer an epidemic of misandry because we don't have 50% male nurses? Ludicrous.

just ask any woman

Yeah, because the plural of anecdote is data </sarcasm>

The quote "These free issues and e-cards are intended to help a generation that could sure use a hand, not to blame them." does not seem very genuine to me. It is very difficult for people in my generation to advance themselves in this climate. Youth unemployment has risen globally, and personally I'm horrified at how this government (in the UK) is sabotaging the future of so many children and young people. These kind of glib pot shots were funny 10 years ago, when social mobility was possible but they come across as arrogant and out of touch in today's world.

But to answer your question, the Language Shootout seems to suggest Java and Go are on the same plane in terms of speed. Take that with however many grains of salt you like.

Clojure's done some impressive improving, too.

With Go you don't have anything comparable to Django, Numpy, Pandas...

Given the age of the language I would assume building out its associated toolchain is only a matter of time. Python didnt ship with Django, Numpy, Pandas...

Basically Python is the glue language data people wanted, it turns out.

Beyond that, it deals with a lot of the 'ugly' things around the edges of other languages. Dependency management, build management, deployments... all these IMHO are much more well thought out in go.

I have to disagree on the concurrency model, I think message passing channels are a much more natural primitive to model concurrency in, and goroutines are exceptionally light.

EDIT: When you talk about nimrod, you might go ahead and mention you are the designer of nimrod... it might color your judgement.

Go's primary niche is server software, and in that niche, it is gaining in popularity and has the backing of a large company. For servers, neither support for a 32-bit address space nor real-time support is important.

Does support for generics really matter when the language has built-in support for the most common collection types?

The allowance of shared mutable memory between goroutines does worry me somewhat.

Nimrod? Never heard of it or the person backing it.

I'm _not_ a language snob, trust me! I'm just a regular, family guy, software developer and I try to put my proverbial eggs in reliable baskets.

Go doesn't seem to be going away any time soon and it's really really fast.

I chose Go over C++, because it looks easier.

C++ is harder and there's no garbage collection.

I now have to yet again close my apps and restart my computer for an IT-forced Java runtime update, for some app I rarely use. For that reason alone I'd not consider Java.

But I don't want you to use C#/C++/Java, I want you to use Nimrod.

This is the first I've heard of Nimrod.

Will it replace all of our Python? Highly doubt it. Some very specific pieces? Probably.