Hacker News Reader

> The author is a PhD student that has been using LaTeX heavily for 10 years. But what should a new student use, and why? When the only reason to choose LaTeX is old colleagues and gatekeeping publishers, I know it's a matter of time.

Sadly its more than that. Will we be able to compile a typst file made today in 10 years? I have to do that regularly with latex. Will everybody one collaborates with also use typst? Very unlikely. A new PhD student may find it beneficial to write papers with someone who only uses latex. then why bother with typst? (and I really want typst to win)

I regularly can't do that in LaTeX due to changes in packages. Yeah, the core is stable, but dependencies are still an issue in TeX land.

That's only true if you need a lot of speciality packages. For the vast majority of people using LaTeX, they only need the core packages like the basic features of hyperref, geometry, amsmath, amsthm, and in that case, they are quite stable.

I've never had a problem recompiling documents. Yeah, you might have a problem if you're using LaTeX for a fringe use but most people don't.

> Will we be able to compile a typst file made today in 10 years?

Yes! typst is actually better than LaTeX in this regard:

LaTeX: contrary to how it sells itself, it's not good at compiling old files. The TeX core is fine but the packaging story is awful. Once I found a beamer presentation about LaTeX itself, including of course some slides about the amazing backward compatibility. Well, the slides failed to compile in multiple places due to the fancy packages used by the author, which had made breaking changes between whatever they were using and my own TeX Live installation. And using an older version of TeX Live is not trivial. Another example: a few weeks ago a colleague found himself unable to compile a document that worked before the system (Linux distribution) update. It took us two hours to figure out that one of the LaTeX packages had made a change which made it incompatible with another package unless you switch the order of \usepackage. Fun!

typst: it's a single binary, statically linked. That's it! If you care about this, you can literally commit this one file (30MB or so) in your repository and it will run flawlessly in 10 years. The packaging system is very recent and still a preview, but it's already better than LaTeX since packages are imported by specific versions. And if you're worried that the typst package server will go down it's easy to mirror it locally.

> Will everybody one collaborates with also use typst? Very unlikely. A new PhD student may find it beneficial to write papers with someone who only uses latex.

That's the reason I mention. If it's the only reason left for learning LaTeX, good luck LaTeX. Very soon it will be "Will everybody one collaborates with also use LaTeX? Very unlikely".

> LaTeX: contrary to how it sells itself, it's not good at compiling old files.

yes and no, that bit me last week, some packages decided to become incompatible. but in my case 99% of old files compile fine today.

A legitimate concern given that Typst is still maturing. But I have at least one thing to say in its favour: you can lock the version of packages that you import. The only reason LaTeX documents full of \usepackages are reproducible ten years later is because packages are in maintenance mode, not because of well-thought-out future-proof design.

Typst is a single file binary. The preview packages are versioned too. If typst breaks the API in ten years, I'd still be able to download the old binary and make a PDF from scratch. I can't begin to imagine the complexity in installing multiple texlive distributions side by side.

Yes, but its more complicated. In my case I have slides with a number of include files, some have not changed since 2006 (just checked), one does not want to maintain slides with same ancient version of typst, and then possibly have many floating around.

For me, they need to promise full backwards compatibility.

That's a valid point: if you don't want a language that makes breaking changes (so you can always compile old files with the latest version), it's not the right time to use typst. It's just moving too fast now. It's currently at version 0.11. Come back when they release 1.0.

That old binary won't link with the shared libraries on your machine 10 years from now. Depends on 280 other crates. Ye gads.

"Yeah just use ancient binaries" is not a viable strategy for future-proofing.

It's a lot easier to move fast and break things when you don't care about stability.

  $ ldd bin/typst
   statically linked

You faked this. `ldd` never prints just the text `statically linked` for a statically-linked binary.

