4 ms·
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/G
by muizelaar 6y 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 6y agoNo, because zig is still in 0.6.0, and the BDFL says "don't use this in prod yet"? Yeesh.
- catach 6y agoPerhaps 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 6y agoLast 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 6y agoTo 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.