I know that exists, but whats the point of that? You loose all advantages of rust when you use the library then because it cant predict application state with the library code. There is a reason all those rust libraries are compiled locally when you compile a rust application. Its a major lacking point for rust, and as long as it lacks that its dead in the water for big projects.
Again, i like strong type stuff and i like the ideas of rust but it is not grown up enough for me
It’s a lacking point yes but unless you want to use a closed-source library it’s also a non-issue, which is why it has never been given priority. It’s not like language semantics would prevent portable dylibs it’s that there’s more important fronts to improve Rust on. A proper solution would take quite some engineering effort, and do note that C doesn’t have a proper solution either it just lets you link stuff up willy-nilly and then crash. Rust is actually in a better position to implement a proper solution than C is.
The “big project” thing is a red herring given that rust compiles incrementally. I know it is technically possible to not rebuild everything from scratch in C but the code has to specifically written to not break assumptions your build system makes while rust is happily re-using the compilation results for one function in a file while discarding those of another because actual dependencies are actually tracked. Out of the box.
Speaking of large Rust projects and proper type-safe linking: The WebAssembly folks are hashing out their Component Model which isn’t really limited to compiling to wasm, in principle: Big picture it’s a way to programmatically specify ABIs and even derive ABI translation code. That might be a good option as a rust-specific solution would be, well, rust-specific and when you engineer something that can support multiple versions of a language you can just as well engineer a bit more and have something cross-language.
I think you have things wrong. Any other languages can have libraries be distributed as some format that would allow applications to use it, be it linux/gcc and .a files ( which are actually archives with elf/object files of the code ), or a full on library like .so/.dll.
Rust can only do .o/.dll and only have it expose like a c library afaik. Even .net has improved on the .dll and includes all its language features in it. Rust has none of that. Its not true that libraries not rebuilding are only for closed source. Its also ease of use/access and less problem prone. What if i build my library using a different version of the compiler than you and your application? I could have no problems building my library, while you cant build your application because the library i made gets rebuild and errors.
These errors happen and are all because there is no stable interface/abi and all other languages have overcome this.
Also, by default, nothing in c is rebuild unless it needs to. Thats why the intermediate .o ( elf object ) files exist, so it only has to do the relinking and not recompile and thats why .a archive/libraries in c work, because it doesnt recompile. Unless you meant the fact rust can rebuild part of a file, without recompiling it completely?
I think you dont fully understand how c compilers ( gcc specifically ) work when using multi file projects ( and not just doing gcc input.c -o output.exe ) just how i dont fully know how the rust compiler works. Also, anything using IL will always have an abi, because how else will it jump from code to IL code, so its obvious that rust to wasm will have to abide by that haha.
Be it c wasm, c# wasm or rust wasm calling one another. Wasm is wasm, and you only need an exposed interface to call or include the other wasm ( c#/blazor having NativeFileReference in the csproj )
Again, i like the idea of rust, but it has a long way to go to be viable atm. And it has many pitfalls to avoid so it doesnt become the hot mess that is any framework based on node.js
I think you dont fully understand how c compilers ( gcc specifically ) work when using multi file projects
They don’t. C compilers compile single files produced by the c preprocessor (resolving all #includes), they have no concept of multi-file projects. That’s a thing for the build system, such as make, and it needs dependency information from the preprocessor to do its job (cpp -M), and once it has that it has to act correctly on them which is often completely broken because people don’t understand make. Like using it recursively, bad idea. In the wild, a random C project at work you’ll come across needs a full rebuild to build cleanly. Things have gotten better with things like cmake getting more popular but the whole thing is still brittle. GNU autohell certainly makes nothing better, ever.
Also, anything using IL will always have an abi,
Everything will always have an ABI because ABI is just API in the target language, whatever that may be. If your program is compiled and can run it uses an ABI.
Wasm is wasm, and you only need an exposed interface
The core wasm abi is less capable than the C abi: You get scalar values and pointers, that’s it. No structs, no nothing, memory layout is completely unspecified. The component model allows compilers to say “so I’m laying out strings like this and structs like that” giving linkers a chance to say “yeah I can generate glue code between you two”.
Again, i like the idea of rust, but it has a long way to go to be viable atm.
C isn’t even close to being viable according to your standards people just have gotten used to the jank.
And it has many pitfalls to avoid so it doesnt become the hot mess that is any framework based on node.js
Rust doesn’t have portable dylibs precisely because it isn’t a hot mess. Because it’s actual work to do it properly. Unlike everyone else. Meanwhile It speaks the local C ABI fluently (they differ by architecture and operating system, btw), which isn’t a thing that can be said about many languages that aren’t C.
Differently put: What, precisely, do you want to do? Have you any actual use-case for your doubts, or are they spooks?
The Rustinomicon has a chapter on it. The basics are quite simple: Declare non-opaque types to use layout matching the C ABI, export/import functions, some wibbles around name mangling. Option<T> vs. null pointers. Where things get a bit more involved is unwinding, but then you’re at the end of it, nothing should be shocking to anyone having written C.
As to how Rusty it is… not very. I mean Rust has first-class FFI support, but the way FFI stuff is written is necessarily unidiomatic because you’re basically writing C in Rust syntax and you won’t get out of declaring your own functions `unsafe’ before you read the rest of the Rustinomicon to understand what properties you need to ensure because the nice and shiny parts of Rust assume them.
Hmm. So I guess it comes down to what OP is doing. They either want to write a Rust library, or something that uses a Rust library that may not be standardised or even exist yet. If the latter, they should stick with C.
You’re aware that Rust gives you access to the full C ABI?
What language are you going to use instead that has a better ABI story? Swift? Or maybe a dynamic language like Python?
I know that exists, but whats the point of that? You loose all advantages of rust when you use the library then because it cant predict application state with the library code. There is a reason all those rust libraries are compiled locally when you compile a rust application. Its a major lacking point for rust, and as long as it lacks that its dead in the water for big projects.
Again, i like strong type stuff and i like the ideas of rust but it is not grown up enough for me
It’s a lacking point yes but unless you want to use a closed-source library it’s also a non-issue, which is why it has never been given priority. It’s not like language semantics would prevent portable dylibs it’s that there’s more important fronts to improve Rust on. A proper solution would take quite some engineering effort, and do note that C doesn’t have a proper solution either it just lets you link stuff up willy-nilly and then crash. Rust is actually in a better position to implement a proper solution than C is.
The “big project” thing is a red herring given that rust compiles incrementally. I know it is technically possible to not rebuild everything from scratch in C but the code has to specifically written to not break assumptions your build system makes while rust is happily re-using the compilation results for one function in a file while discarding those of another because actual dependencies are actually tracked. Out of the box.
Speaking of large Rust projects and proper type-safe linking: The WebAssembly folks are hashing out their Component Model which isn’t really limited to compiling to wasm, in principle: Big picture it’s a way to programmatically specify ABIs and even derive ABI translation code. That might be a good option as a rust-specific solution would be, well, rust-specific and when you engineer something that can support multiple versions of a language you can just as well engineer a bit more and have something cross-language.
I think you have things wrong. Any other languages can have libraries be distributed as some format that would allow applications to use it, be it linux/gcc and .a files ( which are actually archives with elf/object files of the code ), or a full on library like .so/.dll.
Rust can only do .o/.dll and only have it expose like a c library afaik. Even .net has improved on the .dll and includes all its language features in it. Rust has none of that. Its not true that libraries not rebuilding are only for closed source. Its also ease of use/access and less problem prone. What if i build my library using a different version of the compiler than you and your application? I could have no problems building my library, while you cant build your application because the library i made gets rebuild and errors.
These errors happen and are all because there is no stable interface/abi and all other languages have overcome this.
Also, by default, nothing in c is rebuild unless it needs to. Thats why the intermediate .o ( elf object ) files exist, so it only has to do the relinking and not recompile and thats why .a archive/libraries in c work, because it doesnt recompile. Unless you meant the fact rust can rebuild part of a file, without recompiling it completely?
I think you dont fully understand how c compilers ( gcc specifically ) work when using multi file projects ( and not just doing
gcc input.c -o output.exe) just how i dont fully know how the rust compiler works. Also, anything using IL will always have an abi, because how else will it jump from code to IL code, so its obvious that rust to wasm will have to abide by that haha. Be it c wasm, c# wasm or rust wasm calling one another. Wasm is wasm, and you only need an exposed interface to call or include the other wasm ( c#/blazor havingNativeFileReferencein the csproj )Again, i like the idea of rust, but it has a long way to go to be viable atm. And it has many pitfalls to avoid so it doesnt become the hot mess that is any framework based on node.js
They don’t. C compilers compile single files produced by the c preprocessor (resolving all
#includes), they have no concept of multi-file projects. That’s a thing for the build system, such as make, and it needs dependency information from the preprocessor to do its job (cpp -M), and once it has that it has to act correctly on them which is often completely broken because people don’t understand make. Like using it recursively, bad idea. In the wild, a random C project at work you’ll come across needs a full rebuild to build cleanly. Things have gotten better with things like cmake getting more popular but the whole thing is still brittle. GNU autohell certainly makes nothing better, ever.Everything will always have an ABI because ABI is just API in the target language, whatever that may be. If your program is compiled and can run it uses an ABI.
The core wasm abi is less capable than the C abi: You get scalar values and pointers, that’s it. No structs, no nothing, memory layout is completely unspecified. The component model allows compilers to say “so I’m laying out strings like this and structs like that” giving linkers a chance to say “yeah I can generate glue code between you two”.
C isn’t even close to being viable according to your standards people just have gotten used to the jank.
Rust doesn’t have portable dylibs precisely because it isn’t a hot mess. Because it’s actual work to do it properly. Unlike everyone else. Meanwhile It speaks the local C ABI fluently (they differ by architecture and operating system, btw), which isn’t a thing that can be said about many languages that aren’t C.
Differently put: What, precisely, do you want to do? Have you any actual use-case for your doubts, or are they spooks?
Are you suggesting OP write a C application and then compile it as Rust? I’m not a pro, but that sounds kind of janky.
I’m suggesting building a Rust library and exposing a C ABI. That’s what rsvg does for example.
Oh. There’s a still Rust-y way to do this? Nevermind.
OP wanted stability and predictability. I suppose we’ll see how entrenched one library can become.
The Rustinomicon has a chapter on it. The basics are quite simple: Declare non-opaque types to use layout matching the C ABI, export/import functions, some wibbles around name mangling.
Option<T>vs. null pointers. Where things get a bit more involved is unwinding, but then you’re at the end of it, nothing should be shocking to anyone having written C.As to how Rusty it is… not very. I mean Rust has first-class FFI support, but the way FFI stuff is written is necessarily unidiomatic because you’re basically writing C in Rust syntax and you won’t get out of declaring your own functions `unsafe’ before you read the rest of the Rustinomicon to understand what properties you need to ensure because the nice and shiny parts of Rust assume them.
Hmm. So I guess it comes down to what OP is doing. They either want to write a Rust library, or something that uses a Rust library that may not be standardised or even exist yet. If the latter, they should stick with C.
Writing C bindings to a Rust library is the easier scenario because you can rely on the safe code having nice and clean memory semantics.
Yeah, Rust has pretty good integration of it: https://doc.rust-lang.org/nomicon/ffi.html#calling-rust-code-from-c
You do lose some of the Rust-y-ness, because obviously the C ABI is much more simplistic, but in terms of a stable ABI, it’s impossible to beat C.