[pvg]

you are adding more degrees of freedom to your language's design

Why do you think that? Languages/runtimes with high C integration and fairly exposed C bowels like Python and Ruby have, over time, turned out to be very hard to evolve compatibly.

[CogitoCogito]

> Why do you think that?

Because it's a fact? With cpython you can develop things in python if that suits you or C if that suits you. You have more freedom to choose what fits your use case. I'm not saying this is necessarily good, but I don't think it's obviously bad. I'd like to hear from people who think it's the case.

> Languages/runtimes with high C integration and fairly exposed C bowels like Python and Ruby have, over time, turned out to be very hard to evolve compatibly.

That is true, but it's also arguably one of the reasons cpython became so popular in the first place. The ability to write C-extensions when appropriate has been very powerful. It's certainly caused issues, but I think if python didn't have exposed bowels it may never have become nearly as popular. What if numpy wasn't ever written? (This isn't to say that they couldn't have exposed a better C-api with fewer issues, but hindsight is 20/20...)

[pvg]

I guess I don't understand how 'the design gets stuck in amber' (which you seem to agree with) and 'gives you lots of design degrees of freedom' can be true at the same time.

[feanaro]

It gives you flexibility in writing libraries while making it harder to design a new compatible runtime. That said, PyPy has achieved pretty good C extension support while making the language faster.

[pvg]

The claim was 'degrees of freedom in your language's design'. It's an odd one because the history of a bunch of similar languages has been exactly the opposite. Compare, say, JS to Ruby and Python. Even with the seemingly crippling burden of browser compatibility, Javascript has evolved out of its various design and implementation ruts a lot more gracefully than either Ruby or Python.