Hacker News Reader

Comment by Animats | Hacker News Reader

This guy wants to use Rust as a target language for a compiler. He likes that Rust doesn't have too much run-time machinery, such as a GC or a JVM. OK, fine. Compilers have been written to target C for similar reasons.

Then he wants a "battle hardened GC", a JVM, access to the internal syntax tree of the compiler, and enough dynamism to allow an interpretive environment. What? Those are all features that Rust deliberately doesn't have. Adding them would drastically change the language and add considerable complexity. They would not contribute to Rust's main goal - provide something in which to write reliable production software.

From the feature list this guy is asking for, what he really wants is Microsoft's ".NET" system. That has all the run-time stuff he wants, and multiple compilers compile to it.

View on HN

The point, which he outlines in the post, is to be able to mix high level programming with lower level languages. This is already a common pattern in the industry where you write your application in python/ruby and speed up the tight loops with C/C++/Rust. The lingua franca of the interop is C. Which means that the boundary between the two is very stark and unsafe. You can't use advanced typesystems or seamlessly share datatypes. I'm working on something similar these days (C++ and Rust though, no high level language). You lose all template/generics info at the C bindings boundary. Bindgen programs let you get it back to some degree, but forcing monomorphization/etc are all not easy problems to solve without making the compilers talk to each other (also not easy to do).

Will's idea seems to be to use Rust as a target for a high level GCd language, which can then (mostly) seamlessly interop with "pure" Rust code, and the interop won't have an unsafe boundary.

You should check how COM and now WinRT (aka 2nd coming of COM+ Runtime) work.

You get an OO ABI, with support for generics and OS level interoperability and reference counting as the GC algorithm.

Yes, using COM from C is a pain, but it was never intended to be used as such, rather C++, VB, Delphi and any other Windows language able to speak COM.

Yeah, I'm aware :) I don't like it as much but that's because I've always ended in situations where I need to bind via a C API, which isn't COM's fault.

You might want to read an article I wrote on a new technique that allows high and low level languages to be mixed (relatively) seamlessly:

https://medium.com/@octskyward/graal-truffle-134d8f28fb69

Ooh, this is cool and interesting :)

It seems to address a similar need as the one i mentioned above, among others.

The JVM, especially with Graal and Truffle, would also be a good fit: https://medium.com/@octskyward/graal-truffle-134d8f28fb69

See my comment [1] on the recent Graal/Truffle piece for why I'm moving away from those frameworks. It just seems too cumbersome to write a compiler in Java.

[1] https://news.ycombinator.com/item?id=12123657

And yet Rust, with its famously awkward borrow checker, isn't cumbersome at all? I find this set of priorities a little odd.

But if you want less verbosity, you can write your compiler in Kotlin instead. There's no requirement that Truffle languages be written in Java, they just do it that way because Java gives closest control over the bytecode which is generated. But Kotlin generates bytecode that's very similar to what Java creates, so you could use it and get a more modern syntax.

At any rate, I can guarantee you that adjusting an existing language to be less verbose or more to your liking is a lot less effort than building an entire ecosystem of compilers that try to use Rust as their lingua-franca, given that Rust was never designed for this task.

Firstly, I think that .NET is an excellent reference here. Its platform for language integration is a good model for the kind of thing I want to achieve. Honestly, I don't use it more just because I've never used C#/ASP/any CLI language. I can't give an honest comparison between my vision and what .NET offers, but I'd appreciate it if someone more versed could comment.

As for what I want from Rust: when I ask for a GC, this doesn't have to be in the compiler. It can be implemented as a library. Access to ASTs is coming in PRs (see the links in the post). And I don't need Rust to change to get a REPL, I just need to fix the darn JIT. I'm only asking Rust to change to support a few features which greatly improve the experience of using Rust as compile target.

The original idea of .NET was to migrate the whole Windows stack to it, hence why MSIL is much more flexible than JVM bytecode, as it had to be language neutral and even support C++.

Initially Microsoft was going to make it fully native and based on COM, it was called Ext-VOS project from Microsoft Research and the runtime COM+ Runtime.

Eventually they decided to create the CLR instead and things never fully worked out that way.

However with Windows 8 they have gone back to the original idea and WinRT was born. Which is basically the same COM+ Runtime ideas, but using .NET metadata instead of COM type libraries.

On Windows .NET follows a similar idea as mainframes do language interoperability by having the runtime being part of the OS.

The whole problem with GC and JIT implementations as library is that they will never be as good as the ones that work together with the compiler.

There are many types of optimization algorithms that require an helping hand of the compiler how the data structures and specific code patterns get generated.

Of course it depends what are the goals in terms of performance, throughput and latency.

See my comment above, Rust may (probably will) get intrinsics and traits that let you write a gc that works with the compiler. Not as awesome as a GC irrevocably designed into the compiler, but good enough.

I saw it, interesting reply.

But in the end what you get is a kind of compiler plugin and not a generally purpose library, right?

