go语言编程许式伟百度云 go编程语言 pdf

许式伟的个人简介

许式伟,七牛云存储CEO。ECUG社区发起人,是国内Go语言实践圈子公认的Go语言专家,并著有《Go语言编程》。超过10年互联网从业经验,曾在金山、盛大事技术研究方面的工作,是WPS2005的首席架构师。2011年创办七牛云存储,成功打造了全新的公有云存储服务。

10年的大关网站建设经验,针对设计、前端、开发、售后、文案、推广等六对一服务,响应快,48小时及时工作处理。成都全网营销推广的优势是能够根据用户设备显示端的尺寸不同,自动调整大关建站的显示方式,使网站能够适用不同显示终端,在浏览器中调整网站的宽度,无论在任何一种浏览器上浏览网站,都能展现优雅布局与设计,从而大程度地提升浏览体验。创新互联从事“大关网站设计”,“大关网站推广”以来,每个客户项目都认真落实执行。

《Go语言程序设计》epub下载在线阅读,求百度网盘云资源

《Go 语言程序设计》(Mark Summerfield)电子书网盘下载免费在线阅读

资源链接:

链接:

提取码:br6t  

书名:Go 语言程序设计

作者:Mark Summerfield

译者:许式伟

豆瓣评分:6.9

出版社:人民邮电出版社

出版年份:2013-8-1

页数:354

内容简介:

国外最经典的Go语言著作,Go语言编程的先驱者Mark Summerfield的实践经验总结。

这是一本Go语言实战指南,帮你了解Go语言,按Go语言的方式思考,以及使用Go语言来编写高性能软件。

作者展示了如何编写充分利用Go语言突破性的特性和惯用法的代码,以及Go语言在其他语言之上所做的改进,并着重强调了Go语言的关键创新。

注重实践教学,每章都提供了多个经过精心设计的代码示例。

由国内第一个核心服务完全采用Go语言实现的团队——七牛团队核心成员翻译。

作者简介:

Mark Summerfield Qtrac公司创始人,独立的培训讲师、顾问、技术编辑,Go、Python、C++、Qt和PyQt方面的技术作家。他的著作包括Rapid GUI Programming with Python and Qt、C++ GUI Programming with Qt 4(与Jasmin Blanchette合著)、Programming in Python 3和Advanced Qt Programming等。

许式伟——七牛云存储CEO,开源爱好者,发布过十余个C++开源项目,拥有超过15年的C/C++开发经验。

吕桂华——七牛云存储联合创始人,拥有十余年的C/C++大型项目开发经验,也曾在Java和.NET平台上探索多年。

徐 立——七牛云存储首席布道师,前盛大创新院高级研究员。

何李石——七牛云存储布道师。

七牛云存储技术团队是国内第一个核心服务完全采用Go语言实现的团队。

《Go语言编程》pdf下载在线阅读,求百度网盘云资源

《Go语言编程》(许式伟)电子书网盘下载免费在线阅读

链接:

提取码:j0if

书名:Go语言编程

作者:许式伟

豆瓣评分:7.1

出版社:人民邮电出版社

出版年份:2012-8

页数:300

内容简介:

这本书从整体的写作风格来说,会以介绍 Go 语言特性为主,示例则尽量采用作者平常的实践,而不是一个没有太大实际意义的语法示范样例。

本书作者背景极强,许式伟为原金山WPS首席架构师、曾是盛大创新院研究员,目前是国内Go语言实践圈子公认的Go语言专家。参与本书写作的几位作者都是实际用Go语言开发的项目的开发人员,有较强的实战经验。

本书以介绍Go语言特性为主,示例则尽量采用作者开发团队平常的实践,内容涉及内存管理(堆和栈)、错误处理、OOP、并发编程等关键话题。 这本书面向的读者是所有打算用Go语言的开发者,主要包括目前使用C、C++、Java、C#的开发人员,甚至一些Python、PHP开发人员也可能转为 Go 程序员。

作者简介:

许式伟

七牛云存储CEO,曾任盛大创新院资深研究员、金山软件技术总监、WPS Office 2005首席架构师。开源爱好者,发布过包括WINX、TPL等十余个C++开源项目,拥有超过15年的C/C++开发经验。在接触Go语言后即可被其大道至简、少即是多的设计哲学所倾倒。七牛云存储是国内第一个吃螃蟹的团队,核心服务完全采用Go语言实现。

吕桂华

七牛云存储联合创始人,曾在金山软件、盛大游戏等公司担任架构师和部门经理等职务,在企业级系统和大型网游平台领域有较多涉猎。拥有十余年的C/C++大型项目开发经验,也曾在Java和.NET平台上探索多年。同样被Go语言的魅力所吸引而不可自拔,希望能为推广这门优秀的语言尽自己的绵薄之力。

