golang值得购买吗,golang有什么优势

本文目录一览：

• 1、使用Go 语言开发大型 MMORPG 游戏服务器怎么样
• 2、golang适合做web开发吗
• 3、萌新小前端web想入手后台语言，java，php，golang这三种该选哪个
• 4、为什么我全力推荐Golang

使用Go 语言开发大型 MMORPG 游戏服务器怎么样

1.为什么golang的开发效率高？

golang是一编译型的强类型语言，它在开发上的高效率主要来自于后发优势，不用考虑旧有恶心的历史，又有一个较高的工程视角。良好的避免了程序员因为“ { 需不需要独占一行 ”这种革命问题打架，也解决了一部分趁编译时间找产品妹妹搭讪的阶级敌人。

它有自己的包管理机制，工具链成熟，从开发、调试到发布都很简单方便；

有反向接口、defer、coroutine等大量的syntactic sugar；

编译速度快，因为是强类型语言又有gc，只要通过编译，非业务毛病就很少了；

它在语法级别上支持了goroutine，这是大家说到最多的内容，这里重点提一下。首先，coroutine并不稀罕，语言并不能超越硬件、操作系统实现神乎其神的功能。golang可以做到事情，其他语言也可以做到，譬如c++，在boost库里面自己就有的coroutine实现（当然用起来跟其他boost库一样恶心）。golang做的事情，是把这一套东西的使用过程简化了，并且提供了一套channel的通信模式，使得程序员可以忽略诸如死锁等问题。

goroutine的目的是描述并发编程模型。并发与并行不同，它并不需要多核的硬件支持，它不是一种物理运行状态，而是一种程序逻辑流程。它的主要目的不是利用多核提高运行效率，而是提供一种更容易理解、不容易出错的语言来描述问题。

实际上golang默认就是运行在单OS进程上面的，通过指定环境变量GOMAXPROCS才能转身跑在多OS进程上面。有人提到了网易的pomelo，开源本来是一件很不错的事情，但是基于自己对callback hell的偏见，我一直持有这种态度：敢用nodejs写大规模游戏服务器的人，都是真正的勇士 : ) 。

2、Erlang与Golang的coroutine有啥区别，coroutine是啥？

coroutine本质上是语言开发者自己实现的、处于user space内的线程，无论是erlang、还是golang都是这样。需要解决没有时钟中断；碰着阻塞式i\o，整个进程都会被操作系统主动挂起；需要自己拥有调度控制能力（放在并行环境下面还是挺麻烦的一件事）等等问题。那为啥要废老大的劲自己做一套线程放user space里面呢？

并发是服务器语言必须要解决的问题；

system space的进程还有线程调度都太慢了、占用的空间也太大了。

把线程放到user space的可以避免了陷入system call进行上下文切换以及高速缓冲更新，线程本身以及切换等操作可以做得非常的轻量。这也就是golang这类语言反复提及的超高并发能力，分分钟给你开上几千个线程不费力。

不同的是，golang的并发调度在i/o等易发阻塞的时候才会发生，一般是内封在库函数内；erlang则更夸张，对每个coroutine维持一个计数器，常用语句都会导致这个计数器进行reduction，一旦到点，立即切换调度函数。

中断介入程度的不同，导致erlang看上去拥有了preemptive scheduling的能力，而golang则是cooperative shceduling的。golang一旦写出纯计算死循环，进程内所有会话必死无疑；要有大计算量少i\o的函数还得自己主动叫runtime.Sched()来进行调度切换。

3、golang的运行效率怎么样？

我是相当反感所谓的ping\pong式benchmark，运行效率需要放到具体的工作环境下面考虑。

首先，它再快也是快不过c的，毕竟底下做了那么多工作，又有调度，又有gc什么的。那为什么在那些benchmark里面，golang、nodejs、erlang的响应效率看上去那么优秀呢，响应快，并发强？并发能力强的原因上面已经提到了，响应快是因为大量非阻塞式i\o操作出现的原因。这一点c也可以做到，并且能力更强，但是得多写不少优质代码。

然后，针对游戏服务器这种高实时性的运行环境，GC所造成的跳帧问题确实比较麻烦，前面的大神 @达达 有比较详细的论述和缓解方案，就不累述了 。随着golang的持续开发，相信应该会有非常大的改进。一是屏蔽内存操作是现代语言的大势所趋，它肯定是需要被实现的；二是GC算法已经相当的成熟，效率勉勉强强过得去；三是可以通过incremental的操作来均摊cpu消耗。

用这一点点效率损失换取一个更高的生产能力是不是值得呢？我觉得是值得的，硬件已经很便宜了，人生苦短，让自己的生活更轻松一点吧: )。