No, everything will be available via intrinsics, traits, and internal plugins. (as in, autoloaded #[derive()] syntax extensions as a part of rustc that the library has no part in defining) The library will look like regular rust code, and will be loaded the regular way (extern crate my_gc). There may be a special codegen flag that rust will ask you to explicitly enable (we haven't decided on this yet) which will be something cargo can do for you. But otherwise, just a library.

In fact, so far it looks like it might be possible to even have multiple GCs active at once. Not always a good idea, but a potentially useful thing to have. Whether or not the gcs should be allowed to mix is a hard question, but it is one that GC implementors can worry about -- the type system lets them forbid this behavior. Forbid is basically the default (not forbidding the behavior is harder to express and more explicit, but doable). Its the difference between implementing a concrete trait and implementing a generic trait with specialization.

The design is ultimately a magic trait that signals what should be considered a root, and an intrinsic that lets you walk these roots. There are some other traits and stuff making this palatable, but its all something that can be used in a library-esque way.

But that is what I mean, it is a pseudo-library because the code needs to integrate with those compiler hooks you just described.

Just like, for example Turbo Pascal, Delphi or .NET allow us to replace the memory allocator by initializing the runtime with an user provided library that obeys to a specific certain ABI.

Good luck with the work.

Are you aware that these guys are using Rust for language research in VM implementation?

http://microvm.github.io/

They just published "Rust as a Language for High Performance GC Implementation".

I was not aware of this. Thanks for the link.

What do you mean by compiler hooks here? I just mean intrinsics and magic traits. sizeof() is an intrinsic. It looks like a function, but isn't. Copy is a magic trait. It works like a trait but signals additional meaning to the compiler. So is Add. Implementing Add looks like implementing any other trait, except that it conveys extra meaning to the compiler. The GC support will involve basically the same thing. In fact, that intrinsic will probably be wrapped in a slightly higher level api, so you're not even directly calling an intrinsic.

Like I said, the GC will look like a normal library and be loaded the normal way. It doesn't hook into the compiler like a plugin (no library code is run at compile time), it just makes use of magic traits and functions which signal meaning to the compiler. Such traits and functions already exist in rust for non-gc purposes and get used all the time.

Rust also has that replace-allocator support you mentioned, BTW. If anything, allocator crates are more "special" that GC crates -- GC crates look like any other crate, but allocator crates have some special annotation.

I think I read a preprint of that paper, not sure (cant read the paper from here right now). It addresses the other half of the rust GC problem -- one half is designing a safe GC interface (which is solved by rust-gc or these hooks), the other is writing a good and useful GC algorithm.

Magic traits and intrisics are also a form of compiler hooks, without them the compiler will not have any idea what to do with the library.

In any case looking forward to it.

Right, but this is no different from implementing Add or Copy or FnMut or Placer, or calling sizeof or transmute or black_box, or using UnsafeCell. So its not "special" in any way. I don't disagree that its a compiler hook; that's what I called it in the first place :) I disagree that its makes the library in any way "special" or a pseudo library.

I can write a linear algebra library that gives you Vec3d and Matrix4d and the ability to multiply/add such types using regular multiplication operators. I can also write a Gc<T> library that lets you wrap some values in a GC heap allocation, which will have some extra stack maps being generated. It doesn't feel much different to me, both are equally worthy of being called libraries.

Anyway, expect a blog post soon. :)

In fact, Rust is working on hooks for GC-as-a-library. I'll be writing a blog post on this very soon. The gist of it is that you'll some intrinsics for rooting, and some useful traits, on which you can build a GC or write safe bindings to a GCd language. In line with Rust philosophy, this won't cost anything unless you use it.

(rust-gc already exists, but it can be far more efficient with some compiler support. I would recommend waiting for that.)

The main integration points between compilers and GCs are pointer maps and write/read barriers. I don't see a good way to do a GC-as-a-library given the need for the GC to contribute barrier code, which has to be tightly optimised. That's one reason Java/.NET use JIT compilers: there's not yet any one-size-fits-all GC algorithm, and all the best ones need tight compiler integration, so allowing you to pick your GC on the command line and then that impacts how the code is compiled represents a way to square the circle.

Pointer maps (stack maps) are basically what rust will get in its gc support. Rust has a stricter view on mutability, so GCs would be immutable-by-default like Rc is -- mutation would be very explicit and thus barriers are easy to insert. Yes, some optimization opportunities are lost ... but I'm optimistic :)

Ultimately it will never be as good as what Go (or whatever) can do, but it might just be good enough for the application. For cases where you are interoperating with an existing GC or using gcs for a persistent datastructure or something, the GC isn't pervasive so perf doesn't factor in as much as in, say, Java, where everything lives on the heap and the GC has to optimize a lot of extraneous stuff. Non-pervasive usage of GCs mean that the programmer is using the GC only where needed, so consequently less optimization is needed :)

What the post proposes will require a pervasive gc, however. But that GC will be pervasive in the language living on top of rust -- and that compiler/transpiler can attempt to perform optimizations. Can't exactly JIT to rust, though, so it might end up slower. Not sure by how much.

Reply on news.ycombinator.com