12 ms·

Someday this is going to need to happen though. IMO, "the right way" to do this is via the strangler pattern: https://www.michielrook.nl/2016/11/strangler-pat

Someday this is going to need to happen though. IMO, "the right way" to do this is via the strangler pattern: https://www.michielrook.nl/2016/11/strangler-pattern-practice/ https://www.michielrook.nl/2016/11/strangler-pattern-practic... Probably the language that is most poised to achieve this is Zig; it would be feasible to start by wrapping the entire BEAM in a zig compilation unit; which at the very least potentially offers an easier path to maintaining the codebase across multiple platforms. Followed by hodgepodge doing bits and pieces in zig, which could be achieved via straightforward transliteration at first. The very different mindset of the rust PL lends itself to total rewrites, which I don't think will sit well in the BEAM community. On the other hand erlang has tons of strange rewrites happening over its own internal ecosystem all the time (gen_fsm -> gen_statem, pg -> pg2 -> pg), etc.

muizelaar 7y ago
Do you know of any examples of this being done with Zig? I can think of a couple with Rust: - https://gitlab.gnome.org/GNOME/librsvg https://gitlab.gnome.org/GNOME/librsvg completed a migration to Rust. - https://github.com/RazrFalcon/rustybuzz https://github.com/RazrFalcon/rustybuzz and https://github.com/immunant/rexpat https://github.com/immunant/rexpat are making decent progress.
- dnautics 7y ago
  No, because zig is still in 0.6.0, and the BDFL says "don't use this in prod yet"? Yeesh.
  - catach 7y ago
    Perhaps then, for the sake of setting those expectations, the wording "the language that may be most poised to achieve this in the future is Zig" would be preferred?
    - dnautics 7y ago
      Last I checked "poised to achieve this" implies the future. Moreover I have specific reasons to say that, namely that zig now ships with C compilation with transparent cross-compilation support so you can use it as a direct replacement for C and (I believe make), so the statement is based on current zig features whose importance I alluded to in the comment. Fwiw this is also a real problem as I am often hearing complaints about windows ABI support in elixir, anyways. Moreover, having written nifs, I have to say the c header for nifs is basically unintelligible without manually parsing the DEFINES because of windows cross-support needs. Please let me know if I'm using "poised" incorrectly.
      - catach 7y ago
        To my mind, "poised" in this context is roughly synonymous with "ready". If the official position of the project is "don't use it yet" then it's not ready yet. The future implied is the completion of the action one is ready for, not further work of preparation for that action. Your take may, of course, differ.

muizelaar 7y ago

Do you know of any examples of this being done with Zig? I can think of a couple with Rust: - https://gitlab.gnome.org/GNOME/librsvg https://gitlab.gnome.org/GNOME/librsvg completed a migration to Rust. - https://github.com/RazrFalcon/rustybuzz https://github.com/RazrFalcon/rustybuzz and https://github.com/immunant/rexpat https://github.com/immunant/rexpat are making decent progress.

dnautics 7y ago
No, because zig is still in 0.6.0, and the BDFL says "don't use this in prod yet"? Yeesh.
- catach 7y ago
  Perhaps then, for the sake of setting those expectations, the wording "the language that may be most poised to achieve this in the future is Zig" would be preferred?
  - dnautics 7y ago
    Last I checked "poised to achieve this" implies the future. Moreover I have specific reasons to say that, namely that zig now ships with C compilation with transparent cross-compilation support so you can use it as a direct replacement for C and (I believe make), so the statement is based on current zig features whose importance I alluded to in the comment. Fwiw this is also a real problem as I am often hearing complaints about windows ABI support in elixir, anyways. Moreover, having written nifs, I have to say the c header for nifs is basically unintelligible without manually parsing the DEFINES because of windows cross-support needs. Please let me know if I'm using "poised" incorrectly.
    - catach 7y ago
      To my mind, "poised" in this context is roughly synonymous with "ready". If the official position of the project is "don't use it yet" then it's not ready yet. The future implied is the completion of the action one is ready for, not further work of preparation for that action. Your take may, of course, differ.