HN user

rixtox

61 karma
Posts2
Comments39
View on HN

I found octopus megamerge hard to collaborate - my colleagues don't use JJ so they may introduce changes that would cause conflitcts to my megamerge. When you have a conflict on a change that has more than 2 parents, the conflict resolution becomes unmanageable very quickly. No merge tool can handle more than 3-way merge, so you have to do that manually.

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.

Why Objective-C 5 months ago

The most difficult part of Objective-C is its ARC rules, and mixing ARC and non-ARC code in the same project.

If you feel that TypeScript, or hell even JavaScript, is becoming more alike C#, it's actually deliberately done by Microsoft in benefiting their ecosystem. In this interview they mentioned they had internal demands to convert/transpile C# into JavaScript or TypeScript. So by making these target languages more like C#, it directly benefits their need. But I don't think this should be the driving force in designing ECMAScript. When they are pushing a language feature, they have an unspoken internal goal, and every choice they make is to make JS/TS look more like C#, and they are more likely to dismiss proposals that preventing them from deliverying that goal. There's likely a bit of conflict of interest there.

Netflix implements "imgsub"[1] - it actually delivers a zipped archive of transparent images to the player. So technically they can pre-render positioned typesetted subtitles on server and render them as images overlay, as long as there's no animated text effects.

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 remember arguing with Ron on the TC39 disposable proposal that I think Go's `defer` is a better pattern than C#'s `using`, and he tried to convince me the otherwise.

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.

This is also a result of the detachment of TC39 and the developer community. Just how many JS developers are participating TC39? I can recall multiple TC39 proposals that didn't even consult opinions from authors of notable open-source stakeholder libraries, and went straight into stage 3.

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.

I think React would get better developer experience and performance if they adopt language coroutine feature to implement direct style algebraic effect. In fact the React Fiber system is already an implementation of algebraic effect.[1] However, it’s “suspending” a routine by raising an exception. Thus unwinding all the call stack, therefore, it needs to re-run that same routine on resume. This is the core reason why they have a performance issue and why they created the compiler to cache values on reruns.

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/

I wish the TypeScript team can actually make a good and fast compiler with type inference support. There are so many opportunities for minimization, optimization, conditional builds, instrumentation, and so on if we can utilize the type info from the TypeScript compiler. Unfortunately the TypeScript team never commit to requests like these, and only commit to idiomatic JavaScript transpilation.[1][2]

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

You should do some measurement before calling it an improvement. If you read the ECMAScript standard[1] or this blog post from V8[2] about the inner workings of the `await` keyword, you would know even if you `await` a non-Promise value, it would still create a new Promise and put the suspended routine onto the microtask queue. So the change you made won't make a difference.

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

Most third party keyboards cannot emulate the Globe key. Apple would only recognize it if the USB PID/VID matches real Apple USB keyboards, which third party keyboards are not allowed to use.

I really wish a similar tool for exploring binary lifting to different IRs. Like Ghidra p-code with sleigh, LLVM Machine IR, Qemu TCG etc

There's a conversation I had with Ron Buckton, the proposal champion, mainly on this specific issue. [1]

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

What we need is actually the Matrix protocol for app distribution. That is, a decentralized yet federated platform replacement for App Store. So the longevity and transparency of the platform is ensured by the distributed property.

Although the original title is a little clickbait and not exactly correct, this article written by Ania M. Piotrowska, one of Nym’s main researcher, explained in details what are the privacy properties you need against state level mass surveillance.

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.