虽然你看来啥也没做错，不过看样子你本来就是目标韭菜，那么节哀顺变。
解压缩软件的核心功能是解压缩（既然你还要搜解压缩软件而不是具体 UI 特性，那就更加如此），但是你搜到的大多数其实就是 GUI 套皮。
不那么韭菜的用户都知道，现在专有格式都没什么消费市场，基本上所有格式的解压缩程序都是免费甚至开源的，主流平台都有。
如果觉得花钱在皮而不是核心功能上是更合适的支持开发者选择，那么被乐意套皮卖钱的开发者拿信息差噶韭菜而背叛，也是不奇怪的了。

要是实际项目，如果甲方有意见，你没本事洗甲方爸爸脑子，那就该用啥用啥，要么跑路撂担子。

自己玩倒是随便。反正知道这些东西的缺陷也都要轮一遍。（除了你已经知道的性能问题。）但是不建议没项目需求就浪费时间在具体一种上。
需要提醒的是，这里没给出项目背景就随便推荐的理由（什么生态……）多数不上道，你得多长点心眼。特别是不要遗漏不会对你的长期发展有好处，反而会锁死技术栈的风险。

其实有些重要问题不需要多熟练就能看出来，特别是你已经有很多不同基础技术打底的情况下。
比如性能问题……为什么会有？

嗯，很好，正好有人推荐 Flutter……就顺带有部分答案了。
https://github.com/dart-lang/language/issues/490
(1/1)

另外 imgui 这种画网页不鸟 DOM 一样不鸟 WIMP metophor 的 GUI 之耻就算没人提我也要比 Flutter 多黑一下的。当然，我不反对观摩一下所谓 immediate mode 的实现，这样才能理解它们如何拉胯。

@HankAviator 微软曾经是坚持 EEE(Embrace Extend Extinguish)，但是至少 Linux 这块认识到了自己根本没这个斤两，只会口嫌体正直了。
比如 WSL1 做个替代实现都做不全，就怂到直接自己编译内核了……

@m4d3bug 那么看不见的有啥，你举一些例子吧？编辑器或者 IDE 之类的开发工具很吃用户习惯，如果不是有足够优势大多用户是不大会切换的，所以好用的不知名的例子远少于其它软件，更别说好用到能让大量用户自觉付费的了。

@TomChaai 倒不如说是爱抄不抄。基本只有 GPL 或者某些商业开源项目才比较刻意会欢迎抄（因为别有用心），只要是抄完还能被抄回去。
还有一种管生不管养的。稍微有点家教的是儿子闯祸别说是爹。要求认爹已经是很有追求了……

借鉴思想……被借鉴得最多的数学家物理学家还没找你算算总账呢……

@miniliuke 显然有关系，没源码的东西借鉴起来麻烦不说，连发现能借鉴的地方都麻烦，没钞能力那就四舍五入当作不存在好了。
@m4d3bug 这不大对，Atom 已经嗝屁了，VS 自家的，还有啥对手？ JB 家的么……你确定人家没盈利？还是说打算干翻 NP++/Sublime （这目标听着就有点 low 吧）或者 vim/emacs/nano……？

@FrankHB JSC 唯一→JSC
低级 typo……

@DOLLOR 是 JSC ，没注意打快了输入法选词一回车给跳了……
JSC 唯一较早就支持 ES6 的主流实现。到了 2022 ，它居然仍是目前唯一具有 ES6 PTC 的少数实用 ES 客户端实现（剩下也就 XS6 和 Duktape 俩没法相提并论的弟弟）。
关键点是，和其它特性不同，这里其它实现缺少的 PTC 对实现结构的影响是重量级的，原则上无法通过 babel 之类的外加运行时 polyfill 套皮高效正确实现（实际上不说多出来的开销，现在就没一个正确的），要添加正确的实现基本就只有回炉拆了重造。因此第三方现实不可能补救这个特性缺失带来的缺陷。
尤其可耻是 v8 曾经有--harmony-tailcalls ，后来因为可笑的“工程”理由给干掉了。（那你费劲实现干嘛？）