Here's the real output.

    $ ldd result/bin/typst
        linux-vdso.so.1 (0x00007ffd2c4e5000)
        libgcc_s.so.1 => /nix/store/28d6zz06v3mpwdbi72fdw64qmmq8rhfm-gcc-13.2.0-lib/lib/libgcc_s.so.1 (0x00007f4fe68b9000)
        libm.so.6 => /nix/store/7x591g0d1kydp4dci0jvksi0qbn013v3-glibc-2.38-27/lib/libm.so.6 (0x00007f4fe67d9000)
        libc.so.6 => /nix/store/7x591g0d1kydp4dci0jvksi0qbn013v3-glibc-2.38-27/lib/libc.so.6 (0x00007f4fe4619000)
        /nix/store/7x591g0d1kydp4dci0jvksi0qbn013v3-glibc-2.38-27/lib/ld-linux-x86-64.so.2 => /nix/store/7v29y7b3b38x2hpgld698fw6k5mffam8-glibc-2.38-44/lib64/ld-linux-x86-64.so.2 (0x00007f4fe68e1000)

You can't have truly statically linked binaries on glibc systems; they ditched support for that over a decade ago. On the 1% of Linux systems using Musl you can produce statically-linked binaries, but `ldd` will report `not a dynamic executable`.

You faked your console output.

It's not faked. I guess the nix recipe does things differently from the official binary. Try yourself: https://github.com/typst/typst/releases/download/v0.11.0/typ...

But it's true that when I tried ldd on a trivial static binary (compiling "int main() { return 0; }" with "gcc -static a.c") I got a different message: "not a dynamic executable". I don't know why you'd get sometimes one message sometimes the other...

Having to use magically-blessed (what you call "official") binaries is not a viable strategy either.

If you don't know how to build a statically linked rust binary yourself, then why bother posting about the downsides of dynamic linking?

And obviously you can also link statically against musl on glibc systems. It's just another library.

Come on, it's a really good strategy if you care about this (use the official binary, or make the effort of making a static binary yourself).

And even your linked binary will probably work in 10 years, these libraries are not likely to break. See for example https://superuser.com/questions/1450027/how-exactly-a-system...

I couldn't say the same thing about the LaTeX binaries:

  $ ldd /usr/bin/pdflatex
 linux-vdso.so.1 (0x00007ffe347f7000)
 libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007e699d5bf000)
 libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1 (0x00007e699d5a3000)
 libkpathsea.so.6 => /usr/lib/x86_64-linux-gnu/libkpathsea.so.6 (0x00007e699d587000)
 libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007e699ce00000)
 libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x00007e699d4a0000)
 libgcc_s.so.1 => /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007e699d47e000)
 libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007e699ca00000)
 /lib64/ld-linux-x86-64.so.2 (0x00007e699d624000)

libpng, libz, libkpathsea, libstdc++ are much more likely to break than glibc.

  $ ldd /usr/bin/lualatex
 linux-vdso.so.1 (0x00007ffe4f8d6000)
 libtexlua53.so.5 => /usr/lib/x86_64-linux-gnu/libtexlua53.so.5 (0x00007eccb87c1000)
 libzzip-0.so.13 => /usr/lib/x86_64-linux-gnu/libzzip-0.so.13 (0x00007eccb9392000)
 libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007eccb8786000)
 libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007eccb86b7000)
 libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1 (0x00007eccb9376000)
 libkpathsea.so.6 => /usr/lib/x86_64-linux-gnu/libkpathsea.so.6 (0x00007eccb8699000)
 libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x00007eccb85b2000)
 libgcc_s.so.1 => /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007eccb8592000)
 libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007eccb8200000)
 libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007eccb8458000)
 libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007eccb8138000)
 libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007eccb842f000)
 /lib64/ld-linux-x86-64.so.2 (0x00007eccb93c5000)
 libpcre.so.3 => /usr/lib/x86_64-linux-gnu/libpcre.so.3 (0x00007eccb80c2000)
 libbrotlidec.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007eccb80b4000)
 libbrotlicommon.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007eccb8091000)

no comment

PS: you could edit your previous comment and/or apologize for accusing me twice of forgery.

Yeah, this is also not a fair fight.

The "will it work in 10 years?" just swayed _immensely_ in Typst's favor.

> Then the LuaTeX devs moved their efforts to LuaMetaTeX and I found myself scratching my head.

