大家谈谈Revel和Beego吧 或者其他Go框架

https://github.com/codegangsta/martini 个人比较喜欢简单的框架

revel不错，不过封装的有点多

beego也不错

不用框架也不错。。

比较受不了beego作者那种「我是大牛我要在go圈子先圈个地」的姿态。。而且当时beego的代码相当惨不忍睹。
不过大半年没关注了，现状如何不好评价。

正在用revel，当初选择的时候也很纠结。
我觉得就算大家再怎么比较给你听你也不一定能得到满意答案，还不如你自己用两个框架试试写点东西，然后比较下。
beego由国人开发，可能在你出现问题的时候会支持的比较好。

@ltzliwe 林添置你好

@notedit 我去研究一下 我也喜欢简洁的

@ltzliwe 我试了一下 不用框架写 然后最后就变成自己写框架了

@guotie = =确实都不错 但是说beego不靠谱的人偏多

@kevinv 是的 我就在试着写 在试着beego
revel在公司有点问题 先放着
好就好在中文啊 文档看起来方便
个人比较不喜欢beego那个代码风格。。。

go是用来写服务器、基础设施的，用来写web业务代码，到处是error check累不累啊。

@smalltalk 换到其他语言不是一样要try...except嘛？

不喜欢框架， net/http html/template 自己动手。

@ltzliwe 在写业务代码的时候， 如果存在try catch，通常意味着代码写错了，或者框架选错了。

golang-nuts里关于这个问题有过一个非常好的回复，大意就是Go的标准库已经帮你做好了太多东西，以至于没有必要再选用框架。我是半业余开发者，从go刚推出就开始作为自己的主力语言，最开始的一年多基本上就是在折腾自己的框架，到exp.template推出（也就是现在的template包），基本上就稳定了。url处理是很简单的，template现有的已经很不错了，真正有工作量的部分就是ORM。因此，建议选择一个好的orm，其余部分自己动手。

我也不太喜欢 beego 用法的那个代码风格。

这个 https://github.com/hoisie/web 不错

@smalltalk 但是在go里面返回error的目的包含了平时数据处理的错误以及不可预知的错误。
比如得到一个json字符串，你在unmarshal的时候发现它不符合json的语法，这时候go会返回error，但是其他语言可能就是try catch了。这并不是框架或者代码的问题，当然也可以事先检查，但是比起直接返回error不是会更麻烦？
或者读取一个文件，发现文件不存在，这个步骤肯定是省不了的。只是go把其他语言的一些正常的逻辑判断放在了check error里面了

beego挺垃圾的,作者自我感觉良好,实际上水平不怎么样。

martini

再多的评论也比不了自己动手测试一把

@rwx
@darklowly

第一我的态度很端正，没有你们说的这些什么大牛不大牛，我的出发点一直是想做一些有用的东西让大家玩。从来没有圈地或者自我感觉良好这样的。我的水平确实不是最好的，我做的那些也是自己平时项目中积累的东西，如果你们觉得那些不好我很欢迎你们指出来，欢迎你们指导。

我既然愿意把代码分享出来，就愿意接受大家的批评和指正。如果你们觉得写的比我好，我非常欢迎你们分享出来，这样整个的Go技术圈才会越来越好。

目前beego系统已经被各大公司应用于内部的系统开发，稳定性和性能都得到了考证，当然我们还有很多需要改进的地方，所以你们如果不满意，那么不爽欢迎提出你们的意见。

@astaxie
@rwx
@darklowly

谢大(@astaxie)没有上面说的那样子，估计是在GO编程群里面水的太狠了被T了吧。故而记仇了吧。

@astaxie beego只能说是可以工作,beego用golang来做传统的MVC，感觉路子不对，写出来的代码没有质感。这个是一开始设计上的问题。不是说别人能够马上分享一两段代码纠正的。但凡做过开源的，动不动就喜欢说，有本事你分享段代码来看看啊。

实际上在做开源的时候，很多人都喜欢写出一个东西后就开源出来。这样确实是贡献，但是有没有感觉现在的开源代码质量越来越低了。

像redis这样的项目大家都佩服，你说技术难度，很多做C语言的人都能写出来。但是还是佩服他。因为他写出来的质量很高。代码和设计都很有质感。

同时在golang上包装一层弱框架，想不稳定都难。

@overlords 就你最腹黑

用golang写个流媒体服务器怎么样? 我看golang跟nodejs并发不相上下,但是cpu占用低

@darklowly 其实感觉您修行很深。您也来一发

@darklowly 求点评: http://github.com/sipin/gorazor

@darklowly 基于golang之上的弱框架，想不稳定都难，这个结论你怎么的出来的啊？按照你的逻辑，什么东西都得依赖最原始的包来开发？

第二，传统的MVC我觉得挺好啊，路子对不对，不是你说不对就不对，你写过几行代码啊？如果你觉得路子对的话，可以拿出来一些可行的路子出来呢。