大概就是对 tag 的用法少根筋。
用 tag 标记 tag 主要是两个用途：传统的 release tag ，以及某个开发周期起始时的 checkpoint （鼓励一个范围内的固定起点，以避免任意位置建分支导致任何处理不同分支——包括合并——时潜在的工作量膨胀）。
master 分支是默认分支，一般放公共主线，本来就不是放 release 用的。一般用于 release 的 tag 都是在各个 release 计划中拉出来的具体版本的 release 分支的最后的公开 commit 打，用 master 分支上面打 tag 是极端偷懒行为，几乎只适合只有一个人开发的情形。
还有一种 tag 是专门用来做 checkpoint 的助记符。这种 tag 基本就是应该在 maintainer 负责的分支打，如果项目没多层 maintainer 那就是顶层主线也就是 master 分支。
一些成熟的项目会明确在两者中区分，例如 GCC 迁移到 git 后就有 releases/和 basepoints/。
原理：因为 maintainer 和某个 release 的负责人通常不总是同一位，区分 release 分支对区分责任和防止 release 阶段的提交冲突是极其有必要的。要是 maintainer 在过了 merge window 还要傻等 release branch 上的提交包括 release tag 同步却因为个别负责人的意外造成整个项目本不必要的阻塞和延期，那就真特么搞笑了。
当然，虽然原则上限制了 DVCS 的潜力，如果中心集权到 Linus Torvalds 这样总能确保 master 上面快速发版，其他开发者会老实允许你周期性足够短地 freeze master ，那两种 tag 都塞在 master 上也不是实际不可行（像 docs.kernel.org/maintainer/rebasing-and-merging.html 建议的 merge ff 用的 tag 其实是 checkpoint ）。但做不到那还就是笑话。注意虽然对组织内保持权威一般不难，但是外部开发者未必有听你话的义务，全窝在 master 上发版节奏太拉胯惹毛了外部开发者，别人直接 fork 也不是不行。
但那个图里最大的问题还不是这个，而是临时分支居然叫 release ，成心给 release engineering 找不痛快。正常讲，这种临时分支一般都是匿名的，从来不指望不同阶段复用，非得命名也是叫 prerelease/rc 之类的。需要事后维护倒是最好约定命名，如 www.freebsd.org/releng 。

@GeruzoniAnsasu 虽然相互合并通常是 evil ，但是无视分支目的教条主义更加 evil 。
在 DVCS 中 master 分支存在的目的几乎就是全项目单一来源的全局主线（只是要实现配置管理分锅或者跨厂商管理的目的，可以 fork 整个 repo ，不需要窝同一个 origin ），因此负责人或者说 owner 大多数时都需要对其中的内容完全负责并有在整个项目中协调发布节奏的绝对权威。
如果禁止自主 merge master 造成滞后（特别是预期就会跨 release tag 的大改动），到时候差异过大再 merge 回来，会严重阻碍中心 PM 负责人的吞吐量乃至整个项目的分支同步效率。这在上规模的（日常 master 成天管合并 PR 就够忙了）项目中是不可接受的。

搞编译器的，夹在前端和后端中间的东西正经的叫法就叫中端(midend)。
CPU 流水线里的前端和后端就接了个 buffer 。大约是因为跨 ISA 翻译之类不流行以及加流水级代价太大的关系，翻译指令的也都直接算成了前端。
但你说的这块就算是 Web 传统后端的一部分，虽然有一部分抽出来当中间件了。反正跟 Web agent 不捆绑在一起的东西习惯上都不会叫做前端，市场上招前端的也不大会强制要求熟悉这个。
以前前端页面以后的这些东西都是后端工程师来做，像 PHP/JSP/AST 这样并列的 server page 就是“后端页面”。Node.js 也是做的服务器应用，恰好方便前端工程师少学点语言罢了。后来大约是鼓吹前后端分离，发现一些 server page 里不少 view 的成分，外加前端工程师比较膨胀，为了增加人力利用率，就让前端工程师去折腾这种东西了。

@FrankHB 看了下，好像是我 out 了，现在都有 zig c++了。
不过除了包装东西给 zig 调还是意义不大。

用 JavaScript 而不是 v8 看来是 ES conformance 上正确的选择。
@janxin 想多了，clang 是前端，后端是 LLVM 。
且不说 zig cc is not the main purpose of the Zig project ，zig cc 也就是套皮 zig clang 而已，后者依赖 libclang 。所以 zig 做的连前端都算不上，只是个 driver 。
装 zig 去编译 C 也就是只需要 C 前端的时候省事（然而作者起码没放弃 C++）。但真要轻便，除非要一次性搞定所有 target arch ，直接 tcc 不更实用么。

@dcsuibian @yeqizhang 这种理解是错的。
内存泄漏指的是违反资源管理预期表现的行为，可达性判断只是其中的一个保守标准，还有其它种类的 indefinitively lost 。
理论上，[Cl98] 提出以空间复杂度类描述内存资源泄漏。这是一种涵盖比较完全的分类。在这个意义下，没有 PTC(proper tail call) 泄漏调用栈也是一种泄漏。PTC 以上还有 evlis/sfs(safe for space)等更强的保证，不过静态语言一般会因为要求局部变量静态确定而自动满足 sfs 了。
实际上，C++ 这样的语言在基本运行时实现中也存能在其它种类的内存泄漏，例如 libstdc++ emergency buffer 会被 valgrind 标记为 lost ；尽管维护者 Jonathon Wakely 缺乏相关了解而拒不承认这是 bug 。
泄漏并不都是不可接受的，取决于用户和开发者的预期。所以经验上，@Jooooooooo 给出了理论上也能正确的万金油回答。
但是用户未必那么好说话。所以经常只有应用开发者两头受气了，如果自己没个数下场可能更凄惨。说到这里，再日经鄙视一下：github.com/dart-lang/language/issues/490 。

