5 ms·

I'm thrilled to see how much progress this project is making. The ancient core of Emacs written in C is nearly impossible for a newcomer to understand. Porting

by pzone 9y ago

I'm thrilled to see how much progress this project is making. The ancient core of Emacs written in C is nearly impossible for a newcomer to understand. Porting it to Rust might make it possible to work on the codebase and feel confident that your changes is correct.

cies 9y ago
Yeah, much more hackable it will be fur sure. It may also come with speed improvements, as Rust did for FF. :) And I can imagine that writing (parts of) Emacs' plugins in Rust (for speed and/or hackability) may also be a great addition.
- draven 9y ago
  You can load shared libraries in Emacs and Rust can expose a C ABI so it should already be possible to write plugins in Rust. In the same vein, this is cool: https://github.com/janestreet/ecaml https://github.com/janestreet/ecaml
- gcb0 9y ago
  extremely naive to think a new language added perf over C++. its obviously a side effect of rewriting a 20+ yrs codebase under an updated architecture vision from scratch.
  - nbaksalyar 9y ago
    Fearless concurrency is very important for performance though. You can read more on that here: https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-Quantum.html https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-I...
  - Rusky 9y ago
    In the case of Firefox, that new architecture was impossible without Rust. Mozilla tried and failed twice.
  - arcticbull 9y ago
    It's not that it's impossible in C++ just that it's impractical to write large-scale solutions with a complex threading model with the "don't screw up" model C++ uses. The Rust compiler provides what amount to built-in unit tests with every build pass that allow you to fearlessly write code without data races. This in turn allows the new architecture you're referencing.
    - mrighele 9y ago
      I don't think you need a complex threading model. The browser showed that you can get good interaction with single-threaded environment as long as you 1) can offload computation to other processes (web services, in the case of the browser, or more recently, workers) through message-passing and 2) such interaction can be performed asynchronously (i.e. while you wait for the result you can continue with the rest). I think such kind of approach could be adopted by emacs without having to rewrite everything from scratch. Taking advantage of this would require of course rewriting a good amount of code (both elisp and C), but it could be done bit by bit over the course of a long time.
      - arcticbull 9y ago
        I think the Stylo developments show that it's not entirely true. Yes, you can get good performance from single-threaded models, and you can get better performance with threading. I'm also a huge advocate of not rewriting things, which is why Rust's C interop allows for incremental re-development of legacy codebases in a reasonable way.
        cies 9y ago
        > you can get better performance with threading Indeed. I think mrighele is talking about server side web app performance, which is a much higher level game and because a lot is stateless allows scale-out + loadbalancing to achieve resource utilization maximization. When writing hi-perf systems (like a browser), this is a very different game. In this game threading is a tool you need to make sure all cores utilized.

by pzone 9y ago

cies 9y ago

Yeah, much more hackable it will be fur sure. It may also come with speed improvements, as Rust did for FF. :) And I can imagine that writing (parts of) Emacs' plugins in Rust (for speed and/or hackability) may also be a great addition.

draven 9y ago
You can load shared libraries in Emacs and Rust can expose a C ABI so it should already be possible to write plugins in Rust. In the same vein, this is cool: https://github.com/janestreet/ecaml https://github.com/janestreet/ecaml
gcb0 9y ago
extremely naive to think a new language added perf over C++. its obviously a side effect of rewriting a 20+ yrs codebase under an updated architecture vision from scratch.
- nbaksalyar 9y ago
  Fearless concurrency is very important for performance though. You can read more on that here: https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-Quantum.html https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-I...
- Rusky 9y ago
  In the case of Firefox, that new architecture was impossible without Rust. Mozilla tried and failed twice.
- arcticbull 9y ago
  It's not that it's impossible in C++ just that it's impractical to write large-scale solutions with a complex threading model with the "don't screw up" model C++ uses. The Rust compiler provides what amount to built-in unit tests with every build pass that allow you to fearlessly write code without data races. This in turn allows the new architecture you're referencing.
  - mrighele 9y ago
    I don't think you need a complex threading model. The browser showed that you can get good interaction with single-threaded environment as long as you 1) can offload computation to other processes (web services, in the case of the browser, or more recently, workers) through message-passing and 2) such interaction can be performed asynchronously (i.e. while you wait for the result you can continue with the rest). I think such kind of approach could be adopted by emacs without having to rewrite everything from scratch. Taking advantage of this would require of course rewriting a good amount of code (both elisp and C), but it could be done bit by bit over the course of a long time.
    - arcticbull 9y ago
      I think the Stylo developments show that it's not entirely true. Yes, you can get good performance from single-threaded models, and you can get better performance with threading. I'm also a huge advocate of not rewriting things, which is why Rust's C interop allows for incremental re-development of legacy codebases in a reasonable way.
      - cies 9y ago
        > you can get better performance with threading Indeed. I think mrighele is talking about server side web app performance, which is a much higher level game and because a lot is stateless allows scale-out + loadbalancing to achieve resource utilization maximization. When writing hi-perf systems (like a browser), this is a very different game. In this game threading is a tool you need to make sure all cores utilized.