It also claims reasonable error messages but I only ran it on error-free files, so I cannot tell.
One small downside is that in my direct comparison with lualatex it was always marginally slower.
Another one is that it is not a rewrite but still based on the old TeX code.
I think tectonic is a great project but generally speaking I find it quite disappointing that we do not have 100% compatible LaTeX with a modern codebase. And that is not even because the old code is bad - not at all. It's just that a pure Rust or Java implementation would make it so much easier to integrate into other projects. An audited TeX core we could run on untrusted input would be another benefit.
Which brings me to my last point: When researching tectonic I found a fork that attempted a pure Rust port and it nearly worked with examples. There is hope...*
This is the contrary of the "modern" philosophy that says that we need to constantly modify, update or rewrite a software in "modern" languages even if it's a huge effort and risks introducing bugs that were not present in the original version.
Well, at least if we want to rewrite it let's just have to wait 10 years, then we can fed all the codebase to ChatGPT and ask for a new fancy Rust version!
Regarding of integration, TeX follows the (to me still relevant) UNIX philosophy that a software can be called by another software and the input/output communicates in a pipe. Nowadays we have even containers that let us distribute the software as a single unit so we don't have to worry about installing multiple files on a system. Not a big deal, in the end.
1. Most people aren't compiling with tex->dvips->ps2pdf anymore, most people with basic requirements compile with pdftex for more robust hyperlink and navigation pane, etc. features
2. People who want Unicode support and support for modern font files are using xetex or luatex
3. What has been proposed isn't a new tex compiler but more like a package manager for 3rd-party tex packages, using the already established xetex compiler to compile. Whereas historically you would download the whole distribution (or a predefined subset thereof) onto your system versioned by year (e.g. TexLive 2020) eating up GiBs of space, this allows you to download just what you need for your document.
not tex based, but uses CM fonts. I really think that trying to update the programming parts of TeX is necessary. sadly I'm struggling with fonts in svg figures.
but to suddenly see applying effort in this area and getting real traction is treat. so many thanks for the luminaries that put up the last one, but maybe its time for some rework after 40 years.
That would be a huge effort. Your time would be better spent designing and creating a new typesetting system.
Also the way to trust code is isolation rather than verification, even rust has unsafe.
curl --proto '=https' --tlsv1.2 -fsSL https://drop-sh.fullyjustified.net | shWhy/how is this any different? Anyone that wants to inspect the shell script can amend that line to first save and view the script. Are you thinking it’s never appropriate to trust such a script implicitly? If that’s the case, I’d love to hear about your workflow for checking the packages you install (e.g. debs can run arbitrary post install scripts, and do you know that a malicious actor with signing keys didn’t taint the binaries therein?), how you inspect all JavaScript for sandbox escaping exploits before viewing anything on the web, how you’ve ensured your hardware itself isn’t backdoored, etc.
The complaints of piping directly into shell from an HTTPS server strikes me as nothing more than a “no real technologists does $THING!” sort of elitism, though I’m open to being shown otherwise. A non-answer would be to propose that one first fetch a package signing key and install from your package manager of choice — if the script we’re complaining about can’t be trusted, there’s no reason to trust that the key file is any better with it being hosted in exactly the same way… unless you’re going to propose that you use something along the lines of web-of-trust to inspire further confidence that the signing key is authentic; at that point, though, your problem is with how 99.9% of third-party software packages (with respect to your distro of choice) are distributed - every PPA I’ve ever seen (docker, mongodb, whatever) at best tells you to fetch a key from some HTTPS server, and that’s all. It would then strike me as suspect to single out curl|bash (while additionally implying something about Rust users).
Anyone that wants to inspect the shell script can amend that line
to first save and view the script.
And it's not "self-contained" either if it downloads packages from the Internet.