[Cl98]: https://www.researchgate.net/profile/William_Clinger/publication/2728133_Proper_Tail_Recursion_and_Space_Efficiency/links/02e7e53624927461c8000000/Proper-Tail-Recursion-and-Space-Efficiency.pdf

@XiLingHost 看起来不咋地，理由不够具体，也没有提到系统发行版自带的选项。

不如这里的讨论靠谱：
https://news.ycombinator.com/item?id=28820601

@lower 并没有，而暗示了经验不足。

不过 GraalVM 确实和所有其它的东西不是同一个层次上的产品。如果从其它语言运行时迁移（不依赖现有 Java 实现的“扩展”特性和具体实现），那么是个首先值得考虑的选择。

@celeron533 对用户这算不上太大的问题，绕过的成本比较低，无非多用一些科学手段。
真正麻烦的问题这里好像就没人提到：对用户生成内容的控制权。之前讨论（ v2ex.com/t/836360?p=3#r_11409991 ）过，一旦用户账户不可用，发布的历史数据（例如，issue 上的讨论）也不保证可用。原则上别人也没法导出备份这些数据，这意味着这部分内容的发布完全不可靠。所以任何有意义的公共项目应该预估这种损失数据安全和言论自由（字面意义）的风险。
这点和服务方的立场原则上没关系，像强烈声明支持 FOSS 的 OSDN 也一样不保证内容的完整性，甚至允许无理由突然终止服务。这在一定程度上很正常，因为法律原因，对无偿服务担保可用性的承诺是愚蠢的。但是没有提供让用户摆脱这种依赖的手段，客观上一样算不上多支持自由。讽刺的是，这样的网站也许就是靠着 Web UI 比 GitHub 不方便（让用户不会太习惯去依赖；虽说其实功能更多）才显得更尊重自由了。
依赖无法保证可靠性的服务，最终需要靠每个用户的自觉。

把 copyleft 翻译成复制权也是没谁了……
黑版权保护制度最狠的还就是 RMS：www.gnu.org/philosophy/shouldbefree.html
SFC 这坨沙雕被咬也算是一种不熟悉经典的咎由自取：www.gnu.org/philosophy/who-does-that-server-really-serve.html
实际上这里的问题一早存在，并且从来没被解决，跟 copilot 是不是收费毫无关系，会遇到这种问题当年（在 GitHub 没有在合理时间正面回复时）就应该直球抵制（所以这里显然不如从 GitHub 直接润了的有先见之明）。即便是要以 copyleft 保护“软件自由”，因为许可证没针对过 copilot ，也是举证不遵守许可证的侵权才会发挥作用，就是看最终的代码里有没有构成侵权的内容，跟是不是用了 copilot 根本无足轻重。现在借着 copilot 收费的东风煽动抵制，倒是让人有疑问：之前干什么去了？另外，某种意义上，客观上能借着这个机会扩散 GPL 而不用管某些作者的反对意见，反而应该感到窃喜才对。
另一方面，不把微软的代码放进去当训练数据这个大可当笑话看，这样过几十年很有可能就不止没人，也没 AI 会懂微软那坨专有陈年旧屎了，不会有什么实际衍生作品的可能，也不会继续维持路径依赖污染 FOSS 生态，属实反微软党大胜利（

@fuxkcsdn GitLab 没 GitHub 的根本问题，因为它同时提供 FOSS 的代码托管服务器软件，允许用户自行部署获得近似的体验而非构成 SaaSS ，这样还要形成依赖算是用户活该。
当然你可以把对社交网络的依赖算上……但这样的话不妨说依赖 Web 也是得算损害自由的，毕竟 W3C 都是“最坏的”积极侵害自由的实体（ www.defectivebydesign.org/w3c ）。

@ayase252 如果有合同约定，那么还真可能需要用户批准。发版经常是会对用户造成附加成本的。
爱用用不用润的东西自然凉拌。但要是可能会在事实上垄断的东西，又得另说了。除非变更是用户要求的，即便用户无权批准，道义上和舆论也应当给出补偿以挽回变更引起的不公平的损失。说白了：单方面麻烦非特定公众，不给够用户好处，就是你欠用户的。

