rixtox

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.

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

But no one is claiming w3c is not running a website.

It’s unfortunate that they claimed “Matrix is a protocol not a service” while they are literally running a home server on the Matrix domain.

They should really rebrand their home server to another name, so the Matrix name is unambiguously referring to the protocol.

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.

“Stand Alone Complex”

If US and China, two nuclear powers, engaged in direct wars, drone attacks would be the least to be worried about.

Does implementing algebraic effects requires stack switching support? If so, I wonder what runtime cost we must pay when heavily using algebraic effects. Is there any empirical study on the performance of algebraic effects implementations?

They should call it Blade Runner

Another more powerful option: Intel SDE / PinPlay

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.