[4bpp]

Typst does look very nice based on the brief look I took at it, but besides the questions of adoption and entrenchment that have been raised in parallel comments, the choice of Rust as the implementation language is also concerning to me. I think that Rust and the community that surrounds it are associated with a newer, simultaneously somewhat trend-chasing and decidedly paternalistic culture of software engineering that does not mesh well with the longtermist demands of science and scientific publishing. Concretely,

* Where LaTeX evidently favours doing whatever it takes to achieve a desired result (exhibit 1 being the article we are discussing), Rust itself and the culture that begot it are clearly on the side of decreeing a Right Way from high above and treating the possibility of deviating from it as a bug. In the light of the discussion in Footnote 7, I could for example imagine a Rust-minded typesetting system designer decreeing that unnumbered "displaystyle" math will not be supported.

* Cultural acceptance of mandatory automatic updates means that backwards compatibility may actually be considered an anti-goal.

* Cultural acceptance of ideology/politics in software engineering brings the danger of invasive conditions. What if, by way of an aggressively interpreted CoC, {receiving funding from military/police-aligned agencies, working with Russian collaborators, working with Iranian collaborators} becomes grounds for being excluded from issue discussions or package repositories? (I do take note that Typst does not currently show signs of doing anything like this, but the tone of the wider Rust community does have to be taken into account.)

Of course all these concerns are speculative, but scientific papers can be a nightmare scenario of maintenance (half a year's worth of work, one-digit number of people in the world qualified to write, two-digit number of people who will bother to read). Under those constraints, some measure of paranoia feels appropriate.

[returningfory2]

I think the idea in this comment -- that users of languages inherit all of the perceived negatives of the community developing the language -- is just wrong. (I say "perceived" because some of the claims in this post are simply incorrect, such as the claim the Rust language developers think "backwards compatibility may actually be considered an anti-goal".)

For example, over the last couple of years I've been re-implementing some of Knuth's typesetting work in Rust. Contrary to your claim, my project is obsessed with backwards compatibility and making sure the output is identical to Knuth's. Last weekend I even discovered a ~30-year old bug in one of Knuth's programs [1] as part of an extensive fuzzing effort. (Of course, I re-implemented Knuth's bug in my Rust code [2].)

[1] https://tug.org/pipermail/tex-k/2024-March/004031.html [2] https://github.com/jamespfennell/texcraft/commit/e89b7461780...

[4bpp]

I didn't claim anything about your project at all. A claim about a perceived tendency does not amount to asserting an absolute rule.

That being said, though, for any major project, it's hard to overstate the long-term effect of community pressure. I maintain a moderately-sized project using Gtk for its GUI, and am personally deeply opposed to the RHEL blob (which Gtk/Gnome belongs to)'s culture of "windowsification"/switching away from simple composable interfaces to overengineered proprietary ones. Yet, recently contributors successfully browbeat me into switching the config system from a legible textual one to gsettings (basically Gtk's implementation of the Win32 registry, with all this implies) - it was just too much pressure over what seemed like an ultimately minor thing, and I didn't want to alienate people who I depend on for a lot of work that being well-embedded in the wider community conveys competitive advantage in, such as getting packages into distro repositories. I'm left wondering what principles/preferences I would not compromise on, if the resident Gnome wizards were to all disagree. If your project grew so large that you couldn't do without the help of random Rust community members, and the majority of them got very insistent that you should not reproduce Knuth's idiosyncrasies, can you say with confidence that you would resist?

[returningfory2]

Thank you for your very thoughtful response. This has given me food for thought.

[Ar-Curunir]

Rust has enabled much better science at least in my field of Cryptography than whatever nonsense people wrote in C/C++ before. I have the feeling the same is true for other areas like Systems.

And it's also laughable to claim that any research paper written in LaTeX is "maintained". It's a one-off job. Nobody is reusing their previous papers as submodules in new ones.

[4bpp]

> better code

I'm not disputing that Rust has its advantages; the issues I talk above are mostly problems with the community than the language per se. (On the other hand, we are yet to see how the "import antigravity" attitude will play out once the bits had enough time to rot - it does matter whether your ten-liner test program is only using libc because it was too much work to get a nice pretty-printing library, or whether you imported a pretty-printing library because you could, resulting in 2GB of transitive dependencies of which some have 10 users and 0 active maintainers. And then there's the supply chain security issues)

> maintenance

Surely depends on how fast-moving your field is - I have reused diagram code from late-'90s category theory papers, and recompiled more from source just to get the benefits of the pdflatex pipeline over the latex-dvips-ps2pdf one (selectable text, proper font rendering, hyperref). Repositories like arXiv also may need the ability to recompile old submissions automatically.