“Today marks a major milestone in the development of the Go programming language. We’re announcing Go version 1, or Go 1 for short, which defines a language and a set of core libraries to provide a stable foundation for creating reliable products, projects, and publications. Go 1 is the first release of Go that is available in supported binary distributions. They are available for Linux, FreeBSD, Mac OS X and, we are thrilled to announce, Windows.”
Also has partial support for Go 1.
Their plan is to have a complete implementation in the 4.7.1 release.
Edited 2012-03-28 20:55 UTC
Go’s libraries have gotten much cleaner than they were last year. I was using the rc for awhile and it’s been much smoother than the last “stable” release.
Why?
Why didn’t D go with C?
What’s D’s concurrency model like? Because goroutines and channels are wonderfully easy to use.
Another goal of Go is speed of compilation. D probably doesn’t compete very well (but that’s just a suspicion based on the sizes of the two languages.)
D is generally more complicated than Go wants to be. Essentially, D is a better C++ but Go is a better C.
D offers the actors model, along with the usual concurrency models offered by all mainstream operating systems.
Any language with modules as similar compilation speeds.
A better C but lacking:
– enums
– generic programming
– metaprogramming
– exception handling
– FFI with C or C++ libraries requires the use of a C compiler on the host system
– No direct support for system programming
If it wasn’t for Google’s backing, Go would just be another attempt to replace C.
Go has iota for creating enums. The rest of those C doesn’t have either. And how else do you expect go to compile C code if not with a C compiler?
Honestly, Google really isn’t all that interesting a facet of Go. I’m more interested in it due to its authors’ histories.
iota is a kind of poor man’s solution and it feels bad, when all mainstream languages have proper enums.
You are right, but since Go is also being “sold” as an alternative to C++, JVM and .NET languages, the lack of abstractions places it in a bad position, only feeling as a better C.
D, C++, Ada, Delphi are just a few of the languages that are able to link to C libraries without requiring a C compiler. This is not the case with Go.
That’s the only reason I still follow Go’s development.
I’m eager to try Go once it gets a decent GUI library. Sounds like it would be perfect for the kind of work I do.
have you given go-gtk a look?
Briefly. It’s still in early development as far as I can tell.
Does Go now have generics?
considering the authors of go are fundamentally opposed to including generic, I’m surprised you’d feel the need to ask that question.
though I do wish they’d include them, since there are generic functions and types in the specification. You just can’t create one for yourself.
You can always use “interface{}”, this is the “empty interface”. All types implement this interface, so you can use it to write generic code.
> considering the authors of go are “fundamentally opposed” to including generic, I’m surprised you’d feel the need to ask that question.
What are you talking about?
Rob Pike said in one video I saw they are thinking how to implement it. And it could be that it will never show up in Go.
So “fundamentally opposed” seems to me your own opinion.
They considered it because people requested it. But if you read around the golang-nuts group you’ll find that the general opinion of generics is that they are close to useless.
Am I missing something with Go? The syntax is as complicated as C for learners, but different enough to cause massive typo problems for experienced programmers. It has pointers, but no pointer arithmetic (so really what is the point…). Slices and re-slicing look like one major “where is the semi-colon” run-time bug waiting to happen. And goroutines/channels are cool, but they could be implemented with functions in C.
Admittedly, I have only read the “A Tour of Go” document, but it leaves me with one big question. If everybody else is so excited about this language, what am I missing?
You probably could implement goroutines/channels in C, but it would look hideous (in fact most multi-threading/concurrency in C does.)
Pointers are useful for more than pointer arithmetic…
Slices aren’t any harder to use than arrays, for that matter I don’t think I’ve ever specifically created an array in Go. I’m not sure what you mean by “where is the semi-colon” considering you don’t need to put them in.
The syntax differences between Go and C are few and far between, but the ones that do exist make Go an easier language to teach (in my opinion.)
Why would channels be complicated in C? They are just a queue. Instead of x <- y, you simply do push(x, y) or x.push(y) if using c++.
What makes goroutines any easier than just using pthreads? pthread_create(&pth, NULL, threadFunction, threadArgs) is not that difficult. You have to be a little careful with your function arguments. Of course having real pointers makes this easier since you can map a custom struct to a void *. Aside from that you have to worry about the same things with sync issues.
I agree with you, pointers are useful for more than pointer arithmetic. They are great when you want to copy by reference instead of value. However, after reading more about pointers in Go, they seem more like references. My understanding of pointers vs references is that pointers let you do pointer arithmetic, and thus take direct control of the memory. Whereas references take away the direct access are easier for memory management, garbage collection, and new programmers.
My mistake, I meant colon, not semicolon. For example, this code is taken straight from the “Tour of Go” on the Go website.
It took me probably 30-40 seconds before I realized that it was a[:len(a)/2] vs a[len(a)/2:]. Note the location of the colon, which defines how the slice is re-sliced. This is really cool, but I can already see myself feeling stupid for getting it wrong and spending a couple hours trying to figure out why my results are so weird.
I agree that Go seems very C-inspired, much more so than Java. However, it changes very small details. I could be wrong, but I see typos are in store. For example, I can prototype a function – int myFunc(int *x, int *y) {} – in a couple seconds. Typing func myFunc(x *int, y *int) int {} just took me about 8 times longer. Will I get used to it, sure, but it will be a slow process. Also, Go drops parentheses and semi-colons left and right. One article I read said they are not even optional. Just another tiny difference that is going to slow me down.
So again I ask, is there some huge benefit I’m missing? Is Go going to be much faster to develop/maintain/run.? Or is it just a new way to do multi-threading/garbage collection with C inspired syntax that looks prettier to some people?
Please keep in mind that I never said it would be complicated in C. I said it would look bad.
goroutines:
go fun()
channels:
c<-“send a string”
receive<-c
these look much nicer than your C example, in my opinion. Similarly, I like the re-slicing syntax (I believe python has a similar syntax.)
It is true C function declarations are simpler, however, you do get used to Go really quickly. Go is simpler to parse (pure left to right with no look ahead) and function declarations are one thing that needed to change.
Btw, if you have two *int variables you can do this (including multiple returns):
func myFunc(x,y *int) (int, error) {}
Ahh, now I get it. Some of Go is based on python syntax. I guess that is why they named arrays slices. Actually, it almost looks like somebody took Python, stripped out the OO part, added data typing, and said lets compile this. Which is really cool.
Of course I’m basing this on about 30 minutes spent reading Python docs and about the same time with Go docs. Despite 25 years of coding experience in everything from assembly to ruby, I never learned Python. One of the very few popular languages I have just never needed. Maybe it is time to learn.
You can do pointer arithmetic when making use of the unsafe package.
Honestly, people get crazy about it, because it is a Google language. I seriously doubt anyone would care, if that would not be the case.
We all know how Plan9 sadly ended, the previous project where the main Go authors were part of. It was not their fault, but Go is very similar to Alef and this might be their attempt to revive the language.
Go Web sever with bare “hello world” is 10x slower than equivalent in C and almost as fast as Java Play Framework with a lot of magic behind.
This is unacceptable. When I’ll place my app written in Go on Cloud service it will cost me a lot for wasted CPU time.
Your test case is like measuring language performance by seeing who runs this C++ code the fastest:
for(int i = 0; i < 100000; i++);
That is a useless micro-benchmark.
Any program I have written in Go that is non-trivial has had acceptable to excellent performance. I would also like to point out that post Go1 there are aggressive compiler and garbage collector upgrades waiting to commit. Go is still young.
Maybe Go currently isn’t better than Java (currently) on the CPU front, but it is better Java on the memory front:
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=…
Low memory usage and “good enough” CPU usage is more important to most real world apps.
Also, go is still much better than something like PHP on the CPU front:
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=…
I’m also interested in which version of go you ran your test with.
While I really like Go and see myself doing serious programming with it in the not too far off future I have to agree with top poster that it is currently quite slow from my tests and also tests I’ve seen on Language Shootout. Still, like you said it’s a very young language and I’m guessing the focus sofar has been on squashing bugs and pinning down the exact language properties.
Also I’ve only tried the official 64-bit compiler (6g), I hear the GccGo compiler creates much more optimized code (due to it hooking into GCC’s much more mature optimizing backend) so that’s an option and also it proves that there’s alot more performance to be crammed out of the official compilers given time.
Not that kind of benchmark.
I did some testing using ApacheBench.
I manually managed to go up to 10k RPS for Go (setting up number of cores). But all this is still too slow (7 times slower).
http://pokazywarka.pl/aiuo77/
So I’m looking at your programs, are they both being called when someone navigates to the URL? Or are you just statically servering the .c file (which would make no sense)?
If some kind of CGI is running your C program, then it is doing less work:
puts(“Hello World!\n”);
VS.
fmt.Fprintf(w, “Hi there, I love %s!”, r.URL.Path[1:])
Your Go program should be:
fmt.Print(“Hello World!\n”)
Also, I assume whatever CGI is running your C program is not using chunking, so you should set your Go response to also not use chunking… I also assume the C CGI is not putting the date/time in the response header, go is by default to you should tell it not to.
Sorry posted a wrong code the correct one is:
fmt.Fprintf(w, “Hello World”)
Result is correct. You can see it in this line:
Document Length: 11 bytes
fmt.Pritf() prints into terminal, not to response string.
I run test again with original hello code and result was (req per second):
10441.31 [#/sec] (mean)
VS
10038.96 [#/sec] (mean) (old)
Almost the same.
Im using http://gwan.ch/ (G-WAN) as a C servlet server.
Edited 2012-03-29 23:36 UTC
Without chunking:
19k RPS. not bad, but still below level of ecceptance.
330% diference. I could accept 50% max
Incresed CPU time = wasted money.
Both response headers:
————————————————— C Serv
HTTP/1.1 200 OK
Server: G-WAN
Date: Thu, 29 Mar 2012 23:47:36 GMT
Last-Modified: Thu, 29 Mar 2012 23:47:36 GMT
Etag: “441d9cc1-4f74f498-b”
Vary: Accept-Encoding
Accept-Ranges: bytes
Content-Type: text/html; charset=UTF-8
Content-Length: 11
Connection: Keep-Alive
—————————————————- Go
HTTP/1.1 200 OK
Content-Length: 11
Content-Type: text/plain
Date: Fri, 30 Mar 2012 01:16:24 GMT
———————————————————-
BTW do you know any other optimization tricks?
Another thing is a heavy lack of documentation. I wasted a lot of time just to find how to write to header. Yes, Id found it but in some other part of internet. At least their search engine is fine (Google).
“BTW do you know any other optimization tricks?”
I’d be happy to take a look, can you post a link to your latest code?
As far as documentation, check out http://golang.org/pkg/
Specifically regarding headers: http://golang.org/pkg/net/http/#Header
Nothing special, just:
GOMAXPROCS=4
hello.go ———————————————-
package main
import (
“net/http”
“fmt”
“strconv”
)
var hellostr string=”HelloWorld”
var hellolen string=strconv.Itoa(len(hellostr))
func handler(w http.ResponseWriter, r *http.Request) {
w.Header().Set(“Content-Type”, “text/plain; charset=UTF-8”)
w.Header().Set(“Content-Length”, hellolen) // this icreases server performance 2x ,from 11kRPS to 22k RPS (requests per second)
fmt.Fprintf(w, hellostr);
}
func main() {
http.HandleFunc(“/”, handler)
http.ListenAndServe(“:8080”, nil)
}
—————————————————
Your posted program would get 6-8k per run on my machine with ab -k -n 200000 -c 800 http://localhost:8080/
The below program gets 60,000+ RPS on my machine, changes:
* Set max procs dynamicaly
* Stopped net/http go from getting and sending the time with every request
* used fprint rather than fprintf (faster)
package main
import (
“fmt”
“net/http”
“strconv”
“runtime”
)
const hellostr = “HelloWorld”
var hellolen string = strconv.Itoa(len(hellostr))
func handler(w http.ResponseWriter, r *http.Request) {
w.Header().Set(“Content-Type”, “text/plain; charset=UTF-8”)
w.Header().Set(“Content-Length”, hellolen) // 2x faster ,from 11k RPS to 22k RPS (requests per second)
w.Header().Set(“Date”, “”)
fmt.Fprint(w, hellostr)
}
func main() {
runtime.GOMAXPROCS(runtime.NumCPU()/2 + 1)
http.HandleFunc(“/”, handler)
http.ListenAndServe(“:8080”, nil)
}
Thanks for reply.
Your code performs as well as mine on my machine.
Setting Date to blank has a barely noticable influence on benchmark results.
A greater role has setting proper number of cores and http chunking.
BTW im running a Linux machine, so I have GOMAXPROCS set up manually to 2*n_cores (4) in bashrc.
Before that i had 6-7k RPCs just like You. Thanks for “runtime” line so from now on I wont have to use manual setup.
Edited 2012-03-31 01:53 UTC