5 ms·

> But there is another aspect of the language that makes it so desirable from his standpoint: it can be extended with binary extensions that use an API that is

> But there is another aspect of the language that makes it so desirable from his standpoint: it can be extended with binary extensions that use an API that is written in C, but can be accessed from other languages. He likens Python to "a Honda Civic with mounting bolts for a warp drive". So the language can be picked up by kids who can then pop open the trunk "and bolt on warp nacelles" that allows the code to run faster than C or C++ in some cases, Wang said. > > That aspect is sometimes overlooked, but it means that Python can be used in ways that other, similar languages cannot. "It's not just like Node, it's not just an alternative to Ruby". Both node and Ruby have a comprehensive C API, this is a very common language feature since binding to native libraries is unavoidable. Is there actually anything different about python here? https://nodejs.org/api/n-api.html https://nodejs.org/api/n-api.html https://silverhammermba.github.io/emberb/c/ https://silverhammermba.github.io/emberb/c/

deleted 4y ago
[deleted]
oofbey 4y ago
Ruby and Python are incredibly similar in raw functionality, but extremely different in culture. e.g. Both languages allow monkey-patching, while one community thinks it is a great productivity boost making it easy to build cool language tricks, while the other considers it an absolute last resort to be avoided in almost every situation. I think the key point here is that Python prioritized making native add-ons easy, and so it actually developed an ecosystem. The very second sentence on Ruby's C API that is linked above says "the API is huge and largely undocumented."
Taywee 4y ago
I think he's referring to Python's ctypes, which is part of the standard distribution. Ruby and node can't dynamically load C libraries using just the core distro (though it's a little silly of a point to make, given that Ruby's FFI gem works fine, even if it's not part of the standard distribution).
- woodruffw 4y ago
  > Ruby and node can't dynamically load C libraries using just the core distro Ruby has had Fiddle[1] (a libffi binding) in stdlib for a while now. I don't know when exactly they added it, but it's been at least a couple of years. Edit: I gave a talk on obfuscation in Ruby that used Fiddle back in 2017, so at least 5 years now. Edit: But I also don't think that's what the speaker meant. "Binary extensions" are a semi-standard concept in Python, and generally refer to code (modules or packages) that gets compiled against the Python C APIs. [1]: https://ruby-doc.org/stdlib-3.1.2/libdoc/fiddle/rdoc/Fiddle.html https://ruby-doc.org/stdlib-3.1.2/libdoc/fiddle/rdoc/Fiddle....
  - dragonwriter 4y ago
    > Ruby has had Fiddle[1] (a libffi binding) in stdlib for a while now. I don’t know when exactly they added it In ruby 1.9.2 [0], released in 2010. > But I also don’t think that’s what the speaker meant. “Binary extensions” are a semi-standard concept in Python, and generally refer to code (modules or packages) that gets compiled against the Python C APIs. Ruby has the same thing. [0] Based on when it first appears in the standard library documentation on the web; 1.9.1 doesn’t have it, 1.9.2 does.
  - Taywee 4y ago
    Wow, I don't know how I entirely missed that. Thanks for the heads up. I've even written a few libraries with C ABI and wrote gems around them with the Ruby FFI gem because I didn't know about Fiddle. I wish the name were better; I might have found it earlier. Re edit 2: I've made those sorts of binary extensions before, but his wording is "extended with binary extensions that use an API that is written in C, but can be accessed from other languages", implying it's actually just about loading libraries with C ABI and not ordinary binary modules, at least by my interpretation.
woodruffw 4y ago
> Is there actually anything different about python here? I say this as a big fan of Python: I think the main difference is that the CPython C APIs are much more of a pain to use :-) I don't know about Node's C APIs, but I've written both Python and Ruby extensions and find the MRI APIs much nicer than the CPython ones.
- immmmmm 4y ago
  have you tried pybind11? if you accept going from C to C++, all the dirty job is done for you, exposing a C++ function is one line and can use numpy arrays directly in the function.
  - woodruffw 4y ago
    I've contributed to extensions that are written against pybind11, but never written my own. It was pretty nice, and it does indeed cover some of my grievances (at the expense of making me write C++?).
