Linked by Thom Holwerda on Wed 28th Mar 2012 19:22 UTC
General Development "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."
Order by: Score:
GCC 4.7.0
by Lennie on Wed 28th Mar 2012 20:55 UTC
Lennie
Member since:
2007-09-22

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

Reply Score: 4

Some nice clean up
by satsujinka on Wed 28th Mar 2012 21:29 UTC
satsujinka
Member since:
2010-03-11

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.

Reply Score: 2

Why haven't they gone with D?
by piotr.dobrogost on Wed 28th Mar 2012 23:08 UTC
piotr.dobrogost
Member since:
2011-10-04

Why?

Reply Score: 1

RE: Why haven't they gone with D?
by tylerdurden on Wed 28th Mar 2012 23:32 UTC in reply to "Why haven't they gone with D?"
tylerdurden Member since:
2009-03-17

Why didn't D go with C?

Reply Score: 1

RE: Why haven't they gone with D?
by satsujinka on Thu 29th Mar 2012 00:17 UTC in reply to "Why haven't they gone with D?"
satsujinka Member since:
2010-03-11

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.

Reply Score: 2

moondevil Member since:
2005-07-08

What's D's concurrency model like? Because goroutines and channels are wonderfully easy to use.


D offers the actors model, along with the usual concurrency models offered by all mainstream operating systems.

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


Any language with modules as similar compilation speeds.


D is generally more complicated than Go wants to be. Essentially, D is a better C++ but Go is a better C.


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.

Reply Score: 2

satsujinka Member since:
2010-03-11

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.

Reply Score: 2

moondevil Member since:
2005-07-08

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?


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.

Honestly, Google really isn't all that interesting a facet of Go. I'm more interested in it due to its authors' histories.


That's the only reason I still follow Go's development.

Reply Score: 2

Eager to try this...
by coldandflu on Thu 29th Mar 2012 02:05 UTC
coldandflu
Member since:
2012-03-07

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.

Reply Score: 1

RE: Eager to try this...
by satsujinka on Thu 29th Mar 2012 05:58 UTC in reply to "Eager to try this..."
satsujinka Member since:
2010-03-11

have you given go-gtk a look?

Reply Score: 2

RE[2]: Eager to try this...
by coldandflu on Thu 29th Mar 2012 08:03 UTC in reply to "RE: Eager to try this..."
coldandflu Member since:
2012-03-07

Briefly. It's still in early development as far as I can tell.

Reply Score: 1

Generics
by jello on Thu 29th Mar 2012 05:37 UTC
jello
Member since:
2006-08-08

Does Go now have generics?

Reply Score: 1

RE: Generics
by satsujinka on Thu 29th Mar 2012 05:57 UTC in reply to "Generics"
satsujinka Member since:
2010-03-11

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.

Reply Score: 1

RE[2]: Generics
by voidlogic on Thu 29th Mar 2012 14:12 UTC in reply to "RE: Generics"
voidlogic Member since:
2005-09-03

You can always use "interface{}", this is the "empty interface". All types implement this interface, so you can use it to write generic code.

Reply Score: 3

RE[2]: Generics
by jello on Thu 29th Mar 2012 15:45 UTC in reply to "RE: Generics"
jello Member since:
2006-08-08

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

Reply Score: 1

RE[3]: Generics
by satsujinka on Thu 29th Mar 2012 20:14 UTC in reply to "RE[2]: Generics"
satsujinka Member since:
2010-03-11

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.

Reply Score: 1

Am I missing something?
by jburnett on Thu 29th Mar 2012 14:50 UTC
jburnett
Member since:
2012-03-29

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?

Reply Score: 2

RE: Am I missing something?
by satsujinka on Thu 29th Mar 2012 20:23 UTC in reply to "Am I missing something?"
satsujinka Member since:
2010-03-11

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

Reply Score: 1

RE[2]: Am I missing something?
by jburnett on Thu 29th Mar 2012 21:59 UTC in reply to "RE: Am I missing something?"
jburnett Member since:
2012-03-29

