Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rewriting LaTeX in Pure Rust

github.com

Post reply on HN
Print view View original

81–90 of 148 posts

Re: Rewriting LaTeX in Pure Rust

#81

Post by Xylakant »

MaxBarraclough wrote: post #67
jfk13 wrote: post #48

Personally, I think this approach -- which as far as the engine is concerned looks like a largely-automated "translation" of xetex from C/C++ to Rust -- is misguided. The xetex code is a byzantine tangle of disparate pieces that evolved over the course of a number of years and several changes of direction; it originally started as a personal tool to address one individual's use case for a "Unicode-capable TeX", and g…

> littered with unsafe blocks Good points. It's unfortunate that headlines rarely distinguish safe Rust from unsafe, when so much of the advantage of Rust depends on it. You may even get a hostile response for asking about it ( https://news.ycombinator.com/item?id=24141493 )

I think you're getting your hostile answers for implying that unsafe rust is equivalent to C. It's most definitely not. Using unsafe grants you certain powers, but it does not disable all of rusts features - for example the borrow checker is not turned off by unsafe.

See https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#unsa...

Re: Rewriting LaTeX in Pure Rust

#82

Post by Upvoter33 »

sega_sai wrote: post #62

I'm not sure rewriting Latex in XYZ is a good idea. The whole thing is a mess and a pain to use (and I use it multiple times a week). Sure the documents often look good, but when they don't or there is an error, fixing it just becomes a nightmare. I wish somebody would design a modern typesetting system that would accept say latex equations but without 50 years of cruft and levels of macroses upon macroses.

People have tried. I knew someone who did a term paper on typesetting systems - wish I could find it - and the conclusion was basically "TeX sucks in a lot of ways, but the attempted replacements have always been worse." Knuth actually got a lot of things right and hence TeX's staying power.

Re: Rewriting LaTeX in Pure Rust

#83

Post by marktangotango »

This “x implemented in y” is a curious thing we are seeing with growing frequency nowadays (imo). On the one hand, good for these folks, to be rewriting something old in a new way (be it language, library, or framework). On the other hand, could this be an indicator that we’ve reached a certain level where it is easier to rehash the ideas of the past than create new work or invent new ideas or applications? Maybe someone with a more classical education can comment on how this manifests in the arts?

Re: Rewriting LaTeX in Pure Rust

#84

Post by grey-area »

cryptos wrote: post #52
grey-area wrote: post #50

Earlier quoted context omitted.

The advantage of this approach (as opposed to a rewrite), is that you reproduce all the bugs and misfeatures that people in the wild depend on. You can then add a test suite and start refactoring and gradually move to a codebase you're happy with, while breaking few or no users on the way. Another approach is to split it into blocks and replace parts of the system, but whether that is feasible depends on the software…

But the advantage of avoiding C specific bugs is shallow, because the Rust code contains lots of unsafe blocks. Bugfixes made to the original source are not automatically ported to the Rust code base. From my point of view the chosen porting "strategy" doesn't make much sense. It is more of a toy project to see what's possible. What would really make sense would be starting with an extensive test suite and trying to…

Your suggestion would be the start of a clean-room or fresh rewrite - so option 3 above, but those are often surprisingly long and unrewarding endeavours, particularly in old software like this with lots of users used to its quirks and bugs and who disagree about what the spec should be.

Automated translation is obviously not an end goal in itself and doesn't improve code quality, but it could be the start of a successful rewrite as it does at least let them replicate exactly what the old program does, which is very important for end users.

A good example of this strategy being used successfully is the use of the tool c2go to convert the Go runtime and compiler from C to go. That involved quite a specific tool tailored to the codebase in question, and a lot of manual cleanup afterwards.

https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdw...

Re: Rewriting LaTeX in Pure Rust

#85

Post by geodel »

marktangotango wrote: post #83

This “x implemented in y” is a curious thing we are seeing with growing frequency nowadays (imo). On the one hand, good for these folks, to be rewriting something old in a new way (be it language, library, or framework). On the other hand, could this be an indicator that we’ve reached a certain level where it is easier to rehash the ideas of the past than create new work or invent new ideas or applications? Maybe som…

Yeah, roughly something like doing cover versions of older songs but with modern, state of the art music arrangement. From what I know people do seem to love that.

Re: Rewriting LaTeX in Pure Rust

#86

Post by earthscienceman »