第三，这个开源没有强制别人喜欢不喜欢，有些人就是不喜欢beego的执行方式，完全没问题啊，就喜欢用简单地，例如webgo、martini这样的框架，因为代码就那么几个文件。

比较受不了你说别人一套一套，自己什么屁都不是。

新人表示beego用起来还不错，易上手，文档齐全

@astaxie 做好你自己，让他们喷去吧！

@astaxie 走自己的路，让别人去吹吧！

@astaxie

我觉得一个好的框架，就应该是简约的。写出来的代码有质感的。但是你只看到了稳定性和性能

1 稳定性 当然这个很重要，如果只是弱包装一层，然后说很稳定，试问弱包装一层，怎么才能不稳定？既然弱包装很容易稳定，那么稳定性就不应该是你强调的特性。（我从来没说过要什么从原始开发包写）

2 性能 我不觉得，写几个静态测试，然后测试出框架的性能有任何意义。静态测试高那么一点或者低那么一点点，重要么？

3 我自己也写了一个小框架，我自己还不满意，不敢丢人。我对自己的要求比较高。我上面说过了，做过开源的人，就喜欢动不动就说你拿一行代码来看看啊

4 既然不强制别人喜欢不喜欢，那你说这些干嘛呢，我有不喜欢的权利。你刚好也在说一套做一套。

5 自我感觉，写代码质量比你高，你的代码在我眼里屁也不是。光追求完成功能，没有任何美感（包括代码，包括设计的美感）的代码在我眼里都是垃圾。就好像C语言之父说的, UNIX很简单。但需要有一定天赋的人才能理解这种简单。你的代码缺少这种看似简单东西。

6 随便打开了一个文件 github.com/astaxie/beego/blob/master/router.go 8层嵌套，看的欲望都没有了，哥，你这是在写代码啊? 难怪写稳定，对你来说是一件很重要的事情。

7 我又乱点了一个文件，github.com/astaxie/beego/blob/master/orm/db.go 12层嵌套

8 以上代码我并没有挑选，随机点的。一共点了5个文件，还有一些其他问题。

10 现在，我发现用你现在写代码的模式去写框架，给你谈代码质感，谈简约，还引用了大神的名言是多余的，对不起。

@Wuvist 初略的看了下，我觉得很好呀。

@darklowly beego里面的有的代码让人没有看下去的欲望。
之前在对比revel beego 和 Martini ，看到beego某个入口函数有一千行，然后真心觉得有点

@sillyousu
但是作者不这么认为，他认为，能工作就可以了。代码质量都是浮云，代码美感都是浮云，设计的美感都是浮云。就像我上面说的，我现在明白了，为什么来说他把稳定性看得很重要，因为他写代码的模式，要写稳定真不容易。

我其实很想问其他人, 看到这段代码的感受如何
https://github.com/astaxie/beego/blob/cec151fda71cf6220fcfc9487240989d6dee1f6e/orm/db.go#L801

我也很想问作者, 写出这段代码的感受如何.

@sillyousu

还有这里:
https://github.com/astaxie/beego/blob/14dee37a2159ee9db1770e79ab23651c59797ebc/router.go#L422

上下翻动，还有很多问题。

作为一个刚转web开发的新手，表示beego的API还是比较适合新手入门的，没用过其他框架不好说其他的是否更好用。
不过看了 @darklowly 列出的几个代码段，确实觉得beego在保证稳定性和功能的前提下要关注下代码风格。任何代码从产生的一刻起就会是逐渐劣化的过程，所以才会有敏捷开发提倡的小步前进、不断重构来保持代码质量。

@missdeer 我想说的不仅仅是代码风格, 我想说的是能写出这样的代码, 是在证明我上面说的其他观点。

@darklowly 现在beego能立马着手改进的主要也只有代码风格了，像你说的架构的问题首先意见不能统一其次也不是一时半会儿能改好的。代码风格好，用个可能不是太恰当的比喻，一白遮百丑。

@missdeer 这个其实不是最重要的，如果是简单的设计，简单的实现，代码风格自然就好了，所以代码风格只是表象，核心问题不是这个。

非要一开始搞这么烂，这么复杂，然后花很大精力去解决带来的问题，就好像是捅自己一刀，然后再去伤口，然后伤口缝好了，留下一个丑陋的伤疤，还觉得自己很牛逼，居然缝好了这么难逢的伤口。问题的关键是为什么要捅自己一刀？

@darklowly 对，我们的目的是一样的。我的意思是如果一个人写代码时刻注意着要写得风格良好，那会逼得他不得不有精简的设计和实现，才能写得好看。你是要求从内而外的因为核心好所以全都好，我是从外到内加了约束条件首先让面子好看再让里子也不至于偏差得远了。我觉得相对而言你的做法可能对人员水平要求更高些。

https://github.com/astaxie/beego/blob/cec151fda71cf6220fcfc9487240989d6dee1f6e/orm/db.go#L801