4、基于以上的论述，我认为采用go进行小范围的MMORPG开发是可行的。

golang适合做web开发吗

适合。

框架足够成熟了 A Survey of 5 Go Web Frameworks

小型项目你甚至不用框架，用net/http http – The Go Programming Language

常用库也成熟了 Top – Go Search

golang的web后端即使不concurrent也比php，ruby，python快很多很多

golang里用concurrent真的非常方便，非常非常快，超大web项目golang scale成本低

如果你想，golang的部署可以比php更方便，使用go get和http.ServeAndListen()可以不用nginx和

apache

对于文件改动重新编译其实并不是大问题，看pilu/fresh ∙ GitHub，其实你自己写shell脚本（也可以

直接用go写，因为它本身就是系统语言）监控文件系统改动然后自动重新build，即使是C/C++的项

目这也不是大问题，人们不用C/C++写web是因为它们不是写web app的最佳选择

golang写的代码编译通过后，要比scripting language鲁棒，因为go compiler强制一些最佳实践

所以如果你熟悉go或者愿意投资时间，这是一种很值得用的语言，如果你不熟悉而且项目周期很紧，还是

建议你用自己最熟悉的语言，学go本身需要花时间的。

我最近一个web项目是用Gorilla写的，也是边学边做 Gorilla, the golang web toolkit；这个Go by

Example 挺有用

萌新小前端web想入手后台语言，java，php，golang这三种该选哪个

Java应该应用最广，也就是江湖中说的“稳如狗”。语言干净而啰嗦了点吧。生态丰富功能齐全所以学习时间花费不菲。

PHP是专注于Web应用开发的语言，已经很规范了，应用也很广。好的PHP程序员不多，野球型PHP程序员太多。

Java和PHP的市场需求量都很大。掌握一个都不愁没机会。Go也不错，但市场份额还有待时日。

为什么我全力推荐Golang

讨论哪个语言更好，就像在争论姚明和刘翔谁是更优秀的运动员。因为各自的坐标象限不同，常常会陷入一个难有结论怪圈。

所以本文绝不是在说Golang是比其他语言更好的语言。Golang只是最值得推荐的语言，尤其适合快速成长中的后端研发团队。

我推荐Golang的主要理由，并不是技术性的要素：不是他的高并发能力，编译的速度，跨平台能力，内存效率，也不是社区的活跃度等等。

事实上，创业之后，或者说成为一个技术管理者之后，技术优点就已经不再是我推荐任何一种语言的关键因素了。

因为，对于一个研发团队来说，项目成败的关键因素是：成本、质量和时间！

1、人力资源的成本

人力资源是研发团队最重要的资源，也是唯一的资源。其成本不仅仅是团队要支付的薪资代价。也包括获得资源的难易程度，例如招聘和培训的速度。以及维持资源，也就是保持员工满意度或者说士气的代价，也就是管理成本。（上述成本不仅指钱，时间也是非常昂贵的成本）

Golang有一系列特点，使它既容易上手，又易于维护。Golang可以让初阶和中阶工程师，经过少许培训，就写出相当不错的代码。直接点说，一票1-2年经验少许灵性的年轻工程师转Golang，只要少许指导，很快就可以写出高并发高负载能力生产级别的代码，而且质量相当有保证。而同样的工程，如果用C++或java等语言，则需要至少3-5年经验的工程师来完成，同时质量还是要让人担心。

那么，对于团队特别是成长型的或创业团队来说，现在有Golang这样一种语言，可以让大量初阶和中级工程师承担主要开发工作，还能保证相当优秀的结果，从资金成本和时间成本控制的角度，简直就是美梦成真。

2、项目研发的效率

说到高并发高负载，让我不能不想起nginx。nginx在2004年从web server领域横空出世，所向披靡。精巧严谨易于维护和扩展的代码结构，也是教科书级别的。

但是要知道，一个用C写出一个nginx，是需要世界上最优秀的工程师的。这样的工程师，不仅团队里面没有，连遇到一个都很难。

可现在，我再告诉你，一个使用Golang的中级工程师，就已经可以写出性能与nginx相近的高并发高负载应用。而且不仅性能相近，而且需要的代码行数和开发时间也短很多。这对于团队成员来说，这很可能是决定生死存亡还是走上人生巅峰的区别。

—

总之：

对于团队管理者来说，Golang可以让团队用更低的人力成本，更快的速度，更高的质量，完成项目研发。

对于工程师来说，Golang可以让人有更多的时间去思考和生活。

所以，我推荐Golang。