Veen wrote: post #64
sega_sai wrote: post #62

I'm not sure rewriting Latex in XYZ is a good idea. The whole thing is a mess and a pain to use (and I use it multiple times a week). Sure the documents often look good, but when they don't or there is an error, fixing it just becomes a nightmare. I wish somebody would design a modern typesetting system that would accept say latex equations but without 50 years of cruft and levels of macroses upon macroses.

Matthew Butterick is working on the Quad document processor, which is intended to "modernize the good ideas in LaTeX," but I'm unsure what its equation typesetting is like. It's written in Racket. https://docs.racket-lang.org/quad/

The final note in the documentation on this software is a quote very fitting of a project re-thinking digital typesetting:

“A way of doing something original is by trying something so painstaking that nobody else has ever bothered with it.” — Brian Eno

Re: Rewriting LaTeX in Pure Rust

#87

Post by leephillips »

alexpovel wrote: post #68
chriszhang wrote: post #55

Earlier quoted context omitted.

> Also, `lualatex` does not have some of the limitations of `xelatex` (memory limitations, `contours` package, ...) Are there some more details of the memory limitations you can share with us?

LuaLaTeX allocates memory as-needed, see section 3.4.1 in the manual [0] (and comments/answers in this thread [1]). Base TeX has an arbitrary, by modern standards low memory limit, leading to a whole class of errors plaguing unsuspecting users [2], and spawning entire extensions to deal with these limitations [3]. This is simply an artefact of times past and has no technical relevance nowadays. LuaTeX allows dynamic…

I’ve been a luatex advocate in the past¹, but I use xetex instead, unless I need the Lua integration. The memory handling is the reason. I find that for documents with a lot of fonts, luatex eats all the memory available and then crashes, taking a huge amount of time to do so, whereas xetex just breezes through the same document.

[1]https://lwn.net/Articles/731581/

Re: Rewriting LaTeX in Pure Rust

#88

Post by smichel17 »

shp0ngle wrote: post #25

I wonder Does this still depend, even indirectly, at the WEB files written by Knuth? It has the strange license that says "Copying of this file is authorized only if (1) you are D. E. Knuth, or if % (2) you make absolutely no changes to your copy." http://mirror.las.iastate.edu/tex-archive/systems/knuth/dist...

…Those version numbers… I love it!

    % Version 0 was released in September 1982 after it passed a variety of tests.
    % Version 1 was released in November 1983 after thorough testing.
    % Version 1.1 fixed ``disappearing font identifiers'' et alia (July 1984).
    % Version 1.2 allowed `0' in response to an error, et alia (October 1984).
    % Version 1.3 made memory allocation more flexible and local (November 1984).
    % Version 1.4 fixed accents right after line breaks, et alia (April 1985).
    % Version 1.5 fixed \the\toks after other expansion in \edefs (August 1985).
    % Version 2.0 (almost identical to 1.5) corresponds to "Volume B" (April 1986).
    % Version 2.1 corrected anomalies in discretionary breaks (January 1987).
    % Version 2.2 corrected "(Please type...)" with null \endlinechar (April 1987).
    % Version 2.3 avoided incomplete page in premature termination (August 1987).
    % Version 2.4 fixed \noaligned rules in indented displays (August 1987).
    % Version 2.5 saved cur_order when expanding tokens (September 1987).
    % Version 2.6 added 10sp slop when shipping leaders (November 1987).
    % Version 2.7 improved rounding of negative-width characters (November 1987).
    % Version 2.8 fixed weird bug if no \patterns are used (December 1987).
    % Version 2.9 made \csname\endcsname's "relax" local (December 1987).
    % Version 2.91 fixed \outer\def\a0{}\a\a bug (April 1988).
    % Version 2.92 fixed \patterns, also file names with complex macros (May 1988).
    % Version 2.93 fixed negative halving in allocator when mem_min

Re: Rewriting LaTeX in Pure Rust

#90

Post by selfhoster11 »

mkl wrote: post #61
selfhoster11 wrote: post #57

Earlier quoted context omitted.

That means spending time to figure out what you don't need. It's far better to just spend those extra 5 gigs than waste time on this.

Your time must be pretty valuable! It only takes a minute or two, as it's pretty clear which of the ~30 things to deselect.

Unless you deselect too many, in which case you have to go back and try again until you have all the packages you used. It's not much time, but it counts to me.
Post reply on HN