@fatedier 这是另外一个话题了。老板都想招到即插即用到岗马上能干活的程序员，但技术变化那么快，抱有这种把人当机器的想法当然是事倍功半的。 能好好写 golang 避免不必要的 copy ，避免过迟 defer 的你以为很多么？

@jarlyyn 一方面说语言没有优劣， 然而 golang 又自称以 better C 为目标，你们 gopher 真心精神分裂啊。

既然 golang 以 better C 为目标，那现在混成这样也挺尴尬的，嵌入式也用不了，高性能也比不上，说广泛使用吧也不如 Java 。除了有一个三心二意的爹之外一无是处啊。

golang 有啥有资格看不起 C# 么？ 做 3D 有 Unity ，做跨平台 GUI GTK#， Bridge.Net 把 C# 编译成原生 Javascript ，这样的话连 HTML 都不用写，不想装运行时可以 AOT 。 你 golang 连个 hot fix 都解决不了，真不知道有啥好吹牛的。

@gamexg

我司线上服务器用 mono 已经很久了。
如果你说 C# GUI 开发就是指 WPF 之类的话，这当然是没有的。
但是 xamarin studio 本身就是一个很好的 C# 跨平台 GUI 开发的例子。

@jarlyyn 无耻之尤。 我说了 C# 里面有 而 Java 没有的东西来证明非 copy ，你却跟我说不关心细节～ 那你 golang 不也是 copy C 语言吗，谁关心语言细节了？

关心应用场景？好啊，那你说说 golang 怎么写 各种平台上的 GUI 应用啊？

@jarlyyn 那你说 linq 是抄了 java 的什么， async await 抄了谁， yield return 又抄了 java 哪些特性？

@jarlyyn c#是 copy java 这样的话你也说得出，怪不得你认为语言没有优劣之分。

你自认为是码农就算了，不要把所有研究编程语言理论抽象符号运算等等问题的人当成是没事找事干。

降维攻击你赢了

@jarlyyn 我觉得很多人在讨论语言的时候，经常会陷入一个思维误区。
不存在“世界上最好的语言” -> 语言之间没有优劣之分。 请问这个推导你认为成立吗？
我认为不成立。

C# 部署难吗，有 .net 就 .net , 有 mono 就 mono ， 两个都没有，我还能 AOT 成本地二进制。部署难吗？

C# 尴尬吗？ 如果做不到老大就尴尬，那么 golang 应该跟着一起尴尬吧？ golang 在哪个领域做到老大了？ 高性能服务器依然是 C++ 为主流，复杂的大规模服务 Java 是主流，请问你 golang 算老几？

说句不好听的，能用一门语言解决问题，为什么要用多门语言？ C# 能搞定 PC 端，移动端，服务端，浏览器端，为什么要多搞几个人？

当然啦，我也不是介意多学 几门语言，然而学了几门语言之后还想一头扎进 golang 的话，那真是没悟性。

@CRVV 我的意思是，这个世界并不需要到处都需要重新实现写一个 docker ，但是到处都需要写业务服务器，到处都需要 OS 。更重要的是， docker 作为一个具体的软件是可替代的。但是业务服务器作为一个广义需求是无法被替代的。所以，我的意思就是，你举 docker 这个例子来试图说明“ golang 有别的场合能用”，我也是觉得怪怪得，因为 docker 本身并不代表一个 场合。

@CRVV

要这么说的话……那应该 C/C++是世界上最好的语言？毕竟 Linux ， Windows 都是用它们写的。
golang 有什么特点可以说明 docker 这样的软件用它来写是最好的呢？
我觉得只有“适逢其时” 这一点了。

话说， Mono 或者 .NET runtime 本身就是一个 可以自行隔离多个组件的 VM 呢，
C# 的动态加载 API 也能支持这一点，这难道不比 golang 屌么

golang 的能力相比 C# 加上 AOT 之后，优势就所剩无几……
C# 在跨平台开发上还有 Xamarin 之类的撑一下场面
golang 除了写 业务 server 之外，没有想到任何别的场合是能用的。

@mhycy

1. 那是因为你没见过会扔 100 的服务器，你说 Http 100 算不算异常？

