Huh, I did not know that you can speed up builds by stripping debug info, need to try that out :)

Yeah I was very happy to find that out. I was calling latex externally before, and there was a lot of pain interacting with the filesystem and temporary files. Now it all happens in-memory :)

One thing that prevents me from letting users build their own templates is the scripting capabilities. A joker creating an endless loop could block the whole server.

I know little about servers, but can’t you run the generation in a thread with a timeout or so? Or maybe compile to wasm and let the generation run on the users machines? I also know little about wasm, but I’d have guessed it has facilities to keep runtime and load under control.

What would be nice is a “safe” mode in which no access to the file system (include and sorts) and limited runtime makes it safe to let users build their own templates.

Ah, are you by chance shelling out to the typst binary? You can actually use typst as a library, and then you’ve got full control over the files involved, so it’s “safe” in that respect.

That might indeed be the case, I did not look very closely, but mlua has gotten quite some coverage (and I do like lua quite a bit), so I wanted it mentioned :)

Seems to be missing mlua at least: https://github.com/mlua-rs/mlua

transitive performance benefits

I would have assumed the benchmark suite accounts for that, otherwise the results aren’t quite as meaningfull really. Which ties back you your 2nd senctence: I certainly trust the rust team more than myself on these things :)

only affect very select use cases

I did not read the whole conversation, but sorting seems a very common usecase (not mine, but seems to me a lot of people sort data), so this seems quite a broad improvement to me.

that is already perceived as a pain point

Note though, as is mentioned in the issue, that the survey showed people still prioritize runtime performance over compilation performance in general, so this tradeoff seems warranted.

the total regression is still minor

It’s not unheard of that regressions can be unmade later on, so here’s hoping :)

The post mentioned that the introduction of these new algorithms brings compile-time improvements too, so how should I see this?

I assume you mean the first post of the PR? I’d assume it’s simply outdated (or might not have been true to begin with). See https://github.com/rust-lang/rust/pull/124032#issuecomment-2181789935 for the perf run with this PR, it’s showing quite a bit of regression.

Alas, on the whole the compiler slowed down as a result of this. I think it’s a worthy tradeoff though.

No sarcasm, just an honest suggestion :)

From the Fine Readme:

This project allows you to create games for the Playdate handheld gaming system in Rust lang.

You really should preface every announcement with something like this :)

It’s surprisingly simple: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f176852c61dcf0c3382f0ac97c26de03 As a side node, asking for a value, and then immediately calling to_string on it seems kinda hiding the allocation. I’d suggest let the user call to_string on it themselves.

(e) Changed it a bit to account for passing None as the third argument.

It’s absolutely awesome. For my use case, it already surpasses latex, but I’m pretty sure that for other usecases there will be a point where latex offers more, at least due to ecosystem support. I for sure made the switch (wrote some personal docs in typst as well), and I’d suggest anybody at least looks into switching, it’s so much better :)

From a dev perspective, it’s also great that this is useable as a lib, instead of having to muck with an external binary (or rather full external latex installation).

I have an app that ultimately renders pdfs via typst. I’m starting to write tests for the output, exporting the documents to png instead and then applying something like https://github.com/kornelski/dssim or so.

(If anyone has experience with that, I’d take any hint I get ;))

This parting shot sounds pretty dire

a bug in safe code can easily cause unsound behavior in your unsafe code if you’re not careful.

That’s definitely not how it should be. Fortunately, I think I disagree with that, since miri points to the “real” buggy code:

unsafe { inner.as_ref() }

As opposed to the article, I’d argue this code is not correct, since it did not account for alignment, which it must (I mean, by standard use of the word unsound this is unsound, since it can be called from safe code introducing UB). Or am I wrong? Is the fundamental value proposition of rust moot?

Note that this is not only a cli and a (closed source) web editor, but also a library. So it’s possible to embed a full typesetting library in your project, which is awesome. It’s probably not on par with TeX yet, but you can already do an awful lot with it. Scripting it is really much, much easier than, say, LaTeX.

I’ve written nvim-rs, an async library for interfacing with neovim via RPC.

As a sidejob, I’m writing and selling a program to create school reports.

A reference IS Copy, by the simple fact that it is a primitive value on the stack.

This seems a bit misleading, noting that unique/mutable references aren’t Copy. Shared references are Copy because it’s sound to have that, and it’s a huge QOL improvement over the alternative.

In fact, isn’t this not true just by the fact that references work for Strings and Strings size can’t be known at compile time?

I don’t understand this. Shared references to String are Copy, too. This doesn’t have to do anything with sizes. Rather, it’s implemented in the compiler, because it’s sound to have it and a huge QoL improvement over the alternative… just the same reason why e.g. usize is Copy, really.

is it dereferenced specifically because is Boxed on the heap?

No, it’s not really related to the heap. Box implements DerefMut, which is in-depth explained here.

I don’t know, I was just surprised by the short timeframe.