没有任何参考价值，一个富二代想要体验生活去做了程序猿，体验完了，要去经营酒店了，这对任何只能拿薪水，最多拿点员工股的程序猿，有什么学习的价值？？？

人家技术栈和架构设计就是好，说不过是用了这个，用了那个，这些不都是技术栈和架构的一部分吗？不喜欢别人的技术栈就不承认别人做得好，这是什么心态呢？我虽然不喜欢 go ，但我觉得 dapr 做得不错。

@lesismal 原来是 go 吹，go 用了什么都要成主流是吧？流行的开源项目好多都有 rest API ，除了前面举例的，还有 devops CI CD 整个生态的大量软件都提供 rest API ，不仅 put delete ，甚至还有 patch ，云计算平台也是目前趋势吧，也是大量 rest API 。你的回答是不是趋势不一定对，主流不一定好？看来你是权威，只有你才能决定什么是对，什么是好

@lesismal 我做 10 几年开发，现在做架构设计也做开发方面的工作，当前客户基本都是 500 强，不以当前的工作举例还能怎么举例？和我以前的工作接触到的客户比，当然是他们的安全政策最繁复安全管理最严格，你看到几个很菜的能说明什么问题？

我在客户内网工作必须使用客户的电脑，操作服务器必须用跳板机，所有开 IP 和端口白名单必须申请并说明理由，除了 web 和邮件等少量服务器其他服务器不能有外网连接，代码发布前做安全检查，服务器定期安全扫描等等，按你说的这样的安全是不是够工程思维了，但检查到需要整改的安全问题从来没有与 HTTP 方式有关，客户网络安全环境可是跑着跨地区几百上千个大大小小系统的网络。

现在的软件和服务生态已经包含了那么多 API 使用 PUT DELETE ，网络环境复杂，但你反正永远强辩别人做得安全就是场景不同，我也看不出你说的所谓场景有什么特殊的地方。再次强调 HTTP 不是只有 CURD 才用，所以很羡慕你能在你的公司有权无理由拒绝需要调用 PUT DELETE 的一切应用。不过现在生态变了是趋势，建议您还是要跟上时代呢

@lesismal PUT DELETE 就一个 HTTP 方式，居然还上升到工程架构这么高的级别了，明显就是说服力不够，非把一个实际上不存在的小问题渲染得及其严重。前面说了，现在很多 API 就是有 PUT DELETE ，所以必须开放，没有能不能可以不可以的所谓选择，也从没听说现在的这些软件和服务哪个是因为 PUT DELETE 产生的安全问题，让人黑了。大概只有你这种抱残守缺的才会找莫须有的安全问题作为借口，我做 500 强的几个项目都没有遇到这种莫名其妙的安全策略，看来 500 强的安全部门都没有你厉害。和你共勉就免了，有的是与时俱进的大牛让我向他们学习。

@lesismal 我理解，你的意思就是我的地盘我做主，我在管网络就是不让你改。

@lesismal 我们在给世界 500 强公司开发，别人的内部网络安全策略那么严格，需要申请网络策略变更开 IP 开端口，只要走流程能说明清楚，都是可以开，从来不会被各种过时的安全理由而拒绝

@lesismal 在你眼里除了 CURD ，别的开发就不会有 PUT DELETE ？那么你说我开发部门要开发一个功能一定要调用这些 API 怎么调用？既然你承认别人的 API 是安全的，却又不让我用，你逻辑自洽吗？

@lesismal 现在很多主流软件和云厂商的大量 API 都有 PUT DELETE ，在你眼里居然都算专用场景，那什么叫通用？不仅云资源配置、对象存储，其他云厂商服务或软件我随便找几个 API 都有 PUT DELETE 。

Azure 翻译文档 API
https://docs.microsoft.com/en-us/azure/cognitive-services/translator/document-translation/reference/cancel-translation

阿里云日志索引更新
https://help.aliyun.com/document_detail/74912.html

MongoDB Atlas
https://docs.atlas.mongodb.com/api/

ELasticSearch 删除 API
https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-delete.html#docs-delete-api-request