You probably could implement goroutines/channels in C, but it would look hideous (in fact most multi-threading/concurrency in C does.)

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.

Pointers are useful for more than pointer arithmetic...

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.

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.

My mistake, I meant colon, not semicolon. For example, this code is taken straight from the "Tour of Go" on the Go website.


func sum(a []int, c chan int) {
sum := 0
for _, v := range a {
sum += v
}
c <- sum // send sum to c
}

func main() {
a := []int{7, 2, 8, -9, 4, 0}

c := make(chan int)
go sum(a[:len(a)/2], c)
go sum(a[len(a)/2:], c)

x, y := <-c, <-c // receive from c

fmt.Println(x, y, x + y)
}


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.

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

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?

Reply Score: 1

RE[3]: Am I missing something?
by satsujinka on Fri 30th Mar 2012 03:30 UTC in reply to "RE[2]: Am I missing something?"
satsujinka Member since:
2010-03-11

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) {}

Reply Score: 1

RE[4]: Am I missing something?
by jburnett on Fri 30th Mar 2012 12:29 UTC in reply to "RE[3]: Am I missing something?"
jburnett Member since:
2012-03-29

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.

Reply Score: 1

RE: Am I missing something?
by moondevil on Fri 30th Mar 2012 15:39 UTC in reply to "Am I missing something?"
moondevil Member since:
2005-07-08

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


You can do pointer arithmetic when making use of the unsafe package.

If everybody else is so excited about this language, what am I missing?


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.

Reply Score: 2

Too bad it is so slow
by kalcytriol on Thu 29th Mar 2012 14:55 UTC
kalcytriol
Member since:
2011-04-23

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.

Reply Score: 1

RE: Too bad it is so slow
by voidlogic on Thu 29th Mar 2012 16:43 UTC in reply to "Too bad it is so slow"
voidlogic Member since:
2005-09-03

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.

Reply Score: 2

RE[2]: Too bad it is so slow
by Valhalla on Thu 29th Mar 2012 21:41 UTC in reply to "RE: Too bad it is so slow"
Valhalla Member since:
2006-01-24

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.

Reply Score: 2

RE[2]: Too bad it is so slow
by kalcytriol on Thu 29th Mar 2012 21:59 UTC in reply to "RE: Too bad it is so slow"
kalcytriol Member since:
2011-04-23

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/

Reply Score: 1

RE[3]: Too bad it is so slow
by voidlogic on Thu 29th Mar 2012 22:22 UTC in reply to "RE[2]: Too bad it is so slow"
voidlogic Member since:
2005-09-03

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.

Reply Score: 2

RE[4]: Too bad it is so slow
by kalcytriol on Thu 29th Mar 2012 23:19 UTC in reply to "RE[3]: Too bad it is so slow"
kalcytriol Member since:
2011-04-23

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

Reply Score: 1

RE[4]: Too bad it is so slow
by kalcytriol on Fri 30th Mar 2012 01:35 UTC in reply to "RE[3]: Too bad it is so slow"
kalcytriol Member since:
2011-04-23

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

Reply Score: 1

RE[5]: Too bad it is so slow
by voidlogic on Fri 30th Mar 2012 18:34 UTC in reply to "RE[4]: Too bad it is so slow"
voidlogic Member since:
2005-09-03

"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

Reply Score: 2

RE[6]: Too bad it is so slow
by kalcytriol on Fri 30th Mar 2012 23:07 UTC in reply to "RE[5]: Too bad it is so slow"
kalcytriol Member since:
2011-04-23

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)
}
---------------------------------------------------

Reply Score: 1

RE[7]: Too bad it is so slow
by voidlogic on Fri 30th Mar 2012 23:47 UTC in reply to "RE[6]: Too bad it is so slow"
voidlogic Member since:
2005-09-03

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)
}

Reply Score: 2

RE[2]: Too bad it is so slow
by kalcytriol on Sat 31st Mar 2012 01:51 UTC in reply to "RE: Too bad it is so slow"
kalcytriol Member since:
2011-04-23

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

Reply Score: 1