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".
Have you tried `--pretty`? That is more of a Rust style. Most type checker report the short version, but have longer versions of the issues. IMO that's a good choice, but opinions might differ.
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.
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`.
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.
They have a deep incentive to drive users to subscribe, and that's directly at odds with keeping all of the document rendering open source. It makes a lot of sense for them to provide document features that are only available to subscribers.
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.
Is there really a community of volunteer contributors that could fork it if that happened? Typically with a corporate-backed project like this, the corporate development tends to crowd out the formation of a volunteer community of contributors that would be able to take over development.
All the typesetting extensions and such are a community effort. There are so many specific use cases that can only be/will be done by very specialized academics that a non-networked product would die on the vine.
What you suggest seems plausible, but there is a very good counter example. Overleaf is also managing well by relying on the open-source LaTEX. What drives people to subscribe is not the typesetting itself, but the ecosystem around it (collaborative editing, version management, easy sharing, etc.). You can make money with those and still have the rendering free/open-source. I believe a similar thing is/will be true for Typst as well.
That is a bad counterexample. There is a world of difference between the main devs offering a paid service and some unaffiliated company offering services.
In principle, having a reliable source of funding for typst is great. However, as a journal this would make me hesitant: what if down the road some essential features become subscription-only?
There is quite a clear distinction/border between an Input-Output rendering kind of program sitting beneath everything, and a web service providing stuff like collaborative editing, free hosting etc on top.
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.
You’re going to be frustrated a long time into the future I would guess.
I’ve been coding since before the camel book was published: at that time it was basically ask Larry Wall on Usenet or a local bearded guru if you weren’t in a university setting and wanted to learn to code.
I can hand craft code in many a language; I can also do fine wooden joinery. When a project has value to me in the completion and hours to completion is my metric then a cnc machine or an llm is a great tool, and allows me to make things that aren’t “worth” hand coding.
When I want to work on a technical skill or just get in the flow I code by hand or use my wood tools. Upshot: different strokes for different folks.
https://htmlpreview.github.io/?https://github.com/SimonSchic...