2. 你觉得为什么设计 HTTP 的时候要把 status 放到最前面？
因为只要知道是 400 就足够判断不需要缓存结果了。
你要知道，并不是所有 client 都会处理所有 HEADER 的，有些 client 支持 X 开头的 Header 有些不支持，
你指望全部节点都能理解 HEADER 真的很天真。

3. 如果你的 API 只服务于 Web ， 那你干嘛要用 Restful 的形式呢？
大才小用，然后再根据自己的需求来说，大才这么做简直是浪费。
我觉得这很有意思。

@mhycy
1. API 监控报警只监控 200 以外的状态码即可判断 API 失效
严格来说，你这个说法错漏很大，先不讨论细节。很多 API 监控报警机制都是依靠 HTTP 头的，很少会关心 Content 。你把所有的 error 塞进 content ， Http Status 都是 200 了，那么是不是就没法监控了？

2. API 的缓存当然只能依赖返回码了，难道还要检查缓存的内容才能决定要不要缓存吗？

3. 嵌入式设备知道 HTTP 但不一定有 JSON 解析能力。问题是，还是我一开始就在本帖里面就说的那句，能用 400 500 就能表达的意思，为什么非要塞进 Status 为 200 的报文内容里面？你要塞进去我也不反对，但为啥又要把 status 硬要设为 200 ？

4. 这是针对你的思路，你说 200 + json 对于浏览器劫持有重要的豁免效果，虽然我觉得很 bullshit 但你非要这么做的话，我只是提供你一个不会以文害义的做法。最好肯定就不改 http status 啦。

@mhycy 总结 200 + json 对比较大规模 API 服务的缺点：
1. 对于会话层不友好：具体来说就是，譬如上面讨论说到的缓存控制， API 警报监控之类的应用，光这一点我觉得已经足够了。
2. 对于开发者不友好：如果使用你的 API 不仅仅是 web 端，还包括 移动端甚至别的端，那么你就要保证这些端都要有 解析 json 或者 xml 或者别的什么格式的能力，才能知道如何处理你的消息；这也意味着对更多的开发者来说，除了 HTTP 以外他们必须关注你的自定义格式，但是假如我仅仅是写一个小 demo ，我不关心出错信息，只想尽快跑通， json
+ 200 的做法，就给这种快速开发测试的需求制造了不必要的障碍。

事实上，如果你真的很关心浏览器使用 API 时受到的干扰，那么你完全可以用 open resty 之类的或者别的流水线，自己写一个简单的报文解析，根据 Agent 和 回复报文内容，将 Agent 是浏览器的 HTTP 回复 的 status 统一改成 200

@mhycy 主要是你得出使用 200 + json 的结论依据，在我这里看来是说不通的：
你认为： 中间设备干扰 and HTTPS 也可能被劫持 and 非 200 HTTP 回复可能会被劫持，这是我从讨论中知道的你使用 200 + json 的理由。
我认为： 如果 HTTPS 都劫持，那么使用 200 + json 的做法，在大规模网络应用，是缺点多于优点。

我觉得确实没什么好讨论的，明摆着大厂都不用你的做法。
而如果你的业务够小，你喜欢怎么来当然都是 OK 的 --- 那不如更直接一点，直接在 80 端口上走自定义协议不是更好么，反正你也不需要 HTTP 的特别加持。

@chairuosen 只有不懂 rfc 威力的人才敢说 http status code 是冗余字段，理由我说了，全是 200 的话，你就别指望中间节点替你做进一步优化。再简单一点的例子，一堆客户端上为你做请求监控和警报的库也废掉了

@chairuosen 我没有说过只用 http status code 。我是反对，无论 api 如何处理 请求都返回 200 。

@Symo 觉得不屑与我讨论就请拉黑加屏蔽，众目睽睽之下拉坨屎你这是干嘛呢？好了，现在屎拉到我身上了，满足了你奇葩的虚荣心了吗？

@mhycy web 场景下我也没觉得 200+json 有什么特别的优势。当然啦，受制于国内的实际情况--很多 web 前端只是半桶水，不喜欢上 https 甚至 https 据说也被劫持--用 200+json 的好处也就就是能适应这种状况了，但非要说这是优势的话，我想起了这笑话: 中国人最大的特质是什么？贫穷。