I wish it had support for a system similar to webrtc's offer and answer SDP messages.
From what I see, relay servers are doing a job that is equivalent to Stun + Turn + SignalingServer in WebRTC.
This is great for simplicity, but having Stun Turn and Signaling live in the same server would make it harder to secure.
For example, since in webrtc signaling is up to the user, it is most common to have signaling implemented as a web server, this allows you to have it behind cloudflare with the signaling server ip never exposed to the internet. If you are not interested in supporting turn, there is plenty of public Stun servers that can be used and Stun itself is a really cheap server to run.
For iroh, it seems if I wanted to self host relay servers I'd be forced to expose their IP to the web which would make them really expensive to run if one wanted to make them DDoS proof.
> I would be personally a little disappointed if Typst replaced LaTeX, but until that happens, I definitely hope that it continues to do well.
I'm curious about why you'd be disappointed. Is it because you think typst is an irremediably inferior technology to you or is it because you are invested in LaTex?
I do not mean to ask this in accusatory way. I'm not very well informed about typst or tex (I've only used typst once and I thought it was easy and nice).
I'm just curious about what is worse about typst that would make someone disappointed if that was the reason why you would be.
It's mostly that I'm quite personally invested in TeX, far more than most people are. I work on it nearly every day, and I'm even hosting an international TeX conference about a month from now [0].
I do have a few minor concerns about Typst, mainly that its parsing/compiling strategy allows less introspection and extensibility than TeX does (but this is necessary for its fast compile times), and the fact that it's backed by a for-profit company seems less robust than TeX's 50-year history of volunteer maintainership. And of course Typst is still missing quite a few features, but if it's successful I can't imagine that this will be an issue.
Also, I personally mostly use ConTeXt [1], which compiles much faster than LaTeX and has a very uniform syntax, so switching to Typst wouldn't have as many benefits compared to if I were switching from LaTeX.
So if Typst were to take over, I'd mainly be disappointed that my very deep knowledge of TeX would be no longer relevant. But I also wouldn't be surprised if Typst ultimately revitalized TeX, since it might motivate us to improve TeX even more, and Typst might be a good entrypoint for users interested in plain text typesetting (who might then switch to TeX if they find Typst too limiting).
Excuse me for going meta, but your series of comments here have been extraordinarily informative, wise, and a pleasure to read. Thank you for taking the time (and for your work on TeX).
They differ in a similar way to how React differs from SolidJS.
In react when state changes the component functions that depended on that state are rerun to compute what the component should now look like. Then react diffs the new output with the previous to touch only the parts that changed in the DOM.
In solidjs the component function runs only once (when the component is instantiated), when state changes signals will trigger and cause the specific parts of the DOM that depended on them to change. This is generally more efficient.
Too bad it will only be available as a Pro feature. I’m not against supporting hard work by any means but framing it as an alternative to free options set me up for a bit of disappointment. But I agree with everything else you said that this seems very impressive.
I think I agree that it's akin to organized crime, it's a case of "the goal justifies the means".
You see the goal of forcing union usage as a noble thing so you agree with these means. If the goal was one that you don't see as noble you'd definitely agree that it's very organized crime like.
No, performance and power consumption should go hand in hand in this case. If you are strongly IO bound, paying for the synchronization is not really going to matter much I believe.
There are cases where you can be CPU bound and using the share nothing model would work out to your advantage. There's also the case where you only have one cpu core anyway (for example if you want to get all the juice out of a cheap single core VPS)
I've found that practically I'm more likely to simply use Box, Vec, and just regular data on the stack rather than Rc and RefCell when I esque Arc and Mutex by using a single context. The data modeling is different enough that you generally don't have to share multiple references to the same data in the first place. That's where the real efficiencies come to play.