我虽然是go新手，但是beego的这里太倒胃口了。这是写软件的人自己的问题了，多层嵌套本来就是大忌。

@missdeer 要知道这里不是所谓的代码风格能够解决的问题

@Bluecoda 这个问题我在41楼已经说过了。

@Bluecoda 看第二个连接的历史记录啊。已经是修改+重构很多次的了。是完全没有意向去化简。用你的话说，是写代码的人的问题

比较不能接受的是beego的api变动太频繁，几乎每次升级都有点儿破坏性，都stable v1了，还这样

其实连beego代码都没看，看完文档都没欲望了，各种原始的设计，好像一个国产php框架

@darklowly "如果是简单的设计，简单的实现，代码风格自然就好了"，这点我在实现gorazor的时候很有体会。设计是很重要的，razor模板本身的优雅设计决定了我可以简单的实现它，并且模板嵌套几乎可以“自动实现”。

@Wuvist 如果有机会我会把你的razor用到自己的项目中的。

期待楼上某些大神给我们一个更好的框架来学习。

我能说我看到了一群蝼蚁吗？

@darklowly，相比于做出这样一个产品的作者来说，你就是个垃圾。

@sugelawa 你懂技术么?垃圾

我的目的是在这找到一个可以上手的框架看看学习， 结果看到毫无意义的骂战。

@hydyy 是的
我的本意也是
现在一年都快过去了
我建议可以自己实现一个小框架比较好
我现在觉得那些大框架很多功能用不上没必要。。。

刚发现这么一个好玩的贴子，诸神骂战，看着有点小激动

我滴天吆，还有这么好玩一贴啊。

@darklowly 27楼为什么没有 9，这让处女座怎么办啊，再补一条吧。

ps: 写得不错，不过质感这个词，还真难理解。

很多国内的开源，只是说把代码放出来了而已，没几个人能开得懂，更别提给你提交代码了。beego真心不咱样，试图把其它语言的框架换做语言来写而已。并没有发挥出GO自己应有的特点。

beego代码没法看啊

别喷了都，程序员什么时候都变成这样了，做着婊子骂街的事，聊的是艺术家的感受。人楼主只是求推荐一个go框架，不管你是大神还是菜鸟，能推荐就推荐，不想推荐就别起反作用，谁都从菜鸟过来的，别打击人家的积极性。
如果你是大神，公司开发进度又完成了，完全可以利用闲暇时间，在自己喜欢又擅长的领域做做贡献，分享经验，何乐而不为。
BEEGO好不好我不评价，但是确实我学GO的时候帮到了我，很感谢作者的贡献。
而我看你们喷了几十层楼，屁都没学着。

上面吵的人，talk is cheep, show me the code

我同意@darklowly的看法，代码质量确实不堪，希望作者能听取改正。当然既然是开源项目，应当感谢作者@astaxie的无私奉献。一个系统有问题在所难免，大家除了提出意见，有能力和时间精力的也应该作点贡献。一个好的开源系统难以以一已之力就能做好的，大伙给点耐心和奉献点什么吧

@haha1903 9 就脏话，略过

各路大神，结论呢？

@julor 结论就是放弃 beego,试试别吧

@somni 比如呢？哪些值得一试？

NOTE: The martini framework is no longer maintained.

我只是来看 revel 和 beego 的比较，似乎没人愿意认真回答题主，竟然骂开了,go 的社区行为准则我这里贴一下先：
1. Treat everyone with respect and kindness.
2. Be thoughtful in how you communicate.
3. Don ’ t be destructive or inflammatory.

@sillydong 这话就是 u can u up ?呵呵呵

挖了个坟，越看越有意思

@qunxyz 同意
作为一个新手，要感谢两位
@darklowly
@astaxie

每个人都不是完美的。

有讨论，才能学到更多。

挖坟。路人。但是读完评论发现谢 XX 是在是个渣渣！ darklowly 说的全在点子上，除了一开始无理由的批评之外。
谢 XX 说了些啥？“你写过几行代码啊？”这么 low 的话也拿出来说。。。

咋吵起来了。。。真是的。。。人家写个开源的东西放那里，你爱用不用。。就这么简单的事情。。。

敢开源就有敢接收被骂的准备呀~

结果呢?

beego 好坏与否，作者毕竟耗费了心力。提意见应该注意方式方法，又不是仇人，何必咄咄逼人呢

同意 @darklowly 的观点，以 Spring 的代码为例，看起来真的是赏心悦目。

最讨厌这些渣渣，自诩牛逼，代码有质感的你给我贴出来啥是质感，让小弟们瞧瞧，觉得不好写一个框架处理，一点贡献没有就是逼逼叨

然后并没有什么结论，我等新人只能看看热闹。

@crazyjin 确实没有用 beego 啊，这里的问题是谈谈 beego，所以就谈了 beego 。和用不用有什么关系？跑题了吧？