- When you say "materially different," how different are we talking? I'll admit that if you want to implement Haskell (or anything with HKT) that it's a long shot, but if you want to implement Javascript, it shouldn't be that hard, yes?
- Can you give an example of when you need type info to link?
- RE: debug info and error messages, do you disagree with what's written in the post? I agree this is an issue, but it doesn't seem unsolvable.
Generally, I guess I don't see how most languages have semantics terribly different from Rust. You don't need unsafe pointers for shared mutability with a single thread because you can use a RefCell (see: my language linked in the post). In my experience, most type systems for general-purpose languages have roughly the same feature set as Rust.
I buy that implementing a language completely different from Rust in semantics/types makes Rust not a good target, but for most languages we use nowadays, isn't that not the case?
Imagine you have machine code generated by compiling a C program and now want to figure out what struct some function takes as an argument.
As you go down towards machine code you lose information that you cannot easily recover.
Solving all of these issues is also only practical, if the Rust developers themselves cooperate. It seems to me the very purpose of creating a new language, is in freeing yourself of the limits existing ones have. Building a new language on technology that are restrictive doesn't really make sense from that perspective.
- The type system I'm thinking of includes effect inference from Koka (http://www.rise4fun.com/koka/tutorial), is simpler in other places, and has full type inference even of function signatures.
- An example of type info to link is effects. I could do things like serializing my type structures into Rust method names and then decoding them, but that's pretty hacky.
- Error reporting isn't just mapping, it's the messages too. I don't want my language getting error messages like "modification of an immutable borrow" or "cannot pass an Rc<RefCell<MyLangInt>> to a function that takes an Rc<RefCell<Vec<MyLangInt>>" when it doesn't look like that or have those constructs.
- RefCell has runtime overhead where every other compiled language doesn't.
- I think the type systems of most statically typed languages are substantially different from Rust that it would be an impedance mismatch.
I think this is only remotely better for dynamically typed languages, since that also solves a lot of the issues with errors since those are mostly created by your runtime functions.
As a supporting point, TypeScript requires definition files (.d.ts) for JavaScript libraries to properly type them. Unless the language has a 1:1 correspondence to Rust types, something similar will probably need to happen.
Embedding the Rust compiler would be pretty difficult, especially if your compiler isn't written in Rust.
I think that using Rust as a compiler target is a completely goofy idea. But perhaps Rust's MIR intermediate representation could work for other source languages.
- almost nobody has Rust installed already, and it's a ~100MB download. With a new version every six weeks or so.
Linking to Go libraries from a certain type of language could be super easy and the libraries would be nice enough to use to not need a wrapper layer.
I talked about that because IMO a really important part of having a usable language is an ecosystem, and if you're going to start a new language today piggybacking off of Go's sounds like a good plan.
- Your compile times will be a lot slower than they would otherwise be. This is a big one for me.
- If your type system is materially different than Rust's, you don't gain any benefits since you have to write your own type checker anyways.
- LLVM is designed to be easy to machine generate, including having a library API for generating code. Rust doesn't yet.
- You can't necessarily re-use Cargo if your language requires type info to link that wouldn't be in the Rust source files generated.
- If you have semantic differences in memory model you'll need to give up the advantage of Rust's safety by having your code generate unsafe pointers, for example if you want to have shared mutability in a single-threaded context, which Rust doesn't handle nicely.
- If you do re-use Rust's type checker the error messages you get out will be terrible and point into generated Rust code.
- Debug info and debugging get even harder.
- If you want Rust interoperability you have to replicate Rust's enormous type system in your language's FFI, which is hard if you also have your own type checker, see above.
Basically it is a good idea, if your language has semantics and type system very close to Rust.
A much better idea IMO is to target LLVM and then write an LLVM plugin that can link to Golang object files and generate Golang struct metadata. Golang's FFI and type system are much much simpler and more likely to be able to graft onto new languages. Also Go's library ecosystem is larger.