Hacker News Reader

Comment by ProblemFactory | Hacker News Reader

Go was designed for the above-OS, networked systems programming niche at Google: new database engines, distributed filesystems, web servers (as opposed to web apps), and other similar projects. I would not write a wiki app in it, but certainly the next Apache or Nginx replacement.

And although I haven't tried it out myself yet, it does seem very promising for such use cases. You don't have to "give up" 30 years of existing C code if you are just using it as libraries and OS calls, not rewriting it.

View on HN

> I would not write a wiki app in it, but certainly the next Apache or Nginx replacement.

I wouldn't. Nondeterministic garbage collection in a web server like nginx (as opposed to an application web server like Jetty) makes me very nervous. The HTTP (or pick-your-other-TCP-protocol) lifecycle is well-understood enough that you should be able to handle your own memory management.

There are lots of things in Go I like, but for me they're coupled with questionable abstractions that make it difficult to rationalize over C++.

Actually Go GC is quite easy to control. If you know your butt from your elbow you can write code that doesn't GC at all.

I really don't have a problem with GC though. Its easier to optimise a GC than to fix memory and reference counting bugs. Memory management is not a problem I want to be dealing with after 60-odd years of computers being around.

Garbage collection is not the only way to achieve safe memory management.

Agreed but its the one way which requires little headspace when solving a problem.

I find RTTI to require fairly little cognitive load and I don't find resolving memory ownership to be particularly difficult.

Yuck. RTTI is C++'s goto.

Er, sorry. I didn't proof the past. Meant RAII. My bad.

> Its easier to optimise a GC than to fix memory and reference counting bugs.

I don't agree. If you are competent enough to be needing to write your own web server, memory management should be utterly trivial.

There are many use cases where you do not need to really balance bleeding performance against programmer conveniences. Something like "Apache or nginx" is without question one of them.

Agree with Apache/nginx etc, but that is nowhere anyone needs to piddle around these days.

Except that that's exactly what I was replying to: "Apache or Nginx replacement".

Reply on news.ycombinator.com