the-wumpus

It's not great, but in this very thread there's a person from the conformance team that says that it shouldn't sway your choice too much.

https://htmlpreview.github.io/?https://github.com/SimonSchic...

Zuban continues to have "not great" diagnostics like the rest of the python type checkers, where ty has "rust inspired" diagnostics that are extremely helpful. It's a shame to hear that the current state is considered "nearly finished".

The existing type checkers are slow. That's their reasoning for creating it. The type checking world in python is now reasonably well specified (and the type checkers are beginning to work more similarly), so I would expect (once ty is out of beta) you could replace your type checker with ty and just see a 20x speedup in CI and much much faster IDE diagnostics.

If it was going from 3s -> 1s then you'd probably be right, but on my work codebase pyright (which is the faster one!) takes 15 seconds (ty takes 0.8s) and takes a bit for errors to appear in the IDE. This is now fast enough for us (mypy was taking >30s, which was not fast enough), but if the project grew another order of magnitude (which it might) then it would probably be too slow.

It's the same reason ruff is great, linting the codebase is so so fast.

I disagree with it being outside the scope of typst. Typst makes designing a template entirely feasible, I've tried and succeeded.

pprof doesn't do an amazing job of explaining how to use it with perf (which you'd need to use for a rust project like OP), so:

First install perf, graphviz, perf_data_converter and ofc pprof, then generate the data with `perf record [command]`, and display it with `pprof -http=: perf.data`.

They have some incentive to drive users to subscribe, but they have other forms of income, and I think if they ever implemented even a single feature of actual rendering that was closed source their community would riot and we'd get a community managed fork (probably by the guy who does the language server...).

The only way they can continue to gain traction is if they never ever in any way lock people to the web app. Documents must be portable, it's part of why someone would want typst anyways.

I do not see a future where this happens, and if it does it will be because the typst org has changed hands and is also no longer particularly relevant to the future of typst the language.

I disagree. The web app editor is closed source, but much of what it provides is open source so editing is a similar (and imo better) experience locally. The typst compiler and LSP and everything you need to use it is open source.

Imo the situation is more like if overleaf were also the people who made the LaTeX project originally.

I think the only possible issue with the typst org dying (assuming after the full 1.0 version so it's mostly maintenance) is that packages are automatically downloaded from the typst site, but an open repo can trivially be made considering that the set of packages used is just from a open source git repo and the closed source site just hosts tar.gz files of the folders in the repo. Not a big deal I think.

I understand why people like using LLMs for coding, saves them having to think, but it is deeply frustrating to see it being such a crutch that some people cannot use new tools without it.

I suppose the issue is not new, many people didn't want to use new lanuages before because they couldn't copy snippets from the internet, but it was frustrating then too.

To be fair $x^2=1$ literally works in typst.