[PATCH RFC] RFC: allow optional C++ 11 extensions with pybind11 for performance code

Sean Farley sean at farley.io
Wed Feb 10 18:36:43 EST 2016


Bryan O'Sullivan <bos at serpentine.com> writes:

> On Mon, Feb 8, 2016 at 1:33 PM, Sean Farley <sean at farley.io> wrote:
>
>> When cloning code on IBM
>> BlueGene it is annoying as hell to have random dependencies sneak in
>> like this. For reference, IBM BlueGene has had problem with codes that
>> use C++.
>>
>
> As much as I think Laurent has a burden of proof for how C++ helps with
> productivity, I submit that you too owe a strong case for why the Mercurial
> developer community should be hamstrung by support for a tiny
> sub-population if said sub-population is permanently unable or unwilling to
> keep up with the times.
>
> This isn't a game of absolutes, and I'd rather have a discussion of the
> trade-offs.

That's fair. And I agree.

I didn't so much mean that we should be held up by this subset, I meant
more of "here's one example of using C++ that backfired." There are
other examples, though. There are papercuts from C++'s name mangling.
Not to mention the hornet's nest with ABI compatibility. That issue is
still a problem for the Mac (try compiling boost with gcc). Summing all
of these issues does not instill confidence that we would do any better.

My main fear is having a negative user experience. DVCS, at its core, is
a system tool. Impeding a developer from using their familiar tools is a
serious sin.

So, what else is there?

- code generation?
  - pros: outputs C
  - cons: I have yet to see a code generator provide a good debugger

- cython?
  - pros: has a debugger, somewhat native code
  - cons: incompatible with pypy

- cffi?
  - pros: cleaner C, native code, pypy support
  - cons: need to include custom data types

- something else?

- something crazy?


More information about the Mercurial-devel mailing list