Hacker News new | past | comments | ask | show | jobs | submit login

As a long-time Rust guy, this article makes little sense to me. It is surely possible for any language to target Rust, but unless the semantics of that language are an unusually close match to Rust's then you're going to have to pull off some gymnastics. LLVM IR is actually designed to be a decent compilation target for a wider variety of languages (though I wish there was more documentation on what is and is not UB), but even LLVM IR is going to start looking like a poor choice of a target the farther your language is from C++.



As part of a recent project I had to: - build an AST from a large and complicated DSL - transform the AST into something that could be compiled into a DSO.

I chose to write both parts in Rust. Fwiw the semantics of the language really didn't match Rust at all (though, I suspect you weren't thinking of DSLs when you wrote your paragraph).

In the end I had all the benefits of _safe_ Rust when compiling the transformed code into the DSO.

This DSO is a critical component and can not fail. I can't imagine transforming the AST into C or LLVM - I wouldn't be able to sleep at night. I'm only human; I know I'd fall into a number of traps that humans fall into when coding in C - especially when I am _generating_ C from an AST...


Can you give an example of when language semantics are so different from Rust that it would be difficult to do this kind of thing? When I wrote this article, I was thinking major languages: Javascript, Java, Matlab, etc. and to my mind they all are suitable for compiling to Rust. Granted, I don't know the Java specification or its internals, I'm not claiming right now that everything specified by the JVM can definitely get ported to Rust, but moreso the general ideas behind the languages.


Rust has a unique design that would be rather difficult to map other languages efficiently to, unless you simply used it as as complicated assembly language, in which case why not just use LLVM?

Most obviously you cannot map Javascript or Java methods or variables directly to Rust because these languages don't have anything like the borrow checker. You could come up with a way to work around that, but then why target Rust at all?

I think there's a deeper problem with your proposal though, which is - why? I know you try and answer that in the article but I found it unconvincing. The JVM was explicitly designed to solve the problem you're trying to solve, as you clearly know, so a good starting point would be to much more thoroughly analyse why you aren't satisfied with it.

You say you have to "shoulder the runtime overhead of a garbage collector" but then name lots of languages you want to compile to Rust, all of which assume and require the presence of a garbage collector. Then later you talk about needing a good GC written in Rust. Well ... why? If you're gonna have to provide a GC anyway for practically every modern language, then the runtime overhead of this will be paid no matter what.

Having studied the JVM quite extensively, I don't see much in it that's obviously wrong or could be done wildly better, but I see a lot that's done right. If you re-walk that path, you will probably end up reinventing the wheel.


> Rust has a unique design that would be rather difficult to map other languages efficiently to...

With regards to efficiency, a "unique design" is of little direct consequence; we are always mapping from one very different language to another, since assembly bears ultimately little resemblance to Java or Ruby or Haskell.

A language can be a bad compile target but that has more to do with runtime restrictions. For example, it's hard to build command line tools that start quickly if you target the JVM. Compacting GC can make interop with other languages hard (since objects get moved around). But Rust doesn't come with abstractions or an execution model that are any more heavy weight than C++ (which is no way a bad language for implementing interpreters or compilers, and has even served as a compile target on occasion); in fact it is a more conservative extension of C than C++ is.

Rust does impose a burden that is kind of like saying, your compiler/interpreter has to pass Valgrind+Coverity; but this is perhaps more of a help than a hindrance -- and it doesn't limit the kind of language you can write.


> For example, it's hard to build command line tools that start quickly if you target the JVM.

Only for those that don't know what they are doing.

There are plenty of JDKs that AOT compile to native code.


Including the freely-available GCJ, a part of GCC that's not often included by default anymore.


Isn't GCJ obsolete and dead?


It is obsolete as most of its devs moved on to other stuff.

But the gcc folks keep it alive, because many of the gcj unit tests stress parts of the toolchain that other languages don't use.

So I imagine that for quick command line scripts that can live with an aged Java 1.4 API it might still work.


Okay, so how do I do this? Because if I write a simple Scala program that prints "Hello World" it can take like three seconds to start.


I think that's pretty much untrue.

That program is 0.x seconds on Scala-JVM and 0.0x seconds on Scala-Native.


Well, Scala-Native should of course be much faster.

The last time I looked at this was a awhile back; maybe it was 0.3 seconds and I misremembered it.


That sounds more like a Scala issue than anything else. A Java Hello World app runs in about 50 msec.


Javascript has very different semantics from rust. It's not compiled for one thing, it's untyped, and it's executed by a dynamic interpreter that, in the case of v8, directly compiles hot code to native assembly.


Counterpoint: I'm writing a language to do just that [1]. A lot of the basis from this post comes from my experiment in writing Javascript that compiles to Rust!

[1] https://github.com/willcrichton/lia


Look forward to seeing the benchmarks. Good luck!


UB as in undefined behavior?


Yes




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

Search: