Hacker News new | ask | show | jobs
by tav 4048 days ago
No worries. All forgiven :)

Thank you ever so much for the hard work done by yourself and the rest of the Rust developer community. It has been an absolute pleasure seeing the language evolve, and now that it's hit 1.0, I look forward to the incredible opportunities it makes possible.

It takes great courage to go against the grain in terms of the core language (e.g. abandoning GC, M:N scheduling, etc. as core parts of the language), but the end result promises some truly exciting times. Thank you again and thank you also to you and the others for commenting here on HN despite the heavy criticism at times and being ever so helpful for those of us on IRC. It's been a fantastic ride and I look forward to it getting even better.

1 comments

> It takes great courage to go against the grain in terms of the core language

So, what I like to say is this: If you look at Rust by mission statement, it hasn't changed at all. If you look at it by feature list, it's a completely different beast.

The focus of Rust has always been a safe, fast, concurrent systems language. It just took a while to figure out exactly how we wanted to accomplish that goal.

And I'm grateful that you took your time to let the language mature.

If Rust fulfills it's mission statement, it might become widely adopted. While that's generally good, it also makes changes to the language hard, see C++.

So, let's hope you got the things right that you can't change without breaking compatibility.

Curious here: would Rust be a better language for writing the VM of an M:N-scheduled platform? Like, would rewriting Erlang's BEAM in Rust be a win?
So, in general, Rust should be good for writing VMs. If you want a JIT, though, Rust may not have any super huge advantage with it, specifically, as it would basically be all unsafe anyway.

There was a really great blog post about writing a Scheme implementation, including a GC: http://fitzgeraldnick.com/weblog/60/

I'm pretty sure even when building a JIT Rust would provide advantages. The only unsafe part of JITing is allocating the underlying instruction buffer and marking the memory as executable to the OS. You could still leverage Rust in building compilers from IR -> Instructions.
The point is that whenever you do "IR -> Instructions" you are opening the possibility for logic errors to become memory errors. E.g. emitting opcode 9 instead of opcode 8 might (on some system) allow an attacker to execute arbitrary code. And these sorts of bugs cannot be prevented by pure memory safety alone, once you have (intentionally) opened the door to writing executable memory. You would actually need a full theorem prover to check the correctness of your code for you (which obviously Rust does not provide).
Yeah, it's only for part of it, maybe the SpiderMonkey people I was talking too are more focused on the unsafe part than the other parts.
That raises the question of whether any major features that contribute to safety have been there the whole time?