8 ms·

As someone that writes a lot in Rust, I have a longstanding dream to make a compiler for a subset of the language, since I don’t use all features of Rust and my

As someone that writes a lot in Rust, I have a longstanding dream to make a compiler for a subset of the language, since I don’t use all features of Rust and my hope is that this way I could have fast debug builds (in terms of compilation time) while I develop, with simplified borrow checker and so on. So then I can iterate faster. That’s one of my dreams. But I have not had time to even look at it yet, as the other code I work on takes precedence at the moment.

breck 5y ago
Haven’t looked at the rust compiler code base, but often with languages you can hack together subsets via deletions and comments and flags of existing compilers.
tyingq 5y ago
Maybe some ideas here: https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc
- amelius 5y ago
  Why would someone write a bootstrapping rust compiler in C++ when you can just compile the rust to C using a proper llvm backend?
  - tyingq 5y ago
    Bootstrapping on platforms where llvm isn't supported?
    - amelius 5y ago
      I don't see why you would want to do that as you can always ssh into a system where llvm is supported, then compile to C, copy the C sources back to your system and compile rustc using a C compiler.
      - tyingq 5y ago
        Perhaps the generated C isn't as portable (endianess, byte alignment, etc).
      - im_down_w_otp 5y ago
        How are you compiling to C? With the LLVM IR to C backend that was (is?) maintained by the Julia folks? My experience from a couple years ago was that it didn't produce output which would compile with baroque C toolchains for platforms that LLVM doesn't support... I'm giving very unsubtle side eye to you TriCore.
        amelius 5y ago
        Well, in any case, writing a backend for rust or llvm that generates C is probably still less work than writing an entire rust compiler. Maintaining it is even orders of magnitude less work than maintaining a C++ "shadow" version of the rust compiler.
  - Zababa 5y ago
    LLVM doesn't support everything. If you want to see what is not supported, the story about Python cryptography migrating from C to Rust is a good start https://lwn.net/Articles/845535/ https://lwn.net/Articles/845535/.
    - deleted 5y ago
      [deleted]
bilkow 5y ago
I don't think borrow checking plays a significant roles in most projects compiling performance. Running `cargo check` generally runs a lot faster (after the first run) than `cargo build`, even if it runs borrow checking, etc. AFAIR macro expansion, LLVM code generation and linking takes a lot of time, but it depends on the project. In the perf site you can see some examples: https://perf.rust-lang.org/ https://perf.rust-lang.org/
verdagon 5y ago
Any ideas on how one can simplify the borrow checker?
- timClicks 5y ago
  You could implement it as a runtime check
  - skohan 5y ago
    Why not just use GC at that point? I thought the whole USP is the zero runtime cost
    - timClicks 5y ago
      It would be a garbage collector. I assumed that the person asking the question was primarily looking for a simpler implementation option, not to re-create rustc exactly.
- pjmlp 5y ago
  Use a garbage collected language instead. Eventually as optimization point, for the few use cases where the ultimate performance is needed, provide a subset of borrow checker capabilities. Examples of current efforts into this direction, D, Swift, Haskell, Chapel, some .NET ongoing research.
- mbStavola 5y ago
  Niko Matsakis, of Rust's lang and compiler teams, has a talk[1] on how the machinery behind borrow checker is being rethought. The idea is that in the future, the compiler won't really "check borrows" but will instead "track origins." Reframing the system in this way will (hopefully) make things be flexible enough to Just Work™ without surprises, while providing the same guarantees as the current borrow checker. The video itself has a motivating example or two that shows where this stuff would be helpful. [1]: https://youtu.be/_agDeiWek8w https://youtu.be/_agDeiWek8w
  - 5y ago
Zababa 5y ago
I think you would be better served by a simplified, less optimized code generation, as from what I understand LLVM is the thing that takes a lot of time. You can see this pattern in Crystal and Swift for example, that also use LLVM and are also relatively slow to compile, compared to OCaml or Go which have their own backend.
- rlp 5y ago
  There's a Cranelift backend, which is apparently faster at creating debug builds than LLVM: https://github.com/bjorn3/rustc_codegen_cranelift https://github.com/bjorn3/rustc_codegen_cranelift
