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

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!




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

Search: