go vs node
发布于 3 年前 作者 i5ting 8690 次浏览 来自 分享

知乎上扯了会蛋。《对于前端来说后端语言是学自己不感兴趣的 Node.js，还是感兴趣的 Go？》https://www.zhihu.com/question/447669828/answer/1793911279

go

package main

import (
	xhttp "github.com/goclub/http"
	"log"
	"net/http"
)

func main() {
	r := xhttp.NewRouter(xhttp.RouterOption{})
	r.HandleFunc(xhttp.Pattern{xhttp.GET, "/"}, func(c *xhttp.Context) error{
		return c.Bytes([]byte("hello, " + c.Request.URL.Path))
	})
	log.Print(http.ListenAndServe(":1111", r))
}

node

var xhttp = require('.');

function main() {
    var r = xhttp.NewRouter(RouterOption={})
    r.HandleFunc(Pattern={verb: 'GET', router:"/"}, function(ctx) {
        return ctx.res.end("hello, " + ctx.req.url)
    })
    xhttp.start()
}

main()

看了看，还是更喜欢node。哈哈哈

32 回复
2

当然是熟悉的语言，node和go都是我用过的最香的服务端开发技术，两个我都要

闲的

4

共同点是高并发吹得厉害，都是学完了找不到工作的语言 因为高并发只有面试的时侯会用一下，面试完了就没用了，百无一用是高并发

@yakczh 来蚂蚁或淘系前端架构组，如果能力及格，欢迎联系苏千或张挺

@yakczh 各种算法题也是，还有各种听上去高大上的技术名词

MIT的分布式课程里面也用上了go

1

@i5ting no 996 no福报

@yakczh 还是有点用的，这俩基本脑袋正常一写出来就是自带高并发的，，

go爽在go goroutine和channel， node爽在promise，async，await 和steam api。其他感觉本来也都差不多了

@yakczh 都是这样的，在实际场景中，能接触到高并发的人还是比较少的，但是这是面试的经典问题了 还有算法也一样QAQ

对于写C++的同学来说，能用go已经很幸福了，😄

都想要，哈哈

2

86eb2e4504187e1bb92169a61f224a0d.jpg 写golang容易中病毒，还是写nodejs比较安全

进阿里得达到什么水平？目前是做后端的，前端还只是能用纯html css画页面

@qian-ryan 死月的前端估计和你差不多。要你的node能达到什么程度

@yakczh 是的，真正需要处理高并发的项目不是很多

@i5ting 😂 死月表示不服

@i5ting node做了两年外包，express和koa都能熟练使用，但对于node内部实现原理还是不懂。底层源代码还没到那级别，这还需要一段时间积累。今年是打算把前端搞定，然后再去杠服务器和node底层源码

1

我知道用Node.js写单元测试很爽

1

我知道用golang解析json烦得一逼

不喜欢go的两个点： 1、json对象处理比较麻烦 2、过多的error处理

1

@dingyuanwu go最不行的地方就是内存，占着茅坑不拉屎，明明已经垃圾回收了就是不把空闲的内存还给系统

全要了。nodejs写一些工具包，自动化，爬虫，桌面应用，都是不错的，大项目不喜欢用ts，js弱类型写法花样多，个人认为不适合大型多人合作开发。 golang协程配上通道，太强了，执行效率完胜nodejs，简明的语法（大道至简），不过糟糕的iferr看着让人头疼。

@zengming00 😄 这个我倒不是很清楚，但是有这个问题的话，go的社区应该有提供对应的解决方案，可以去看下

@pretty-foam 是的，err的处理是很恶心，关键是你不处理还真就不行

1

@dingyuanwu go提供的api最多只能强制执行下gc，哪怕是调用debug.FreeOSMemory()这样强势的API它也只是“attempt”而已 ，go的理由是为了更高效的利用内存，垃圾是回收了，但是内存暂时先不还给系统，我在128M的路由器上运行了一个go语言写的上网工具，压力一大就崩了，原因就是内存不够，内存泄漏肯定是不存在的，因为你去看gc日志它确实回收了内存，他说的实际占用也很小，但是htop看到内存占用却很高，你有空闲内存你到是利用起来呀，还老是向系统要新的内存，结果就是OOM了

在服务器环境动不动就几个G的内存，占用个几十上百M都可以认为是正常的，除非真的有内存泄漏了，否则很难达到OOM，我之前做过一个单机1万5并发的也没有出现，可能在几十上百M空闲内存时它就能利用起来，在小内存的路由器这种机制几乎就是无效的，GO语言在一些方面太过于强硬，哪都好，就是内存很神奇

1

@pretty-foam "golang协程配上通道" 这只是挖坑的开始 通道只是封装的数据结构 协程对应着流程控制的代码 通常是用代码来操作数据结构 在传统的多线程场景下 码农可以精确地控制线程同步，可以手动调整线程nice级别 可以taskset 到指定cpu 而golang的协和的调度完全是被golang运行时接管的 码农用记事本写个helloworld跑一下，哇！并发真高 但是到了实际复杂的业务场景的时后，究竟哪个gorutine对应到哪个thread，分配到哪个cpu 码农是完全抓瞎的 通道变成黑盒子，码农只能看到两端的数据和deadlock 而系统调度策略只关注系统资源/io读写通用的规则 如果一个需求场景，系统调度策略跟业务相关，或者系统调度内存很充足，但是OOM当机了 码农只能看着golang运行时默默发呆

golang属于初期写helloworld很容易，写着写着然后发现越到后面坑越来越多，最后掉进坑里根本爬不出来，彻底绝望的那种坑语言

“golang协程配上通道“带来的好处就是高并发，而对应的代价是失去调度控制带来的调试困境和成百上千的协程内存栈的消耗 只是golang推广的时候只说好处，不说代价 前面已经说了，高并发的需求只在面试的时侯吹牛皮有用，实际业务没有多少是真要高并发的 实际项目中真正的需求是代码的可维护性 就是老板刚劝退了一个35岁不愿意免费加班的旧码农，新招了一个25岁愿意免费加班的新码农 新码农接手原来的代码，老板指着代码说说这里这里给我改成我想要的结果，然后新码农上手立马就能改了 ，比如现在流行的低代码平台

@yakczh 其实还是由于go语言太过于强硬，这个调度问题和我最不满意的内存控制问题其实都是runtime导致的，如果go能提供更多的控制权一切都能变得美好起来

go语言是虽然是开源的，这样的控制权需求肯定是能通过改它源代码实现的，但是像我们这种菜鸡不一定有这能力去改它底层

照这样看, go不适合我. 看到内存不还给系统的, 就郁闷, 还有java也是这样.

@zengming00 你可以试试Rust

@leizongmin rust学起来挺费劲，rust静态编译做得不如go，rust编译速度极其缓慢，由于openwrt路由器本身自带lua，我已经用lua实现了功能，效果很不错，lua吃cpu的地方用c语言实现原生模块也很简单

@zengming00 rust要写复杂程序才能体现出优越性

回到顶部