3 ms·

My (admittedly) limited experience with Cargo had me beeing forced to write a build.rs file, which, while neat for edge/complex cases, seems a little overkill f

My (admittedly) limited experience with Cargo had me beeing forced to write a build.rs file, which, while neat for edge/complex cases, seems a little overkill for basic stuff like linking to a simple C library. I'm also not fond of making the package manager also kinda the build system, but that's just my preference to keep it flexible.

virtualritz 4y ago
I think you have your definitions upside down. Linking to a library from another language is rather considered an 'edge/complex case' in most circumstances outside of systems programming and the lib having a C API. And that case is literally three lines of Rust in build.rs if you use e.g. bindgen. While Rust is a systems programming language the primary use cases, judging from the ecosystem of crates, are actually /not/ drivers or desktop apps. The latter are an 'edge/complex case' that just happens to be also nicely covered. And not doing that (i.e. operating solely inside the language ecosystem) is what most users of such ecosystem would reserve the term 'basic' for. To understand where I'm coming from: would you consider 'linking' to a Python or Erlang libray from C++ 'basic' or an 'edged/complex case'?
- Ragnarork 4y ago
  I can agree that it's not the most common case, but it's also out of necessity because there's multiple rust crates, for certain C & C++ libraries that are fundamental in some domains, that either: * do not exist yet * struggle to provide full bindings * do not keep up * have stopped being updated One of the most glaring example for me is Assimp, which still does not have its Rust counterpart (and unsurprisingly, because Assimp has a weird interface to begin with). I didn't stumble upon bindgen, but from what I gather it's for library developers, not consumers, right? > the primary use cases, judging from the ecosystem of crates, are actually /not/ drivers or desktop apps Well, in that case (but not aiming specifically at you) why do I see so much claims that "Rust is the new C++"? > would you consider 'linking' to a Python or Erlang libray from C++ 'basic' or an 'edged/complex case'? I would consider it complex, but this is wildly different IMHO than Rust with C or C++ (but mostly C to keep it sane), which, while more "complex" than pure Rust, still falls within the reasonable expectations. The fact that there are so many crates wrapping around C (and C++ to some extent) libraries means that for the most part, that "complexity" has been offset by crates developers, but many Rust use-cases still seem to require a lot of C/C++ code to even exist (even if abstracted away by glue crates).

virtualritz 4y ago

I think you have your definitions upside down. Linking to a library from another language is rather considered an 'edge/complex case' in most circumstances outside of systems programming and the lib having a C API. And that case is literally three lines of Rust in build.rs if you use e.g. bindgen. While Rust is a systems programming language the primary use cases, judging from the ecosystem of crates, are actually /not/ drivers or desktop apps. The latter are an 'edge/complex case' that just happens to be also nicely covered. And not doing that (i.e. operating solely inside the language ecosystem) is what most users of such ecosystem would reserve the term 'basic' for. To understand where I'm coming from: would you consider 'linking' to a Python or Erlang libray from C++ 'basic' or an 'edged/complex case'?

Ragnarork 4y ago
I can agree that it's not the most common case, but it's also out of necessity because there's multiple rust crates, for certain C & C++ libraries that are fundamental in some domains, that either: * do not exist yet * struggle to provide full bindings * do not keep up * have stopped being updated One of the most glaring example for me is Assimp, which still does not have its Rust counterpart (and unsurprisingly, because Assimp has a weird interface to begin with). I didn't stumble upon bindgen, but from what I gather it's for library developers, not consumers, right? > the primary use cases, judging from the ecosystem of crates, are actually /not/ drivers or desktop apps Well, in that case (but not aiming specifically at you) why do I see so much claims that "Rust is the new C++"? > would you consider 'linking' to a Python or Erlang libray from C++ 'basic' or an 'edged/complex case'? I would consider it complex, but this is wildly different IMHO than Rust with C or C++ (but mostly C to keep it sane), which, while more "complex" than pure Rust, still falls within the reasonable expectations. The fact that there are so many crates wrapping around C (and C++ to some extent) libraries means that for the most part, that "complexity" has been offset by crates developers, but many Rust use-cases still seem to require a lot of C/C++ code to even exist (even if abstracted away by glue crates).