我为什么从python转向go

坦白的讲,在一帮python用户面前讲为什么放弃python转而用go其实是一件压力蛮大的事情,语言之争就跟vim和emacs之争一样,是

一个永恒的无解话题,稍微不注意就可能导致粉丝强烈地反击。所以我只会从我们项目实际情况出发,来讲讲为什么我最终选择了go。

为什么放弃python

首先,我其实得说说为什么我们会选择python。在我加入企业快盘团队之前,整个项目包括更早的金山快盘都是采用python进行开发的。至于为

什么这么选择,当时的架构师葱头告诉我,主要是因为python上手简单,开发迅速。对于团队里面大部分完全没服务端开发经验的同学来说,python真

的是一个很好的选择。

python的简单高效,我是深有体会的。当时私有云项目也就几个程序员,但是我们要服务多家大型企业,进行定制化的开发,多亏了python,我们才能快速出活。后来企业快盘挂掉之后,我们启动轻办公项目,自然也使用python进行了原始版本的构建。

python虽然很强大,但我们在使用的时候也碰到了一些问题,主要由如下几个方面:

动态语言

python是一门动态强类型语言。但是,仍然可能出现int + string这样的运行时错误,因为对于一个变量,在写代码的时候,我们有时候很容易就忘记这个变量到底是啥类型的了。

在python里面,可以允许同名函数的出现,后一个函数会覆盖前一个函数,有一次我们系统一个很严重的错误就是因为这个导致的。

上面说到的这些,静态语言在编译的时候就能帮我们检测出来,而不需要等到运行时出问题才知道。虽然我们有很完善的测试用例,但总有case遗漏的情况。所以每次出现运行时错误,我心里都想着如果能在编译的时候就发现该多好。

性能

其实这个一直是很多人吐槽python的地方,但python有它适合干的事情,硬是要用python进行一些高性能模块的开发,那也有点难为它了。

python的GIL导致无法真正的多线程,大家可能会说我用多进程不就完了。但如果一些计算需要涉及到多进程交互,进程之间的通讯开销也是不得不考虑的。

无状态的分布式处理使用多进程很方便,譬如处理http请求,我们就是在nginx后面挂载了200多个django server来处理http的,但这么多个进程自然导致整体机器负载偏高。

但即使我们使用了多个django进程来处理http请求,对于一些超大量请求,python仍然处理不过来。所以我们使用openresty,将高频次的http请求使用lua来实现。可这样又导致使用两种开发语言,而且一些逻辑还得写两份不同的代码。

同步网络模型

django的网络是同步阻塞的,也就是说,如果我们需要访问外部的一个服务,在等待结果返回这段时间,django不能处理任何其他的逻辑(当然,多线程的除外)。如果访问外部服务需要很长时间,那就意味着我们的整个服务几乎在很长一段时间完全不可用。

为了解决这个问题,我们只能不断的多开django进程,同时需要保证所有服务都能快速的处理响应,但想想这其实是一件很不靠谱的事情。

异步网络模型

tornado的网络模型是异步的,这意味着它不会出现django那样因为外部服务不可用导致这个服务无法响应的问题。话说,比起django,我可是非常喜欢tornado的,小巧简单,以前还写过几篇深入剖析tornado的文章了。

虽然tornado是异步的,但是python的mysql库都不支持异步,这也就意味着如果我们在tornado里面访问数据库,我们仍然可能面临因为数据库问题造成的整个服务不可用。

其实异步模型最大的问题在于代码逻辑的割裂,因为是事件触发的,所以我们都是通过callback进行相关处理,于是代码里面就经常出现干一件事情,传一个callback,然后callback里面又传callback的情况,这样的结果就是整个代码逻辑非常混乱。

python没有原生的协程支持,虽然可以通过gevent,greenlet这种的上patch方式来支持协程,但毕竟更改了python源码。另

外,python的yield也可以进行简单的协程模拟,但毕竟不能跨堆栈,局限性很大,不知道3.x的版本有没有改进。

开发运维部署

当我第一次使用python开发项目,我是没成功安装上项目需要的包的,光安装成功mysql库就弄了很久。后来,是一位同事将他整个python目录打包给我用,我才能正常的将项目跑起来。话说,现在有了docker,是多么让人幸福的一件事情。

而部署python服务的时候,我们需要在服务器上面安装一堆的包,光是这一点就让人很麻烦,虽然可以通过puppet,salt这些自动化工具解决部署问题,但相比而言,静态编译语言只用扔一个二进制文件,可就方便太多了。

代码失控

