由于高可用架构群每天有大量技术讨论，同时在架构领域也不断有新的技术及思想产生，因此架构君摘取部分值得一读的讨论及资源，供关心架构领域的同行参考。小编不生产文章，小编只是文字的搬运工。
码农界有个广为人知的笑话
女神：你能让这个论坛的人都吵起来，我今晚就跟你走。
程序员：PHP是最好的语言！
某论坛真的就炸锅了，各种吵架……
女神：服了你了，我们走吧，你想干啥都行。
程序员：今天不行，我一定要说服他们，PHP必须是最好的语言……
今天的日报也是由一个典型的争议问题开始
调查：有哪家之前不是用java开发的，后来转java的？为什么转？
语言讨论
淘宝就是经典案例啊
还有京东[呲牙]
还有twitter
亚马逊也是，我进去第一个项目就是c++ migrate到java
携程也部分服务开始用java了吧
Twitter的Heron，C++，这是理性回归吗
Java之争
C和C++在基础服务还是可以的，比如想存储什么的，偏上层一点的 真不如Java好
第一.net等闭源的语言，访问量上来，很多问题没法跟到最里面来定位问题,所以好多电商后期换java, 第二Java人好找，开发效率高。以前一直搞py和cpp，看不上java，后来又不得不搞Java了
反正我对语言没有偏好，什么合适就用什么，上次遇到个写go的，说实在受不了Java的try catch，太啰嗦了，然后我说go的error从底层传到最上层，每层要写if，java只需要扔一个runtime出来，然后在最外层的框架层处理，他就不说话了
Java做业务也比go强一点，java代码可以做到业务方根本看不到任何关于db的东西，比如连接多库，transaction控制，但go就比较难
Java让我这种资质平庸的人也能写写代码[呲牙]
Java有强大的人才库和企业持续投入支持，这就是最大的优势啊
Java的整个生态更完善些，go的依赖管理就把人搞郁闷，go适合于追求自由的程序员，无拘无束
Java对语言内部了解比较深的也不多的，这一块感觉还是挺缺的
我倒是觉得现在必须要考虑一个语言，很容易找到人接盘蛮重要的。
有时候人跑了，一个公司然后这个语言就没人玩得动，招人也找不到，就悲剧了。
那后端真正的api还得从Java、c++、go等里面选。
Golang
C/c++程序员对go的认同度更高些
.NET 转 Java，C/C++ 转 go，基本这趋势
chrome等基础软件还是得c cpp. 美国这类软件比较多，国内基础软件比较少
并且谷歌这几年名声不太好，用go也顾虑颇多。
Go 想保持简单这是好事，但有些东西用起来 还是有点不太够
选go或者node 甚至lua一般就是业务轻 高性能
其实我有个感觉，就是推崇go的都是以技术为出发点，热爱编程，享受编程带来的乐趣，打开vim，啪啪啪的就可以享受编程了，但是java更更像是从事情本身为出发点，一堆的规则，力求避免程序员人为犯错，关心怎么样一起协作，怎么样管理依赖等等
C/C++
go 目前应用主要还是服务端，C/C++ 在桌面应用还是强，不过现在真没多少桌面应用了
chrome把cpp模板的用的淋漓尽致，能往里跟的动，也是需要一定力气的，基础软件主要出于性能考虑吧，不好用java
c++招有经验的越来越难了，学习曲线长
以前做山寨机业务代码全部是c，不过设计相当不错，用c实现了面向对象方法
游戏服务端应该用c++写业务逻辑的比较多。
我也见过用c实现面向对象的，整个工程全是结构体和函数指针
当时我是帮他们解bug，真是看得想吐，其实代码结构很清楚，只是一堆void*指针
Python
每个语言都有它的优点，应该共存的，流行的语言不一定语法比另一个好，流行有很多其他因素，比如ruby，lua比Python语法更好，但是没py流行
Lua
Lua火在游戏届
Lua用来做胶水语言，也挺好的。
nginx+lua做业务现在也很多
agentzh一直在做Lua的生态，推他的openresty
上一家公司很多后端服务都是用nginx+lua做api
之前好像看到又拍云也在往nginx+lua上转
脚本语言其实不要有经验，边学边用就行了，一般人都没什么问题。很难的服务端高并发一些奇奇怪怪的问题，需要一两个源码级的够了，没数据量也碰不到
是的,就是前端和db中间的
lua一般不写业务太复杂的服务 我觉得，要说另一种语言也就是用c来写一些模块扩展
是的，业务不复杂，性能要求高。比较适合用lua
当然 由于lua对nginx的依赖 也是个制约
lua+nginx可以做做代理层面的扩展，比如统一身份认证啥的，类似于api-gateway, 写具体的业务逻辑还是比较费劲吧？
目前看到Lua除游戏外的，就做这块，和nginx配合使用。
lua游戏那边主要是云风，nginx+lua这边主要是agentzh。感觉就他们两个的博文较多
lua需要c来写模块，做些复杂点的逻辑，更复杂的需要后端服务提供api。那后端服务又得选语言。
用lua纯实现业务逻辑还是有不少坑的，版本越高越慢
业务复杂后用lua确实不太好维护
用Lua写业务，感觉是不需要用rdbms的节奏
觉得lua写业务恐怖的，那是因为你们没见过用c写业务的公司[坏笑]
游戏里面用lua是有别的原因
这个当然了，lua在游戏方面应用的时间非常久了
Scala
以Go语言的开发效率能不能代替Erlang呢。
我还是比较喜欢能以开放态度，什么语言都接受的公司，
并发编程的话，我们的路线是Erlang转向Scala,但是Scala学习曲线太高了
框架讨论
说到Scala之后，引起新的问题
我们这边一个老团队开新业务，内部招人，别的团队的人第一句话都是问：还要继续用 scala 吗“？写scala 的人，一个转产品，一个转 leader，没剩下几个了
L: 像以前在亚马逊，服务之间约定好接口，我管你用什么语言，只要满足你对于服务质量的promise就行
T: 问题是，小公司里，如果一个服务没有满足 promise 你怎么办？如果你用了奇怪的语言或者框架，别的人都没法帮忙
T: 我刚帮着折腾了两个月的 akka 和 play 。。。akka 里解决的一个大问题，居然是 log actor 的性能不行，导致内存堆积；这种框架，不碰到坑就天下太平，万一碰到坑，你就只好自求多福
L：小公司从组织架构到基础工具都做不到，所以也只好尽量减少语言栈
G: 看豌豆荚的akka分享，感觉还不错啊
T: 这两天在折腾 sbt 和 maven 的配合问题。。。一把辛酸泪，公司里有两个二进制repo，伤不起；总之一句话，在公司里或团队里，保持技术栈的简单可靠，是一件功德无量的时期。我正在这边推 spring boot，套上一个简单的 http rpc，把其它乱七八糟的底层依赖全干掉，上层业务逻辑爱用啥用啥，基础设施保持统一就行。
L: 之前有人想引入c++，坚决抵制住了
Y: 不搞spark就别scala了
F: 我还是spring webmvc
W: 成功从 Play framework 的 Scala + SBT 栈换到了 Spring boot 的 Java + Maven
S: springboot起码解决了内嵌tomcat的问题？
T: spring boot 解决了“该怎么用 java 代码做这种事情” 的选择问题
Y: sbt 不是Springboot
T: sbt 是 simple build tool
F: scala 可以用 gradle，还是挺舒服的
Y: 我们也刚改了SpringBoot
S: 但是我感觉springboot还要runtime读取jar包 好土，jar包套jar包，我们最近看的 start.spring.org, 里面的各项东西都比较靠谱
W: sbt里引用国内第三方的包时简直要哭死，比如各类SDK（支付、推送、短信等等）
J: 我觉得scala推广最大的阻力其实就是sbt。不知道为啥scala的创始人不好好的用gradle/maven。这可能是java最开始的时候没有内置依赖管理导致的。go如果不赶紧解决依赖管理问题，等社区里出来几个依赖管理的解决方案，就又像java一样开始分裂了。
T: 现在总结出来，凡是版本号在 0.x的，或者最近几个版本之间兼容性差的，都不能用，sbt两条都符合
Z: 哈，上次带josh四处求爷爷告奶奶展示spring boot demo，这下从群里找到组织了[表情] 居然这么多人用的。。
josh上次在沪江分享过
先去脑补一下spring boot
直接springmvc, so easy
业务系统用java 这么呆的语言都成这个样子了，真不知道如果换成scala 会变成啥
现在喜欢上了node.js
想进一步同群专家进一步交流高可用架构，并探讨什么是最好的高可用架构语言的，可回复arch申请进群。由于主群人员长期处于满员状态，为了让更多同行可以参与架构交流，近期开放了一个新的高可用架构群（待冠名），很多排队的朋友喜大普奔，虽然已经快满，不过依然还可以申请加入。
本文编辑TimYang。想阅读更多架构方面内容，可以通过搜索“ArchNotes”或长按下面图片，关注“高可用架构”公众号，获取通往架构师之路的宝贵经验。 转载请注明来自“高可用架构（ArchNotes）”微信公众号。
文章评论