- pjmlp 5y ago
  Or Haskell, which also has multiple backends to choose from.
- mhh__ 5y ago
  The D compiler has Walters last compilers backend. It is very useful to have a really fast debug build. It's also potentially remarkable how slow LLVM is given that the D compilers backend is actually pretty inefficient in places yet still munches LLVM on debug builds.
- user-the-name 5y ago
  That is definitely not the case. Compiling C with LLVM is very fast. In Swift, type inference is one thing that can be extremely slow.
  - Zababa 5y ago
    That's fair, Crystal seems to also take a lot of time with type inference. However the LLVM codegen is almost constantly slower than the alternatives. For example, Haskell has a non-LLVM backend and a LLVM backend, and the LLVM backend is slower. Zig uses LLVM, and they are working on a non-LLVM backend to speed up development builds. A sibling comment mentioned that the situation is the same for D too. For C, I'm almost certain that TCC is faster than Clang with LLVM. There seems to be a pattern here. I'm not saying that LLVM is bad, in fact if it's used by so many projects it's for a reason. But it does have a cost.
gwbas1c 5y ago
I'd like a GC (no borrow checker) version of Rust. There's so many cool concepts in the language that I'd like to know how useful it is in different contexts. (Compiled without a VM, option types, no nulls, easy error handling without exceptions...)
- Zababa 5y ago
  You could try OCaml (it does have exception but they're usually "opt in"), it's a really nice language and probably one of the closest to GC'd Rust. There's also Swift that inspired some features.
  - awestroke 5y ago
    OCaml is often dropped due to its unpredictable performance
    - Zababa 5y ago
      I've heard the opposite about it, that its predictable performance is one of its strength. Do you have any sources?
      - awestroke 5y ago
        Darklang is being rewritten in .Net Flowtype has horrible performance, which in my opinion partially explains why it has lost so many users to Typescript, which has much more predicable and fast performance even though it's written in JS. The project is basically dead
        octachron 5y ago
        None of this seems related to OCaml performance? Darklang is being rewritten to .Net because they were unsatisfied with the OCaml ecosystem. Horrible performance is generally more a question of algorithms and software architecture than a problem with a language, which only account for a flat percentage of performance.
brundolf 5y ago
Check out cranelift: https://blog.rust-lang.org/inside-rust/2020/11/15/Using-rustc_codegen_cranelift.html https://blog.rust-lang.org/inside-rust/2020/11/15/Using-rust...

breck 5y ago

Haven’t looked at the rust compiler code base, but often with languages you can hack together subsets via deletions and comments and flags of existing compilers.

tyingq 5y ago

Maybe some ideas here: https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc

amelius 5y ago
Why would someone write a bootstrapping rust compiler in C++ when you can just compile the rust to C using a proper llvm backend?
- tyingq 5y ago
  Bootstrapping on platforms where llvm isn't supported?
  - amelius 5y ago
    I don't see why you would want to do that as you can always ssh into a system where llvm is supported, then compile to C, copy the C sources back to your system and compile rustc using a C compiler.
    - tyingq 5y ago
      Perhaps the generated C isn't as portable (endianess, byte alignment, etc).
    - im_down_w_otp 5y ago
      How are you compiling to C? With the LLVM IR to C backend that was (is?) maintained by the Julia folks? My experience from a couple years ago was that it didn't produce output which would compile with baroque C toolchains for platforms that LLVM doesn't support... I'm giving very unsubtle side eye to you TriCore.
      - amelius 5y ago
        Well, in any case, writing a backend for rust or llvm that generates C is probably still less work than writing an entire rust compiler. Maintaining it is even orders of magnitude less work than maintaining a C++ "shadow" version of the rust compiler.
- Zababa 5y ago
  LLVM doesn't support everything. If you want to see what is not supported, the story about Python cryptography migrating from C to Rust is a good start https://lwn.net/Articles/845535/ https://lwn.net/Articles/845535/.
  - deleted 5y ago
    [deleted]

bilkow 5y ago

I don't think borrow checking plays a significant roles in most projects compiling performance. Running `cargo check` generally runs a lot faster (after the first run) than `cargo build`, even if it runs borrow checking, etc. AFAIR macro expansion, LLVM code generation and linking takes a lot of time, but it depends on the project. In the perf site you can see some examples: https://perf.rust-lang.org/ https://perf.rust-lang.org/

verdagon 5y ago

Any ideas on how one can simplify the borrow checker?

timClicks 5y ago
You could implement it as a runtime check
- skohan 5y ago
  Why not just use GC at that point? I thought the whole USP is the zero runtime cost
  - timClicks 5y ago
    It would be a garbage collector. I assumed that the person asking the question was primarily looking for a simpler implementation option, not to re-create rustc exactly.
pjmlp 5y ago
Use a garbage collected language instead. Eventually as optimization point, for the few use cases where the ultimate performance is needed, provide a subset of borrow checker capabilities. Examples of current efforts into this direction, D, Swift, Haskell, Chapel, some .NET ongoing research.
mbStavola 5y ago
Niko Matsakis, of Rust's lang and compiler teams, has a talk[1] on how the machinery behind borrow checker is being rethought. The idea is that in the future, the compiler won't really "check borrows" but will instead "track origins." Reframing the system in this way will (hopefully) make things be flexible enough to Just Work™ without surprises, while providing the same guarantees as the current borrow checker. The video itself has a motivating example or two that shows where this stuff would be helpful. [1]: https://youtu.be/_agDeiWek8w https://youtu.be/_agDeiWek8w
- 5y ago

Zababa 5y ago

I think you would be better served by a simplified, less optimized code generation, as from what I understand LLVM is the thing that takes a lot of time. You can see this pattern in Crystal and Swift for example, that also use LLVM and are also relatively slow to compile, compared to OCaml or Go which have their own backend.

rlp 5y ago
There's a Cranelift backend, which is apparently faster at creating debug builds than LLVM: https://github.com/bjorn3/rustc_codegen_cranelift https://github.com/bjorn3/rustc_codegen_cranelift
pjmlp 5y ago
Or Haskell, which also has multiple backends to choose from.
mhh__ 5y ago
The D compiler has Walters last compilers backend. It is very useful to have a really fast debug build. It's also potentially remarkable how slow LLVM is given that the D compilers backend is actually pretty inefficient in places yet still munches LLVM on debug builds.
user-the-name 5y ago
That is definitely not the case. Compiling C with LLVM is very fast. In Swift, type inference is one thing that can be extremely slow.
- Zababa 5y ago
  That's fair, Crystal seems to also take a lot of time with type inference. However the LLVM codegen is almost constantly slower than the alternatives. For example, Haskell has a non-LLVM backend and a LLVM backend, and the LLVM backend is slower. Zig uses LLVM, and they are working on a non-LLVM backend to speed up development builds. A sibling comment mentioned that the situation is the same for D too. For C, I'm almost certain that TCC is faster than Clang with LLVM. There seems to be a pattern here. I'm not saying that LLVM is bad, in fact if it's used by so many projects it's for a reason. But it does have a cost.

gwbas1c 5y ago

I'd like a GC (no borrow checker) version of Rust. There's so many cool concepts in the language that I'd like to know how useful it is in different contexts. (Compiled without a VM, option types, no nulls, easy error handling without exceptions...)

Zababa 5y ago
You could try OCaml (it does have exception but they're usually "opt in"), it's a really nice language and probably one of the closest to GC'd Rust. There's also Swift that inspired some features.
- awestroke 5y ago
  OCaml is often dropped due to its unpredictable performance
  - Zababa 5y ago
    I've heard the opposite about it, that its predictable performance is one of its strength. Do you have any sources?
    - awestroke 5y ago
      Darklang is being rewritten in .Net Flowtype has horrible performance, which in my opinion partially explains why it has lost so many users to Typescript, which has much more predicable and fast performance even though it's written in JS. The project is basically dead
      - octachron 5y ago
        None of this seems related to OCaml performance? Darklang is being rewritten to .Net because they were unsatisfied with the OCaml ecosystem. Horrible performance is generally more a question of algorithms and software architecture than a problem with a language, which only account for a flat percentage of performance.

brundolf 5y ago

Check out cranelift: https://blog.rust-lang.org/inside-rust/2020/11/15/Using-rustc_codegen_cranelift.html https://blog.rust-lang.org/inside-rust/2020/11/15/Using-rust...