Scala/Golang/Java/Spring boot那些事儿

码农界有个广为人知的笑话

女神:你能让这个论坛的人都吵起来,我今晚就跟你走。

程序员: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

 

未经允许不得转载:氢网 » Scala/Golang/Java/Spring boot那些事儿

支付宝扫码打赏 微信打赏

欢迎点击上方按钮对我打赏

分享到:更多 ()

评论 抢沙发

评论前必须登录!