- toyg 4y ago
  That's literally the opposite feedback of the rest of the world. There is a reason the scientific community standardized on Python, and bindings for all sorts of things from Blender to KDE were more successful on Python than other languages.
  - woodruffw 4y ago
    My understanding of the "why" for Python in the scientific community is that it's twofold: it's very easy to get started in (and slowly build up expertise in), and (2) that a key set of packages (pandas, numpy) were created early and obtained critical mass. But neither of these implies that the CPython API is exceptionally good: (1) can be an overriding factor during the implementation of (2), and (2) means that the average scientific Python user doesn't actually need to touch the CPython APIs that much (all the work is already done!). So I don't think my feedback ("Ruby extensions are easier to write than CPython extensions") is actually incongruous with the rest of the world; the rest of the world picked Python because it's a better language in the ways that matter.
smaudet 4y ago
I can't say I'm as familiar with ruby bindings, I have dabbled with node bindings.... JS could sort of probably do most things Python can, except for there not being a huge effort for JS things to be native binary (compiling an exe wrapper that executes a VM is not the same thing, e.g. electron). I know there are various C++ injected JS dependencies on node... Python has a distinct advantage of being a bit closer to the metal, though. Yeah the default python intepreter yadayada - but that's the honda civic bit. You can compile python to c code, compile it, and _call random python modules from within your c code_ all automatically. Or generate a binary c module, or create or a fully compiled exe, or create a python app with an embedded vm, or run the whole thing in a JIT....there's a lot of flexibility. "Oh but with package XYZ I can cobble together something similar in JS" - yeah, you probably can, but normally you have to contend with a browser, or modules written for a browser, or a DOM, or a transpiler/webmaplicabroominator (don't ask, there's some real nonsense in the JS space) - its all non-standard, plus most of it has only existed for <5 years, python land has had this for...decades now? JS is what you get when you build a language around a DOM, don't get me wrong, it can do some nifty things. Python is what you get when you mostly don't care about fancy UI... I suspect Ruby is in a closer boat to Python than JS, but, python has been a more perlesque language insofar as its use as a glue language, Ruby is/was definitely focused on being a fantastic web rendering language (with a bit of JS UI glue). This is evident where python is often used - you can normally get a python binding, even if you don't have a JS or ruby binding. Again, not the world - as far as type safety there are much better alternatives than any of these, for systems or reliability I would not depend on python (alone).
simonh 4y ago
It had it a lot earlier, and built up a significant library and ecosystem of C modules fast enough to reach critical mass first. This matters because a bigger ecosystem and community creates a feedback loop that generates further resources and adoption. It's the ecosystem that's the game changer. I'm not a C developer, so for me if the question is, can I call out to a C module that implements capability X, the answer to that is much more likely to be yes for Python than it is for Ruby.

deleted 4y ago

[deleted]

oofbey 4y ago

Ruby and Python are incredibly similar in raw functionality, but extremely different in culture. e.g. Both languages allow monkey-patching, while one community thinks it is a great productivity boost making it easy to build cool language tricks, while the other considers it an absolute last resort to be avoided in almost every situation. I think the key point here is that Python prioritized making native add-ons easy, and so it actually developed an ecosystem. The very second sentence on Ruby's C API that is linked above says "the API is huge and largely undocumented."

Taywee 4y ago

I think he's referring to Python's ctypes, which is part of the standard distribution. Ruby and node can't dynamically load C libraries using just the core distro (though it's a little silly of a point to make, given that Ruby's FFI gem works fine, even if it's not part of the standard distribution).

woodruffw 4y ago
> Ruby and node can't dynamically load C libraries using just the core distro Ruby has had Fiddle[1] (a libffi binding) in stdlib for a while now. I don't know when exactly they added it, but it's been at least a couple of years. Edit: I gave a talk on obfuscation in Ruby that used Fiddle back in 2017, so at least 5 years now. Edit: But I also don't think that's what the speaker meant. "Binary extensions" are a semi-standard concept in Python, and generally refer to code (modules or packages) that gets compiled against the Python C APIs. [1]: https://ruby-doc.org/stdlib-3.1.2/libdoc/fiddle/rdoc/Fiddle.html https://ruby-doc.org/stdlib-3.1.2/libdoc/fiddle/rdoc/Fiddle....
- dragonwriter 4y ago
  > Ruby has had Fiddle[1] (a libffi binding) in stdlib for a while now. I don’t know when exactly they added it In ruby 1.9.2 [0], released in 2010. > But I also don’t think that’s what the speaker meant. “Binary extensions” are a semi-standard concept in Python, and generally refer to code (modules or packages) that gets compiled against the Python C APIs. Ruby has the same thing. [0] Based on when it first appears in the standard library documentation on the web; 1.9.1 doesn’t have it, 1.9.2 does.