国际云厂商都是通过众多安全合规标准的，他们有 PUT DELETE 也能通过，凭什么说有 PUT DELETE 就是不安全？在我看来，安全问题并不是 PUT DELETE 本身造成的，但部分安全部门和厂商只会一刀切，这就是懒惰、不思进取、推卸责任。

@xz410236056 你自己逻辑搞笑，安全厂商屏蔽 PUT 的理由是你说的幂等不安全吗？你用这个来说明厂商是对的，这不是牛头不对马嘴吗？防火墙厂商认为是 PUT 修改数据不安全，我说 POST 也修改数据那也一样安全，逻辑上哪有问题

你自己逻辑搞笑，安全厂商屏蔽 PUT 的理由是你说的幂等不安全吗？你用这个来说明厂商是对的，这不是牛头不对马嘴吗？防火墙厂商认为是 PUT 修改数据不安全，我说 POST 也修改数据那也一样安全，逻辑上哪有问题

@xz410236056 PUT 不安全这个观点毫无依据，是应用垃圾才不安全，却怪到 PUT 方法本身，这观点一点都不正确。如果 PUT 修改数据就不安全，那么 POST 新增数据就安全了吗？我们公司做云平台项目和产品，云厂商的 Rest API 全都有 PUT DELETE ，还需要 OPTIONS 支持跨域，云厂商可都是安全合规的，所以现在还说 PUT DELETE 不安全的都是瞎扯。

@Buges erlang go 都是面向并发的编程语言，和同步异步都有的开发平台比较，你就像在拿 OLTP 和 OLAP 比较，说 OLTP 为什么没有 OLAP 读性能好。

关于异步同步阻塞，只说.net ，以前的 .net 版本有同步上下文设计，但 .net core 以后的版本就不是这个设计了，前面有人说了，异步任务调用同步方法只阻塞当前任务，哪有阻塞整个应用的，而且实现变了 async/await 编程模型却没有变。即使其他开发平台有你说的这种情况，也正说明和实现有关，和 async/await 没有关系。

另外，你认可的 Kotlin 也有 async/await ，但不影响它有不同的调度器，并且不同的编译目标还用不同的实现。明显，好坏不谈，async/await 编程模型可以有各种实现，但你始终模糊 编程模型和实现 的界限，将它们混在一起。

建议教育别人前先自己厘清概念，还有你的回复中那么多名词不是专有词汇都是有中文翻译的，我和香港客户谈技术问题都不会夹这么多英文词汇，是不是你中文不太好？

@Buges 大多数开发平台都是同步异步都有，当然要实现 2 种，否则怎么区分，这也能算缺点？异步上下文调用同步方法会阻塞和 async/await 有什么关系？前面我强调了，async await 是用来简化异步编程模型，使源代码的逻辑简明清晰，易于阅读和维护，并没有改变开发平台实现异步编程的控制调度，你非要把编程模型随意扩大解释，把语言特性和背后的实现混为一谈。各个开发平台实现的效果各有好坏，但同步异步都有的开发平台里，async/await 显然是最好的异步编程模型，否则不会在 C#首创后被多个新旧语言学了去。你只是看着好像知道很多知识点，但实际连基本概念都搞不清，只会翻来覆去扯几个名词。

@Buges await/async 是业内公认最佳异步编程模型，新老语言 js Python swift rust 都实现了这个语言特性，它只是编程模型，便利异步开发，难用从何说起？它并不改变开发平台本身的控制调度，你要想自己控制调度不用它就好了。你比较开发平台间异步编程的相同不同就算了，还把这种比较和 await/async 编程模型好不好用联系起来，不仅基本概念错误，比较本身也值得商榷，完全就是伪命题

go 加了泛型，可能要加模板了，还大道至简吗？我们开发组在做一个产品，最初也是希望轻量简洁，随着产品进化，筛选特性，很多次迭代做到现在还是变重了。为了满足技术需求，最终 go 也会走上逐渐增加特性的道路

@Remember 这是你的关注偏差

@orangie JAVA 历史遗留问题，很难改了，你说的特性只有运行时真泛型才能做到，反射是运行时，编译时泛型是做不到的

@wxw752 我看英语文档无障碍，但还是得考虑有人需要中文文档，虽然机器翻译有点生硬，但结合样例代码可以满足大多数需要