5 ms·

We definitely made a mistake at launch using the term "systems programming", because people automatically think of operating systems. What we meant were the kin

by enneff 13y ago

We definitely made a mistake at launch using the term "systems programming", because people automatically think of operating systems. What we meant were the kind of systems we build at google. Some of the examples in the blog post are "systems programming" in the same sense. So we are pleased to see Go being used for the job it was designed for, but we are also happy to see that Go has a broader appeal.

millstone 13y ago
You don't build operating systems at Google?
- enneff 13y ago
  Well, we have Android and ChromeOS, which are both Linux. While we do have a lot of people doing Linux kernel work, I'm not aware of any "green field" operating systems being built at Google. (Although I wouldn't be surprised to be wrong here.) Most of the software we build at Google are server processes that talk to other server processes. Go was designed primarily for this role, but it is obviously useful for a lot more.
chetanahuja 13y ago
Well, I would argue that there's a level between "db replication infrastructure" type projects and OS kernels. That is the space occupied by things like database engines (everything from BigTable and descendants to Oracle), distributed storage engines (GFS and descendants) etc. I don't think I've seen a project in Go that aims to deal with that level of "system-ness" yet. And I suspect I know the reasons (why, say, I wouldn't write the packetzoom protocol stack in Go) but I'd like to know more about whether to Go team thinks it made the right choices in language and runtime design for a systems language.
- enneff 13y ago
  There are a few Go databases mentioned in the blog post, and several more besides. Also there's weed-fs a distributed storage system (and at least one other whose name escapes me right now). I also think Go would be a great language for implementing a BigTable server.
  - chetanahuja 13y ago
    Hmm... I did miss the line with groupcache and kv. Sorry about that. Though I still think you'd agree with me that go is not exactly killing it at that level of the stack (as opposed to the numerous examples of rather more successful usage at a level higher than that).
    - enneff 13y ago
      I think it's mostly a case of storage systems being a very core, important part of any software stack. If shit goes wrong at that level you're really screwed, so it takes longer to develop that kind of software and also longer for people to trust it enough to use it for serious things. But there is plenty of action at that level in the Go community, and as distributed consensus libraries like go-raft mature it will only become easier to write and trust such software in Go.
      - tonyplee 13y ago
        Personally, I think there are other reasons. I developed software system with hundreds of millions to a few billions data entries items in the core object store (C++) and need to very fast access time. There are needs to open/load/read those objects in database in very fast speed (< 0.01 seconds). When I profiled those operations in early version of the code, the biggest bottleneck is always the malloc/free when the system reached > 10 millions records. To get around those limitation, I end up design the data structures / datastore that eliminated the malloc/free, new/delete and do my own memory manager to map all the info directly to the structure in the file via mmap and do my own sub allocations. With those, I can get everything in < 0.01 seconds constant access time regardless the size of the database. (from startup of the program to return the value to client.) I think all modern day database or BIG DATA type system app depend on its own custom memory manager. My theory, a language that depend on garbage collection can not be used in those big data app design. I love to be proven wrong by someone re-implement the mysql, (or even just sqlite) in "pure golang" (not sqlite driver in C) that can provide similar level of performance with golang's garbage collector compare to sqlite's C counter part. The use case I care about is DB size of 0.1GB - 50 GB with hundreds of millions of records in the DB.
- virtuz 13y ago
  I don't think anyone would rely on the performance of a garbage collected language for an OS kernel. There are some things Go is great for now – web apps, lower-layer services and daemons — but I wouldn't ever consider it a contender for things like that. Hence the comparison to ruby, PHP, python, JS etc.
laureny 13y ago
> So we are pleased to see Go being used for the job it was designed for, This sounds a bit like revisionism. Rob Pike made it clear that the initial motivation for Go was the slowness of the C++ compilation. Go was clearly initially targeted at replacing C++ and it's not being successful in that area at all. Personally, I think it will grab a decent amount of Ruby and Python programmers but it won't go much further than that.
- axaxs 13y ago
  I see that as an obvious mistake. C++ is so different than C, and I imagine most C purists despite it. Go created a smarter C, and presented it as the solution. The problem though is that C++ people likely aren't C purists to begin with, or that C purists are too into C. Compounded by those who only drop to C when needed, you begin to see why it failed initially in this segment. I do think it will continue to gain adoption, but linux is such a firm C membership club that it will either be painfully slow, or else require Go to play nicer with C.
  - pcwalton 13y ago
    > C++ is so different than C, and I imagine most C purists despite it. Go created a smarter C, and presented it as the solution. I think it has nothing to do with the difference between C and C++ and everything to do with the reasons why people use C and C++: extreme performance, zero-cost abstractions, and integration with native libraries.
    - axaxs 13y ago
      I think you are right, and I tried to convey that in my last two sentences but in retrospect worded it poorly. I guess what I was trying to say there is that people who "drop to C"(or for that matter, start in C) for performance reasons or compatibility reasons aren't going to consider a slower and less integrated language. This is probably most people, I'm not sure many people write everything in C regardless of task anymore(such as say, webapps). I still think the initial part stands. C and C++ are not visually or mentally similar languages. Go is very similar to C in logic, so I'm not sure why it was expected that C++ people would flock to it(unless of course they weren't happy with C++, which brings us back to the first condition in that they were probably only using it for performance).
