4 ms·

The best advantage of writing libraries in C is that it allows the library to be usable via FFIs in many other languages. Also, C is extensively standardised, w

by gkya 12y ago

The best advantage of writing libraries in C is that it allows the library to be usable via FFIs in many other languages. Also, C is extensively standardised, widely used and thus greatly test-covered. This is a nice property of the language, as the programmers can be sure that as long as they follow the standards, they'll find a compiler to compile the programs they write. I have not used Rust for more that «Hello world!», but I know that I'd regret sooner or later, if I wrote a multi-million line project in a language that is not somehow standardised. Also, memory safety is hard to enforce, I reckon, while controlling the memory hardware, which is what an operating system like Linux* has to do. Rust can be used, but still, there are many unsafe things that OS has to do, like moving and assigning pages, managing which programs use which pages, swapping, etc.; which, I reckon, requires knowledge and usage of physical memory addresses and access to individual bytes. Rust may be an appropriate and advantageous language to use for the non-core parts of a microkernel, though. * I acknowledge that Linux is not an operating system per se.

DCKing 12y ago
Rust has memory safety by default. However, it can do memory unsafe things in special blocks[1]. So it can do everything low level that C can, including controlling memory hardware [2]. It does unsafe things only in special blocks that can be specifically audited. That's part of why I find it so promising. C has no memory safety by default. So if you want to audit your C program for memory safety problems, those problems can be anywhere. Even if that C program/component doesn't actually need such low level access in the first place! [1]: http://static.rust-lang.org/doc/master/rust.html#unsafety http://static.rust-lang.org/doc/master/rust.html#unsafety [2]: Here's a list of (hobby) kernels written in Rust: https://github.com/mozilla/rust/wiki/Operating-system-development https://github.com/mozilla/rust/wiki/Operating-system-develo...
- gkya 12y ago
  Everytime I say something negative about Rust, the counterarguments push me to learn the language. I'll definitely check out the kernels page, thanks a lot for that. With your comments I have to concur. I have also read a comment on name-mangling somewhere on this thread, probably one that you've written. If C can be replaced with Rust for most-if-not-all applications in future, it is a step forwards IMO.
  - jnbiche 12y ago
    In my opinion, your argument about only C being usable from FFI is a strong one against using Rust if you're making a library. It is possible to expose Rust data and functions to Python, Ruby, etc, since Rust is ABI-compatible with C. Unfortunately, you lose most of the Rust standard library since the Rust runtime is not freestanding. And I'm not sure how -- or if -- Rust will fix this issue. It's certainly desired, but it will be a lot of work. The only bright side to all of this is that Rust is such a modern and pleasant language to use that scripting language bindings are almost not needed. Almost. But it's still a enough of a low-level language that bindings are highly desirable for quick prototypes, exploratory programming, and other scripting tasks.
    - kibwen 12y ago
      > I'm not sure how -- or if -- Rust will fix this issue. We're addressing this as we speak! We've split out the stdlib into many constituent libraries that depend on each other, and then just made the stdlib a convenient facade for these libraries. After opting out of the stdlib, you can then opt into any of the "core" libraries as you like, a la carte. Many of these smaller libs don't rely on the runtime (they don't depend on librustrt) nor do they rely on allocation at all (liballoc), and can thus be used in a freestanding environment. See the other comment in this thread for more details: https://news.ycombinator.com/item?id=7883451 https://news.ycombinator.com/item?id=7883451
      - jnbiche 12y ago
        Oh wow, that's great to hear. Any idea when/if basic, safe network/file IO will be possible without the runtime? Or is it already?
throwaway0010 12y ago
> Also, C is extensively standardised Not really, at least not in the sense that you mean here: The generation of machine code in shared objects. There is a distinct lack of definition between C syntax and the resulting machine code. > The best advantage of writing libraries in C is that it allows the library to be usable via FFIs in many other languages. You can create C shared objects from Rust (or from a ton of other languages which generate native code). No big deal. It can do what you want.
- asuffield 12y ago
  > There is a distinct lack of definition between C syntax and the resulting machine code. And more importantly: there is a distinct lack of similarity in behavior in this respect between vendors, versions, architectures, language features, ambient temperatures, and times of day. Change any of those things and you can get different output from your C compiler.
- fithisux 12y ago
  But not C include files. I think nimrodhas something here. Vala? I do not know.
  - dbaupp 12y ago
    That's just because Rust is still in development, and tooling like that is developed incrementally. There's already an issue about automatically creating C headers representing a Rust library, https://github.com/mozilla/rust/issues/10530 https://github.com/mozilla/rust/issues/10530 (and Alex Crichton has even started working on a tool for it, see his comment).
pcwalton 12y ago
> The best advantage of writing libraries in C is that it allows the library to be usable via FFIs in many other languages. Rust has allowed this for over a year at this point. For example, see the (old) blog post "Embedding Rust in Ruby": http://brson.github.io/2013/03/10/embedding-rust-in-ruby/ http://brson.github.io/2013/03/10/embedding-rust-in-ruby/
- steveklabnik 12y ago
  And the third production deployment of Rust is at Tilde for skylight, which uses a Ruby extension written as a Rust library with a thin C wrapper, due to Ruby's extensive C macros which would be annoying and bug-prone to port.
fithisux 12y ago
Like creating servers or user space drivers. That is what IOMMU is for.

by gkya 12y ago

DCKing 12y ago

Rust has memory safety by default. However, it can do memory unsafe things in special blocks[1]. So it can do everything low level that C can, including controlling memory hardware [2]. It does unsafe things only in special blocks that can be specifically audited. That's part of why I find it so promising. C has no memory safety by default. So if you want to audit your C program for memory safety problems, those problems can be anywhere. Even if that C program/component doesn't actually need such low level access in the first place! [1]: http://static.rust-lang.org/doc/master/rust.html#unsafety http://static.rust-lang.org/doc/master/rust.html#unsafety [2]: Here's a list of (hobby) kernels written in Rust: https://github.com/mozilla/rust/wiki/Operating-system-development https://github.com/mozilla/rust/wiki/Operating-system-develo...

gkya 12y ago
Everytime I say something negative about Rust, the counterarguments push me to learn the language. I'll definitely check out the kernels page, thanks a lot for that. With your comments I have to concur. I have also read a comment on name-mangling somewhere on this thread, probably one that you've written. If C can be replaced with Rust for most-if-not-all applications in future, it is a step forwards IMO.
- jnbiche 12y ago
  In my opinion, your argument about only C being usable from FFI is a strong one against using Rust if you're making a library. It is possible to expose Rust data and functions to Python, Ruby, etc, since Rust is ABI-compatible with C. Unfortunately, you lose most of the Rust standard library since the Rust runtime is not freestanding. And I'm not sure how -- or if -- Rust will fix this issue. It's certainly desired, but it will be a lot of work. The only bright side to all of this is that Rust is such a modern and pleasant language to use that scripting language bindings are almost not needed. Almost. But it's still a enough of a low-level language that bindings are highly desirable for quick prototypes, exploratory programming, and other scripting tasks.
  - kibwen 12y ago
    > I'm not sure how -- or if -- Rust will fix this issue. We're addressing this as we speak! We've split out the stdlib into many constituent libraries that depend on each other, and then just made the stdlib a convenient facade for these libraries. After opting out of the stdlib, you can then opt into any of the "core" libraries as you like, a la carte. Many of these smaller libs don't rely on the runtime (they don't depend on librustrt) nor do they rely on allocation at all (liballoc), and can thus be used in a freestanding environment. See the other comment in this thread for more details: https://news.ycombinator.com/item?id=7883451 https://news.ycombinator.com/item?id=7883451
    - jnbiche 12y ago
      Oh wow, that's great to hear. Any idea when/if basic, safe network/file IO will be possible without the runtime? Or is it already?

throwaway0010 12y ago

> Also, C is extensively standardised Not really, at least not in the sense that you mean here: The generation of machine code in shared objects. There is a distinct lack of definition between C syntax and the resulting machine code. > The best advantage of writing libraries in C is that it allows the library to be usable via FFIs in many other languages. You can create C shared objects from Rust (or from a ton of other languages which generate native code). No big deal. It can do what you want.

asuffield 12y ago
> There is a distinct lack of definition between C syntax and the resulting machine code. And more importantly: there is a distinct lack of similarity in behavior in this respect between vendors, versions, architectures, language features, ambient temperatures, and times of day. Change any of those things and you can get different output from your C compiler.
fithisux 12y ago
But not C include files. I think nimrodhas something here. Vala? I do not know.
- dbaupp 12y ago
  That's just because Rust is still in development, and tooling like that is developed incrementally. There's already an issue about automatically creating C headers representing a Rust library, https://github.com/mozilla/rust/issues/10530 https://github.com/mozilla/rust/issues/10530 (and Alex Crichton has even started working on a tool for it, see his comment).

pcwalton 12y ago

> The best advantage of writing libraries in C is that it allows the library to be usable via FFIs in many other languages. Rust has allowed this for over a year at this point. For example, see the (old) blog post "Embedding Rust in Ruby": http://brson.github.io/2013/03/10/embedding-rust-in-ruby/ http://brson.github.io/2013/03/10/embedding-rust-in-ruby/

steveklabnik 12y ago
And the third production deployment of Rust is at Tilde for skylight, which uses a Ruby extension written as a Rust library with a thin C wrapper, due to Ruby's extensive C macros which would be annoying and bug-prone to port.

fithisux 12y ago

Like creating servers or user space drivers. That is what IOMMU is for.