This makes sense: They're essentially “done” with LuaTeX; it works fine and is distributed with TeX Live; it's up to others to use it. Many people are in environments (submission to journals that insist on pdfTeX etc) where they cannot use LuaTeX; the LuaTeX developers cannot change that. (It has minor differences from TeX/pdfTeX but they don't seem keen to fix it.) Meanwhile for those who are willing to use a new system, they might as well simplify (remove the backward-compatibility requirements) and make a better typesetting system more suited to the needs of ConTeXt.

In other words, users can be divided into:

- those who insist/need to use pdfTeX + LaTeX

- those who are willing to try something different, for which there's ConTeXt (with lmtx) or (further afield) Typst, etc.

can I add a third class. - those who need latex+dvips+ps2pdf

and if you ask why, 2 packages: psfrag and pstricks.

I'm just happy I can compile thirty year old documents.

> The author is a PhD student that has been using LaTeX heavily for 10 years. But what should a new student use, and why? When the only reason to choose LaTeX is old colleagues and gatekeeping publishers, I know it's a matter of time.

From what I have seen, it's Overleaf.

Do newer students know or care what flavour of Tex Overleaf uses in the background? Not as far as I have seen.

"Typst Overleaf" sounds like a fine business idea to me, if you give the user the option to export TeX (so that they can then submit it to a journal).

(If you support both LaTeX and Typst, and improve the Overleaf experience somewhat -- which is definitely possible -- I can't imagine you wouldn't steal some market share from Overleaf.)

The Typst webapp [1] seems like it is already pretty similar to Overleaf.

LaTeX output seems not to be on the roadmap [2], which I can respect. The amount of weirdness you would have to workaround to get good Typst to LaTeX translation sounds like a pain. I guess the hope is that the publishing industry starts adopting Typst...

[1] https://typst.app/ [2] https://github.com/typst/typst/issues/149

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.

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...

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?

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

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.

> 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.

Typst is exciting, but I wish their roadmap would prioritize features in common use in LaTeX like microtype rather than niche new features like style revocation.

Yeah, I'm curious if anyone with experience has comments on the typography quality of Typst, or whether that's even a focus at this point in time. There are a million document languages (DocBook, AsciiDoc, Markdown+extensions, LaTeX, etc etc) but LaTeX has the foothold it does (other than academic entrenchment) because of the output quality.

I sometimes use Typst as an intermediate renderer with Pandoc, but for my highest quality work I insist on features like protrusion. I was using LibreOffice just yesterday and actually had to check multiple times whether there was a space at the beginning of the line because the lack of protrusion support meant unsightly visual gaps.

Probably not as developed as microtype, but they have overhang, kerning and ligatures: https://typst.app/docs/reference/text/text

Microtype features are already incorporated. See this issue: https://github.com/typst/typst/issues/261#issuecomment-14886...

The only microtype feature currently supported in typst is overhang, and only for seven hardcoded punctuation characters. See the code here:

https://github.com/typst/typst/blob/10a3fbd174fc1a3f95937c91...

It's basically a kludge; there's a lot more work needed to actually implement even overhang properly.

Typst has nowhere the control and reproducibility of LuaTeX. It's core syntax is quite weak and will be a bottleneck in future. It is especially weak for structure of huge documents, and for mathematics.

LuaTeX is stupid but it still has features needed which none of the other markup languages posses.

This is quite baseless without any proof or at least example.

Many of the equations and syntax I used in my PhD work can't be written in Typst. For instance, Young Tableaus, or commutation diagrams. Or circuits generated from inline code. I am not even sure if it has been coded in a way to support such extensions.

So I would not recommend a new PhD student (actually undergrad student) to learn Typst just yet.

Could you give some examples of these equations?

The ecosystem for the kind of things you mention is expanding rapidly, have a look at these:

https://typst.app/universe/package/fletcher

https://typst.app/universe/package/quill

https://github.com/fenjalien/cirCeTZ

These are based on CeTZ: https://github.com/johannes-wolf/cetz , a kind of TikZ for typst. I don't see anything for Young Tableaux but it should be easy to do based on that.