_ak 13y ago
No, I found the term systems programming to be brilliant to describe the kind of things exactly between applications and operating systems, and I think the Go team did a good job communicating this from day 1. It just seems it was misunderstood (maybe even intentionally so) by detractors that focussed too much on their very own interpretation of the term.
wilderness_one 13y ago
I think of Go as systems programming for the web, not a typical, stand-alone system.

by enneff 13y ago

millstone 13y ago

You don't build operating systems at Google?

enneff 13y ago
Well, we have Android and ChromeOS, which are both Linux. While we do have a lot of people doing Linux kernel work, I'm not aware of any "green field" operating systems being built at Google. (Although I wouldn't be surprised to be wrong here.) Most of the software we build at Google are server processes that talk to other server processes. Go was designed primarily for this role, but it is obviously useful for a lot more.

chetanahuja 13y ago

Well, I would argue that there's a level between "db replication infrastructure" type projects and OS kernels. That is the space occupied by things like database engines (everything from BigTable and descendants to Oracle), distributed storage engines (GFS and descendants) etc. I don't think I've seen a project in Go that aims to deal with that level of "system-ness" yet. And I suspect I know the reasons (why, say, I wouldn't write the packetzoom protocol stack in Go) but I'd like to know more about whether to Go team thinks it made the right choices in language and runtime design for a systems language.

enneff 13y ago
There are a few Go databases mentioned in the blog post, and several more besides. Also there's weed-fs a distributed storage system (and at least one other whose name escapes me right now). I also think Go would be a great language for implementing a BigTable server.
- chetanahuja 13y ago
  Hmm... I did miss the line with groupcache and kv. Sorry about that. Though I still think you'd agree with me that go is not exactly killing it at that level of the stack (as opposed to the numerous examples of rather more successful usage at a level higher than that).
  - enneff 13y ago
    I think it's mostly a case of storage systems being a very core, important part of any software stack. If shit goes wrong at that level you're really screwed, so it takes longer to develop that kind of software and also longer for people to trust it enough to use it for serious things. But there is plenty of action at that level in the Go community, and as distributed consensus libraries like go-raft mature it will only become easier to write and trust such software in Go.
    - tonyplee 13y ago
      Personally, I think there are other reasons. I developed software system with hundreds of millions to a few billions data entries items in the core object store (C++) and need to very fast access time. There are needs to open/load/read those objects in database in very fast speed (< 0.01 seconds). When I profiled those operations in early version of the code, the biggest bottleneck is always the malloc/free when the system reached > 10 millions records. To get around those limitation, I end up design the data structures / datastore that eliminated the malloc/free, new/delete and do my own memory manager to map all the info directly to the structure in the file via mmap and do my own sub allocations. With those, I can get everything in < 0.01 seconds constant access time regardless the size of the database. (from startup of the program to return the value to client.) I think all modern day database or BIG DATA type system app depend on its own custom memory manager. My theory, a language that depend on garbage collection can not be used in those big data app design. I love to be proven wrong by someone re-implement the mysql, (or even just sqlite) in "pure golang" (not sqlite driver in C) that can provide similar level of performance with golang's garbage collector compare to sqlite's C counter part. The use case I care about is DB size of 0.1GB - 50 GB with hundreds of millions of records in the DB.
virtuz 13y ago
I don't think anyone would rely on the performance of a garbage collected language for an OS kernel. There are some things Go is great for now – web apps, lower-layer services and daemons — but I wouldn't ever consider it a contender for things like that. Hence the comparison to ruby, PHP, python, JS etc.

laureny 13y ago

> So we are pleased to see Go being used for the job it was designed for, This sounds a bit like revisionism. Rob Pike made it clear that the initial motivation for Go was the slowness of the C++ compilation. Go was clearly initially targeted at replacing C++ and it's not being successful in that area at all. Personally, I think it will grab a decent amount of Ruby and Python programmers but it won't go much further than that.

axaxs 13y ago
I see that as an obvious mistake. C++ is so different than C, and I imagine most C purists despite it. Go created a smarter C, and presented it as the solution. The problem though is that C++ people likely aren't C purists to begin with, or that C purists are too into C. Compounded by those who only drop to C when needed, you begin to see why it failed initially in this segment. I do think it will continue to gain adoption, but linux is such a firm C membership club that it will either be painfully slow, or else require Go to play nicer with C.
- pcwalton 13y ago
  > C++ is so different than C, and I imagine most C purists despite it. Go created a smarter C, and presented it as the solution. I think it has nothing to do with the difference between C and C++ and everything to do with the reasons why people use C and C++: extreme performance, zero-cost abstractions, and integration with native libraries.
  - axaxs 13y ago
    I think you are right, and I tried to convey that in my last two sentences but in retrospect worded it poorly. I guess what I was trying to say there is that people who "drop to C"(or for that matter, start in C) for performance reasons or compatibility reasons aren't going to consider a slower and less integrated language. This is probably most people, I'm not sure many people write everything in C regardless of task anymore(such as say, webapps). I still think the initial part stands. C and C++ are not visually or mentally similar languages. Go is very similar to C in logic, so I'm not sure why it was expected that C++ people would flock to it(unless of course they weren't happy with C++, which brings us back to the first condition in that they were probably only using it for performance).

_ak 13y ago

No, I found the term systems programming to be brilliant to describe the kind of things exactly between applications and operating systems, and I think the Go team did a good job communicating this from day 1. It just seems it was misunderstood (maybe even intentionally so) by detractors that focussed too much on their very own interpretation of the term.

wilderness_one 13y ago

I think of Go as systems programming for the web, not a typical, stand-alone system.