Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> And yet there seems little effort to make them production-ready and deploy them; what kind of market failure is that?

At least we have Rust...



At least we have Rust...

Well, it's not really stable yet. But it is about the best candidate that I've heard of recently for this...

Since I'm not familiar with it, is it possible to write a library in Rust, and have it callable from C?

I've been doing a fair amount of golang programming recently, but calling Go from C is not possible right now (not sure if it will ever be).


Yes, it's certainly not production ready. I just mean that there is one contender that is coming that addresses this.

> is it possible to write a library in Rust, and have it callable from C?

Yup. The third production deployment of Rust is actually a Ruby extension, written in C, that is a thin wrapper over Rust. Ruby -> C -> Rust. The reason it was done this way is that Ruby's C interface is incredibly macro heavy, so it was easier to use them in a tiny C layer than to try to port them to Rust itself. For more: https://air.mozilla.org/sprocketnes-practical-systems-progra... (you'll have to scroll through to wycats' part.)


That's great. I've been meaning to learn a bit more about Rust, maybe now's the time.


I still think that now would be the ideal time to start working on a TLS/SSL implementation in Rust. First, it would mean that there would be less time between the release of Rust 1.0 and a usable library. It would also be a good project to give feedback to the Rust compiler writers.


  > is it possible to write a library in Rust, and have it 
  > callable from C?
Yes, you can generate a Rust library that exposes a C-compatible interface and then call that library from any language that can call C code.


What really bothers me about HN and the startup echo chamber at large is the idea that newness makes something inherently better.

It's like an endemic of "not invented here" fever.

A language is not inherently better simply because it is newer. Sometimes the old ways are best. Rust will not magically solve problems like this. Only more disciplined coding and auditing practices can.


You are greatly misrepresenting the comment you're replying to. It is not suggesting that Rust is better because it's newer. It's suggesting that Rust would avoid this vulnerability because Rust is designed to avoid this vulnerability. It is absolutely possible to "magically solve problems like this" at a language level. Buffer overruns are possible because of specific decisions in the design of C. They simply do not exist in, for example, Java programs. There will still be errors that can occur, but this particular bug is 100% an artifact of C.


I too, hate the 'new is better' angle. But...

> Rust will not magically solve problems like this.

I agree that it won't magically solve problems like this, but it _will_ solve problems like this. Rust guarantees protection from data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory. At compile time.


"problems like this" == "ordinary buffer overflow attack"

pretty sure Rust does magically solve those, as do most non-C(++)? languages


C++ has things that are meant to prevent this, but in the real world C++ programs tend to be vulnerable to the same sorts of attacks.


That's because C++ is an approximate superset of C, an so it inherits all of that baggage as well. This is why we need new systems programming languages like Rust, designed for the 21st century with the benefit of hindsight.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: