Performance and telemetry analysis of Trae IDE, ByteDance's VSCode fork

I don't believe the behavior that is analyzed here was done in good faith, it is in fact a direct attack on things that I strongly believe in. Striving for good faith argument is only effective when both sides agree that they gain mutual benefits through agreement, otherwise your good faith is used as a tool to stall, disrupt, and do harm.

In that case, shaming is an appropriate response.

I may agree that this is an unequal yoke slung across both a good faith commenter and a rules-lawyered troll, assuming that your interpretation is accurate. However, it is not for us to say that bad faith must be answered with bad, and in fact the guidelines say that we must keep the good faith even in the face of bad. Otherwise we become the very thing we wrestle against.

You’re arguing for a kind of strained logic that suggests that two wrongs don’t make a right, but three lefts do, as if that could justify driving the wrong way down a one-way street. All roads might lead to Rome, but you can’t get there from here.

For what it’s worth, the comment I’m referring to in which shaming by me was perhaps not consistent with the guidelines was this one, in which I say that the commenter was wrong, their comment was bad, and they should feel bad. Dang said that this wasn’t okay, and I tend to agree to a point. We aren’t solely preaching to the choir here, so it’s not for me to say that they should feel bad per se, because that would be to stand in judgment of them as a person, and not merely to find their views contemptible. I don’t know if I find dang’s reasoning entirely convincing on the points, but I know his heart is in the right place by calling me out when I emailed him about being rate limited. You may also feel free to judge me, as I have also found myself feeling as you do.

https://news.ycombinator.com/item?id=44568173

> "Another problem is Microsoft is not merging the numbers with actual feedback"

That is a problem, I agree.

> "So, at the end of the day, the numbers are not there to secure user happiness, or giving clout to the Powershell team."

Members of the Powershell team are/were active on Reddit, Steve Lee the Software Engineering Manager for PowerShell commented[2] when telemetry was introduced: "Telemetry can help increase Microsoft investment in PowerShell. If the data shows increasing usage, we can justify increasing the size of the team. However, if the data shows the opposite, then we would need to justify our existence". Your claim that that is not the reason flies in the face of the people who put it there saying why they put it there. And the public RFC they did before adding it, linked in the comment.

> "You today have PowerShell because, some big customers said they need it,"

We have PowerShell because Jeffrey Snover ported Linux/Unix tools to Windows, found they were no use, and designed a shell for Windows. Then argued Bill Gates into having an automation system that wasn't graphical to compete with Linux. Before it was PowerShell it was called Monad and Snover wrote a blog post about his design document[1] where he talks about the design being customer focused and the team getting feedback that they were then one of the most customer-focused teams.

> "P.S.: ...and yes, Bash maybe a terse language, but it's better than PowerShell, a lot."

As you can read in the Monad Manifesto linked in the blog post: "the traditional approach to composing solutions is difficult and fragile. It uses pipelines to perform prayer-based parsing of text streams. These mechanisms are awkward, inconsistent, and imprecise. Admins spend the majority of their thought process on mechanisms instead of problem solving.". Having the shell do argument parsing for all cmdlets makes the user experience more predictable and consistent, the tooling for completing parameters better and more consistent, and reduces the effort needed to develop scripts and cmdlets. Better.

Everyone promptly moves from Bash to Python for scripting. PowerShell is a scripting language. Extensible syntax makes it usable in interactive shell and in code. Better.

"Monad takes a different approach providing a rich set of management oriented services for developing management GUI tools. These services allow management GUIs to be layered on top of the scripting engine and Cmdlets. This provides auditing, macro record/playback and integrated GUI/command line tools" - Bash has nothing like this at all.

Bash associative arrays are keyed by strings, PowerShell's can be keyed by different types because PowerShell uses .NET types. PowerShell can call almost any .NET code (C#'s standard library) and use the same object instances and call methods on them and the data is not serialised to text at any point. Bash cannot do this.

PowerShell can import modules over its remoting system from a remote system, run the cmdlets locally, get serialised objects to the local machine, which can invoke methods on the remote machine. Bash cannot do this.

Bash is not in the same league, not playing in the same game, much more narrowly scoped, and when it comes to language design it's not well designed. Both are full of warts and footguns, which is expected from a Microsoft tool but should not be the case for something which has been open source since 1989 in a world where its fans say open source means anyone can fork and improve stuff and stuff gets better over time. Given its much narrower scope and much wider fanbase, it should be trip-hazard free. Nobody should be moving to Python to make reliable small administration scripts, instead of everyone recommending that.

[1] https://www.jsnover.com/blog/2011/10/01/monad-manifesto/

[2] https://old.reddit.com/r/PowerShell/comments/ohieet/anyone_k...

Yes, I agree that person's comparison to non-consensual medical research is stupid.

> "Your opt-out telemetry is akin to your insurance sending you powered and Bluetooth enabled toothbrushes out of the blue to track you and threaten to cancel your insurance if you don't use that toothbrush and send data to them."

More akin to your insurance company making a public RFC where you can discuss the coming telemetry, then you choosing to ask your insurance for an optional toothbrush, being able to opt out of telemetry if you want to, the insurance company documenting how to opt out[1], you being able to edit the toothbrush source code to remove the telemetry entirely with the insurance company's approval because it's MIT licensed, and absolutely nothing happening to you if you opt out.