rixtox
Eventually I settled on a tree-like megamerge that's more practical: merge 2 branches at a time and merge the merged branch with the next branch. This way I only need to handle 2-way conflicts at a time which is more manageable.
Also you have to be very careful to decide the order when you (and your colleagues) are going to land the branches, or if you expect any new features other people are working on that's going to conflict with your branches. When using megamerger workflow, most of the problems come from coordinating with other colleagues.
They should really rebrand their home server to another name, so the Matrix name is unambiguously referring to the protocol.
In general, streaming services have to ensure maximum compatibility when playing their contents on all kinds of devices - high end and low end. For which on low end device it could be very resource constraining to render typesetted subtitles. There are other platforms where all video playback have to be managed by the platform system frameworks with limited format support, and streaming services can't do much about it.
The priority of streaming service is extending their market reach, and I think Crunchyroll itself is facing the same challenge of market reaching.
I think the right solution is trying to get typesetted subtitles, and the end-to-end workflow - creation, packaging, delivery, rendering with adaptation (device capabilities, user preferences, localizations etc) all standardized. A more efficient workflow is needed, so a single source of subtitle is able to generate a set of renditions suitable for different player render capabilities. Chrunchyroll should actively participate in these standard bodies and push for adaption for more features and support in the streaming industry.
I was surprised to see they choose Go instead of C# for the TypeScript compiler port. Microsoft has been trying to make ECMAScript look more similar to C#, and their Windows Universal SDK has made a lot of efforts to provide a seamless transition for developers to port their code between C# and TypeScript. And yet they still think porting TypeScript compiler to Go is easier to do than porting it to C#.
Despite my different tech view with Ron, I appreciate and respect the great work he has done to TypeScript & ECMAScript. And I wish him the best with his next adventure.
And btw, the TypeScript tooling scene is far from being able to get standardized. TypeScript is basically a Microsoft thing, and we don't see a single non-official TypeScript tool can do type-checking. And there's no plan to port the official tools to a faster language like Rust. And the tsc is not designed for doing tranditional compiler optimizations. The TypeScript team made it clear that the goal of tsc is to only produce idiomatic JavaScript.
JavaScript has language level coroutine features like async/await or yield/yield* and we have seen libraries using these features to implement direct style algebraic effect. For example Effect[2] and Effection[3]. You don’t need to memoize things if the language runtime can suspend and resume your functions instead of throwing exceptions and rerun them.
And because TypeScript is so complex and development is so heavy, third party attempts on making a type checker have never succeeded.[3]
I'm curious how far React Compiler can go without the access to TypeScript type info, and if they would invest in compiler tooling for TypeScript in the future. But considering Meta has Flow as their in-house alternative to TypeScript, they might not have the incentive in investing in the TypeScript ecosystem.
[1]: https://github.com/microsoft/TypeScript/issues/8#issuecommen...
[2]: https://github.com/microsoft/TypeScript/issues/661#issuecomm...
Besides, there is a JavaScript language feature that can give you finer control on routine suspension and resumption, decoupled from any of the microtask or macrotask queue. It's called the generator function. There are some good coroutine libraries based on generator functions, e.g. co.js[3] and redux-saga[4]. You can easily make something similar that can resume the suspended routine according to your scheduling policy that prioritize main thread rendering.
[1]: https://tc39.es/ecma262/#sec-promise-executor [2]: https://v8.dev/blog/fast-async#await-under-the-hood [3]: https://github.com/tj/co [4]: https://redux-saga.js.org
Short answer: Yes, Disposable can leak if you forget "using" it. And it will leak if the Disposable is not guarded by advanced GC mechanisms like the FinalizationRegistry.
Unlike C# where it's relatively easier to utilize its GC to dispose undisposed resources [2], properly utilizing FinalizationRegistry to do the same thing in JavaScript is not that simple. In response to our conversation, Ron is proposing adding the use of FinalizationRegistry as a best practice note [3], but only for native handles. It's mainly meant for JS engine developers.
Most JS developers wrapping anything inside a Disposable would not go through the complexity of integrating with FinalizationRegistry, thus cannot gain the same level of memory-safety, and will leak if not "using" it.
IMO this design will cause a lot of problems, misuses and abuses. But making JS to look more like C# is on Microsoft's agenda so they are probably not going to change anything.
[1]: https://github.com/tc39/proposal-explicit-resource-managemen...
[2]: https://stackoverflow.com/a/538238/1481095
[3]: https://github.com/tc39/proposal-explicit-resource-managemen...
[1] https://hub.docker.com/r/curve25519xsalsa20poly1305/wireguar...
[2] https://hub.docker.com/r/curve25519xsalsa20poly1305/openvpn/
The importance of this article is to see a privacy project introspectively admitting its current limitation. In Nym’s case, it still doesn’t have hidden service, sender anonymity and receiver anonymity. This is the level of transparency we want to see from any privacy project.
Having flaws or limitations are okay, but not communicating them with users while advertising itself as a privacy project is just dishonest. I hope to see more articles like this from other privacy projects.
Nym explained its ambition to achieve much stronger privacy properties under much stronger threat model. Until then, they can truly claim to protect privacy against state surveillance.