[andreaferretti]

In fact, as a compilation target, one wants a language with a lax semantics, not a strict one. This is (one of the reasons) why so many languages compile to C, instead of - say - to C++.

Consider this fact for example: many languages make use of objects allocated on the heap in a way that prevents to know statically when they are to be disposed; then a GC takes care of that dinamically. How are they going to give Rust the necessary information to track lifetimes, when the information is not there to start with? Of course, one can just write a GC in Rust, but how is this an improvement with respect to a GC written in C?

Also - what about typed languages - such as Go - that do not have generics? These are not going to map well to the Rust type system. Or what about lazy languages? Or languages that save the stack on the heap to implement call/cc?

In short, whenever the semantics is different enough, you will not be able to map to idiomatic Rust constructs, and in fact if you don't want to pay the cost of interpretation, you will probably map to unsafe constructs most of the time.

[Manishearth]

Rust most probably will be getting hooks that make it possible to safely integrate efficient GCs. Writing a safe nonconservative GC for rust has already been done, and once these hooks are in place it should be possible to write a good GC. Though for a codegenned language on top of rust you may not need these hooks.

https://github.com/mystor/rust-callcc is callcc for Rust. Technically abuses a feature for a purpose it was explicitly not intended for, but meh :)

callcc and gc are usually not useful operations in rust. That doesn't mean that its not possible to implement them. The implementation might be annoying to use, but of you are codegenning to rust this doesn't matter.

Yes, some semantics won't copy over. I feel like most would though. Those that don't can often be emulated at the lower level with enough codegen.

[andreaferretti]

It's not that writing a GC is impossible - of course it is doable. The issue is that objects written in this hypothetical language will always make use of the GC because they do not have lifetime information in the first place. So the question arises naturally: why bother compiling to Rust if you have to avoid the borrow checker anyway?

[Manishearth]

The reason I gave in https://news.ycombinator.com/item?id=12148269 applies here too. Clean interop. The ability to freely use a GCd language and smoothly transition to Rust when necessary.

And Rust-as-a-target doesn't necessarily mean you're doing it for the borrow checker. It could also be the typesystem (with the perf and safety of lower level code as a unique bonus). Yes, other, better, typesystems exist, but nobody's saying that Rust is the only language you can do this with :)

[andreaferretti]

How is Rust type system helpful? If the codegen produces valid Rust, the Rust type system will not give errors. If it doesn't, I'd say it is a bug of the higher level language - and at best the user is going to see a type error of Rust, while working in X, which is not the best user experience.

Really, these kind of checks belong to the frontend.

[Manishearth]

No, I mean if you want your higher level language to have a typesystem similar to that of Rust. As I mentioned in the other comment, interop between high level and low level languages usually happens through the medium of C, in which all type information is lost. If your higher level language is compiling to Rust, you can easily add Rusty typesystem features with seamless interop.

I'm not saying Rust's compile errors should ever be shown to the user. I don't think that's what the OP is suggesting either. If rustc errors you should emit an internal compiler error, because your higher level compiler should be producing valid rust code.