It always bugs me to think about the Python community not rallying around PyPy. Faster Python is right there and has been there for years. Sure there can be C-extension issues but projects like HPy showed you can remedy that. Why doesn’t everyone just use and support PyPy?
"C-extension issues" are not something you can just gloss over. They're a huge chunk of python usage. Users won't rally around that. And Hpy is dead. If CPython embraced PuPy, worked with it to smooth those issues then maybe things would be different.
Well, see popularity of CGO among Go devs, or JNI among Java devs, or the ongoing work to make all the learnings from System C# (from Midori) available in regular C#, while C++/CLI is slowly left in maintenance mode (last updated for partial C++20 support, and not part of FOSS .NET)
All of those are for non native code to call code in those languages. Nobody is saying "all Go code must never invoke native code". That would be wild and to my knowledge, there's no major language that forces such a constraint.
I can't tell if you're being willfully ignorant or not. The comment I was replying to was proposing banning C extensions: invoking native binaries that are not written in the host language and compiled in (at build or runtime). What you're describing has nothing to do with that.
Why would a Go binary (to keep the examples short), compiled to native code, with a compiler toolchain that includes support for Assembly if necessary, and a syscall package as well, have to depend on C extensions?
gomoboo · · focus · HN ↗
famouswaffles · · focus · HN ↗
theandrewbailey · · focus · HN ↗
bastawhiz · · focus · HN ↗
pjmlp · · focus · HN ↗
bastawhiz · · focus · HN ↗
pjmlp · · focus · HN ↗
bastawhiz · · focus · HN ↗
pjmlp · · focus · HN ↗
CGO only exists as a matter of convenience.