Hacker News Reader

Comment by steveklabnik | Hacker News Reader

There isn't a strong ETA, no. Everything about internals is basically waiting until after the HIR/MIR work lands, as it would end up changing a lot anyway, so that's where the focus is at the moment.

That doesn't mean the _discussion_ about how it works has to stop in the meantime, though...

View on HN

Well even a guesstimate would be nice :)

I've been following Rust from sidelines before 1.0 and from my perspective there are advantages but I can also see a lot of pain in porting stuff and moving over and I right now the benefits don't outweigh the risk and cost for me - but having a fast build system (which implies incremental recompilation) along with a default package manager (which it already has) would be enough for me to start working with it seriously.

It's kind of sad that building code is such an instrumental part of developing C++ when it's just about dealing with technical issues of the compiler/language/tools and not the problems I'm trying to solve - anything that gets me away from that while leaving me with similar level of memory control and portability is a big win for me.

So when should I be looking back at it ? 6 months ?

There's two components to this. I just asked the relevant people, they said "Six months is a safe guess, we hope sooner, we have ambitious plans, we'll see."

However, there's also something mentioned in this announcement: cargo-check. In terms of the "I'm building a project and I don't want my builds to be slow," I think that cargo-check might even be more important. cargo-check relies on an important insight: many times, when you're compiling, you don't actually care about producing a binary, you care that your code passes typechecking and other passes. cargo-check basically runs those things, and doesn't produce the final binary. Makes sense?

Is this something which the editor plugins can make use of? (as a quick lint/feedback about the code). My guess is that the plugins actually use naked rustc call rather than cargo build.

Currently, it basically runs `rust -Zverbose -Zno-trans`, so yes. If it gets more advanced, we'll see.

What would make you choose swift vs rust at this point? The compile speeds have been getting pretty close to objective-c levels, there is 1st and 3rd party package management and its been recently open sourced and is actually being developed in the open.

On top of that they have the financial backing of apple.

Does Swift run on Windows ? Emscripten ? Android ? Portability is also a big question that Rust has a lot better incentives to solve than Apple.

I got the impression that Linux support is more of a "here iOS/OSX develoeprs - we're aware you don't actually run OSX on your servers so you can share code between client and server now". I was not aware Apple wants to push Swift as a cross platform language.

If it was and their commitment looked credible (ie. they start porting tools like integrating debuggers and stuff on other platforms as well) I would definitely consider it.

If you want a guess, I guess "in 2016".

For the ignorant among us, do you have a link explaining what HIR/MIR is (and how it relates to Rust)?

I should blog about it, because I keep writing comments. :)

So, the basic process of compiling is:

  source -> AST -> LLVM IR -> asm

At each step, you can do transforms too, so like, LLVM will take in LLVM IR, but before compiling, will simplify/transform it into other IR.

There's a few issues with this. The first is that any processing we want to do, like optimizations, safety checks, etc, has to work on the AST. This means that when the AST changes, these features need to change. This is why compiler plugins aren't stable, we're not ready to stabilize the AST yet. Doing so would mean things like "we can never add a new keyword", or at least, makes that process harder.

The final process for Rust will look like

  source -> AST -> HIR -> MIR -> LLVM IR -> asm

HIR is "higher IR" and MIR is "mid IR". In this sense, LLVM IR is a "low IR". There's two important aspects here: the first is that this decouples the AST from things like plugins, which can operate on the HIR, which we will stabilize. The second is that at each step, things get simpler. Here's an example. We have both regular old if statements, and match, which can do more powerful, structural things. Both are fundamentally jump statements, though, and so we can transform the more complex match into the more primitive if. This means that by writing safety checks, optimizations, and other things against MIR, they're both easier to write, as well as more maintainable.

There's one other minor benefit: Someone who wants to write an alternate compiler could theoretically write MIR -> ASM, and eliminate LLVM entirely. While we have less than zero percent chance of doing that ourselves, it might be nice if you want to support some sort of esoteric platform LLVM doesn't, for example.

Does that all make sense?

It does make sense, and thank you very much for taking the time to explain! :)

What does HIR/MIR mean ?

https://news.ycombinator.com/item?id=10713301

Reply on news.ycombinator.com