- Taywee 4y ago
  Wow, I don't know how I entirely missed that. Thanks for the heads up. I've even written a few libraries with C ABI and wrote gems around them with the Ruby FFI gem because I didn't know about Fiddle. I wish the name were better; I might have found it earlier. Re edit 2: I've made those sorts of binary extensions before, but his wording is "extended with binary extensions that use an API that is written in C, but can be accessed from other languages", implying it's actually just about loading libraries with C ABI and not ordinary binary modules, at least by my interpretation.

woodruffw 4y ago

> Is there actually anything different about python here? I say this as a big fan of Python: I think the main difference is that the CPython C APIs are much more of a pain to use :-) I don't know about Node's C APIs, but I've written both Python and Ruby extensions and find the MRI APIs much nicer than the CPython ones.

immmmmm 4y ago
have you tried pybind11? if you accept going from C to C++, all the dirty job is done for you, exposing a C++ function is one line and can use numpy arrays directly in the function.
- woodruffw 4y ago
  I've contributed to extensions that are written against pybind11, but never written my own. It was pretty nice, and it does indeed cover some of my grievances (at the expense of making me write C++?).
toyg 4y ago
That's literally the opposite feedback of the rest of the world. There is a reason the scientific community standardized on Python, and bindings for all sorts of things from Blender to KDE were more successful on Python than other languages.
- woodruffw 4y ago
  My understanding of the "why" for Python in the scientific community is that it's twofold: it's very easy to get started in (and slowly build up expertise in), and (2) that a key set of packages (pandas, numpy) were created early and obtained critical mass. But neither of these implies that the CPython API is exceptionally good: (1) can be an overriding factor during the implementation of (2), and (2) means that the average scientific Python user doesn't actually need to touch the CPython APIs that much (all the work is already done!). So I don't think my feedback ("Ruby extensions are easier to write than CPython extensions") is actually incongruous with the rest of the world; the rest of the world picked Python because it's a better language in the ways that matter.

smaudet 4y ago

I can't say I'm as familiar with ruby bindings, I have dabbled with node bindings.... JS could sort of probably do most things Python can, except for there not being a huge effort for JS things to be native binary (compiling an exe wrapper that executes a VM is not the same thing, e.g. electron). I know there are various C++ injected JS dependencies on node... Python has a distinct advantage of being a bit closer to the metal, though. Yeah the default python intepreter yadayada - but that's the honda civic bit. You can compile python to c code, compile it, and _call random python modules from within your c code_ all automatically. Or generate a binary c module, or create or a fully compiled exe, or create a python app with an embedded vm, or run the whole thing in a JIT....there's a lot of flexibility. "Oh but with package XYZ I can cobble together something similar in JS" - yeah, you probably can, but normally you have to contend with a browser, or modules written for a browser, or a DOM, or a transpiler/webmaplicabroominator (don't ask, there's some real nonsense in the JS space) - its all non-standard, plus most of it has only existed for <5 years, python land has had this for...decades now? JS is what you get when you build a language around a DOM, don't get me wrong, it can do some nifty things. Python is what you get when you mostly don't care about fancy UI... I suspect Ruby is in a closer boat to Python than JS, but, python has been a more perlesque language insofar as its use as a glue language, Ruby is/was definitely focused on being a fantastic web rendering language (with a bit of JS UI glue). This is evident where python is often used - you can normally get a python binding, even if you don't have a JS or ruby binding. Again, not the world - as far as type safety there are much better alternatives than any of these, for systems or reliability I would not depend on python (alone).

simonh 4y ago

It had it a lot earlier, and built up a significant library and ecosystem of C modules fast enough to reach critical mass first. This matters because a bigger ecosystem and community creates a feedback loop that generates further resources and adoption. It's the ecosystem that's the game changer. I'm not a C developer, so for me if the question is, can I call out to a C module that implements capability X, the answer to that is much more likely to be yes for Python than it is for Ruby.