@otakustay @starrys 分不清 patchlevel 干什么用的，大概说明 release engineering 能力约定于零。
这倒是正常水平，实际也没多少项目的涉众会意识到需要有像样的 releng 。
话说回来，这跟刷 major version 性质确有不同，但有些后果是共通的。

@ksco 在具体项目背景下，大道理没错，但站位太低，恰好被 RMS 全方位爆杀。
典：www.gnu.org/philosophy/shouldbefree.en.html ，c.f. "everyone (concerned)"（因为中文“所有”的歧义，还是看原文吧。）
特别是 recently-invented mythology ，简直是召唤自由软件运动打脸的：什么开源这弟弟，也不是挺 recent 的嘛……

@pangtianyu @gaodeng 营销不一定可耻，可耻的是占用不对等的公共资源攫取少数人的私利。
大众鄙视 Chrome 刷版本并非因为它技术差，而是因为它的变更充分体现了自以为是：版本更新非但未必是对一般用户而言的品质上的改进，反而可能给大量在乎使用体验的用户带来麻烦（比如强制隐藏 URL ），因此有用户对版本提升 PTSD 也毫不奇怪。（你看人家老黄家的驱动刷的版本号不更狠，但恶心用户的显然主要不在这方面，也没每迭代一个大版本就“骚扰”用户和通过推行不兼容技术强行提醒你过时，就没那么在这个方向上被鄙视了。）结合占用大量社区资源和近乎垄断性的用户关注度的客观事实，这种鄙视是很正常的。
（能更上一层楼的，也就类似“听说你要教你爹做产品”的张小龙之流了吧；不过人家还经常藏着 release note 不发没那么自卖自夸，也没多少能力搞诸如往国际标准里面掺杂私货(eg. TC39 STC)强行连带非用户一起恶心的破事，这些意义上反而比较文明了……）
相比，刷版本号的行为本身简直是人畜无害的傻白甜了（虽然污染 semver 之类仍会有更深刻的危害）。
更重要的是：以大量用户吃亏为代价，谁得到了什么好处？上帝视角看，就是便宜了对版本号有预期 KPI 的 PM （“营销”人员）而已。他们的目的应当比这些用户更重要吗？
最后这个问题有时不好说，因为没这群人可能项目都不会存在，用户不太有立场说三道四。但 Chrome 明显不是这种情况；他们不配。

遗憾的是，还有一些更加重要的版本更新灾难缺乏关注——连刷 KPI 的实践都不断地失败了，没有赢家，却仍然持续——让几乎所有人都只会体验到不稳定、碎片化和冗余成本。例如，ISO C++近年来持续频繁更新不完善的半成品，远比 Chrome 这种弟中弟影响深远。

尽管产品形态相去甚远，为了快速发版而发版背后的心态（乃至价值观）很大程度是一致的——不优先考虑用户的全局需求，唯恐市场存在感灭失而有意吸引用户眼球，黔驴技穷就局部搞点事做（是否既定需求不重要，虽然用户有要求过自然更好），表现自己有能力推进项目进程且有实质进展——这种声东击西就是一种所谓的“营销”（以及某些所谓“敏捷”之流的玩意儿）的常见姿势，而改版本号就是向没对应需求的用户表现成果的首要“抓手”。显然这占用了大量的（如果没不要脸到一定程度的话）资源，却不见得产出用户需要的东西。越是涉及重要公共利益的项目，这越不可接受。这也是为什么刷版本号（包括版本号长什么样）不是根本问题，却仍有必要从抵制刷版本号入手反对的原因。

这里的“营销”，到底不过是“损人不利己地犯贱”的一种雅称罢了——是一种基于为了尊重涉众，硬是想为现状找出一点客观上可辩解的理由而不是直接承认某些不适格项目（“营销”）人员纯粹犯傻——的善意尝试的结果。（说实话，其实很多社区人员连正经的营销都不会。）

如果缺乏人员能保证做对一些基本的事，那么也许保持现状完全不发版对全世界的人都更好（即便考虑了会有高危缺陷没及时被处理的风险）。毕竟有些宁缺毋滥最后却要公众擦屁股的东西，是没有后悔药的。我强烈建议，即便没能力单方面改变现状，也要对某些试图把屁股无缝对接到用户嘴上的无赖行为说“不”——除非不在乎被彻底堵住。

……你这标题。。我还以为现在微信已经流氓到卸载也需要专用定制方案了。

@kop1989smurf 未必，也可能只是想打死异教徒维护自身生存环境安全类似的心理而已。

@Kould 即使使用得当，不限深度的嵌套数据结构集中释放也很容易出现高延迟的问题。（这不属于使用不当，因为语言允许轻易地构造这种对象。）
实际上不容易观察到类似的问题，是因为在此之前，大多数 naive 实现在递归调用释放资源的例程中就直接爆栈了（