46 ms·

Go was designed for the above-OS, networked systems programming niche at Google: new database engines, distributed filesystems, web servers (as opposed to web a

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.

eropple 14y ago
> 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++.
- meaty 14y ago
  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.
  - pcwalton 14y ago
    Garbage collection is not the only way to achieve safe memory management.
    - meaty 14y ago
      Agreed but its the one way which requires little headspace when solving a problem.
      - eropple 14y ago
        I find RTTI to require fairly little cognitive load and I don't find resolving memory ownership to be particularly difficult.
        meaty 14y ago
        Yuck. RTTI is C++'s goto.
        eropple 14y ago
        Er, sorry. I didn't proof the past. Meant RAII. My bad.
  - eropple 14y ago
    > 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.
    - meaty 14y ago
      Agree with Apache/nginx etc, but that is nowhere anyone needs to piddle around these days.
      - eropple 14y ago
        Except that that's exactly what I was replying to: "Apache or Nginx replacement".

eropple 14y ago

> 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++.

meaty 14y ago
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.
- pcwalton 14y ago
  Garbage collection is not the only way to achieve safe memory management.
  - meaty 14y ago
    Agreed but its the one way which requires little headspace when solving a problem.
    - eropple 14y ago
      I find RTTI to require fairly little cognitive load and I don't find resolving memory ownership to be particularly difficult.
      - meaty 14y ago
        Yuck. RTTI is C++'s goto.
        eropple 14y ago
        Er, sorry. I didn't proof the past. Meant RAII. My bad.
- eropple 14y ago
  > 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.
  - meaty 14y ago
    Agree with Apache/nginx etc, but that is nowhere anyone needs to piddle around these days.
    - eropple 14y ago
      Except that that's exactly what I was replying to: "Apache or Nginx replacement".