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.

[1]: https://netflixsubs.app/docs/netflix/features/imgsub

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.

[1]: https://youtu.be/7GcrT0SBSnI

[2]: https://effect.website/

[3]: https://frontside.com/effection/

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...

[3]: https://github.com/dudykr/stc/issues/1101

Comments URL: https://news.ycombinator.com/item?id=40373553

Points: 8

# Comments: 1

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