python非常灵活简单,写c几十行代码才能搞定的功能,python一行代码没准就能解决。但是太简单,反而导致很多同学无法对代码进行深层次的思

考,对整个架构进行细致的考量。来了一个需求,啪啪啪,键盘敲完开速实现,结果就是代码越来越混乱,最终导致了整个项目代码失控。

虽然这也有我们自身的原因,譬如没好的代码review机制,没有好的项目规范,但个人感觉,如果一个程序员没经过良好的编码训练,用python很容易就写出烂的代码,因为太自由了。

当然,我这里并不是说用python无法进行大型项目的开发,豆瓣,dropbox都是很好的例子,只是在我们项目中,我们的python代码失控了。

上面提到的都是我们在实际项目中使用python遇到的问题,虽然最终都解决了,但是让我愈发的觉得,随着项目复杂度的增大,流量性能压力的增大,python并不是一个很好的选择。

为什么选择go

说完了python,现在来说说为什么我们选择go。其实除了python,我们也有其他的选择,java,php,lua(openresty),但最终我们选择了go。

虽然java和php都是最好的编程语言(大家都这么争的),但我更倾向一门更简单的语言。而openresty,虽然性能强悍,但lua仍然是动

态语言,也会碰到前面说的动态语言一些问题。最后,前金山许式伟用的go,前快盘架构师葱头也用的go,所以我们很自然地选择了go。

go并不是完美,一堆值得我们吐槽的地方。

error,好吧,如果有语言洁癖的同学可能真的受不了go的语法,尤其是约定的最后一个返回值是error。项目里面经常会充斥这样的代码:

if _, err := w.Write(data1); err != nil {

returun err

}

if _, err := w.Write(data2); err != nil {

returun err

}

难怪有个梗是对于一个需求,java的程序员在写配置的时候,go程序员已经写了大部分代码,但是当java的程序员写完的时候,go程序员还在写err != nil。

这方面,errors-are-values倒是推荐了一个不错的解决方案。

包管理,go的包管理太弱了,只有一个go

get,也就是如果不小心更新了一个外部库,很有可能就导致现有的代码编译不过了。虽然已经有很多开源方案,譬如godep以及现在才出来的gb等,但毕

竟不是官方的。貌似google也是通过vendor机制来管理第三方库的。希望go 1.5或者之后的版本能好好处理下这个问题。

GC,java的GC发展20年了,go才这么点时间,gc铁定不完善。所以我们仍然不能随心所欲的写代码,不然在大请求量下面gc可能会卡顿整个服务。所以有时候,该用对象池,内存池的一定要用,虽然代码丑了点,但好歹性能上去了。

泛型,虽然go有inteface,但泛型的缺失会让我们在实现一个功能的时候写大量的重复代码,譬如int32和int64类型的sort,我们

得为分别写两套代码,好冗余。go 1.4之后有了go

generate的支持,但这种的仍然需要自己根据go的AST库来手动写相关的parser,难度也挺大的。虽然也有很多开源的generate实现,

但毕竟不是官方的。

当然还有很多值得吐槽的地方,就不一一列举了,但是go仍旧有它的优势。

静态语言,强类型。静态编译能帮我们检查出来大量的错误,go的强类型甚至变态到不支持隐式的类型转换。虽然写代码感觉很别扭,但减少了犯错的可能。

gofmt,应该这是我知道的第一个官方提供统一格式化代码工具的语言了。有了gofmt,大家的代码长一个样了,也就没有花括号到底放到结尾还是新开一行这种蛋疼的代码风格讨论了。因为大家的代码风格一样,所以看go的代码很容易。

天生的并行支持,因为goroutine以及channel,用go写分布式应用,写并发程序异常的容易。没有了蛋疼的callback导致的代码逻辑割裂,代码逻辑都是顺序的。

性能,go的性能可能赶不上c,c++以及openresty,但真的也挺强悍的。在我们的项目中,现在单机就部署了一个go的进程,就完全能够胜任以前200个python进程干的事情,而且CPU和MEM占用更低。

运维部署,直接编译成二进制,扔到服务器上面就成,比python需要安装一堆的环境那是简单的太多了。当然,如果有cgo,我们也需要将对应的动态库给扔过去。

开发效率,虽然go是静态语言,但我个人感觉开发效率真的挺高,直觉上面跟python不相上下。对于我个人来说,最好的例子就是我用go快速开

发了非常多的开源组件,譬如ledisdb,go-mysql等,而这些最开始的版本都是在很短的时间里面完成的。对于我们项目来说,我们也是用go在一

个月就重构完成了第一个版本,并发布。


分享题目:go语言编程许式伟百度云 go编程语言 pdf
网页链接:http://azwzsj.com/article/doghchh.html