http://golang.org/

Have you programmed in Google's GO programming language by Google today?

Their Hello World is weeaboo!! It must be good!

>>40
I call NYJMUA on this.

>>41
Nuyo Tsumua?

>>34
        fmt.Printf("Sup guys?\n");;;;
VALID C CODE, RETARD

I watched the Google-made YouTube video with the kid in the black T-shirt.  What did I learn?  That Go compiles quickly. 

Did this win me over?  Not really.  I mean, as much as I value a quick build, the merit is in how easy it is to code and what the performance is like post-compilation.

In an extreme situation, I would be willing to run a build for a week on my box, if the result was sex on wheels.

>>44
Typical C programmer; always reinventing things on wheels.

>>43
It is. I thought I had a compiler warn me for doing that before. gcc4 isn't doing it though. I don't stroke my epeen, so I don't really care.

That mascot has to die. And that name. I'll wait until I've written something a bit larger than hello world before commenting on the actual language features.

func Announce(message string, delay int64) {
    go func() {
        time.Sleep(delay);
        fmt.Println(message);
    }()  // Note the parentheses - must call the function.
}

Lightweight threads and closures all at once. Tell me you don't want this. I get off when you lie to me.

According to the ``Tech Talk'', they consider Java a systems language as well.  Because you can write a wob server in it.

>>49
Actually I imagine a webserver in go would be quite excellent. Their 'goroutines' have segmented stacks that start out 1k in size and grow exponentially. A process could launch tens of thousands of these to serve any number of connections, and they could all be doing heavyweight rendering of pages with negligible memory overhead because the libraries they load are shared.

I think I just got a hardon.

>>50
Also, just thought I'd point out that the webserver currently running golang.org is itself written in go. Pretty cool.

>>50
You do know that you can have the libraries loaded in the same memory space on most OSes... It's called dynamic loading.
As for growing stacks... again, nothing particularily special, and it's available with some implementations.

oh lawdy shared libraries??? what will they think of next!

>>52,53
Obviously other languages share code between threads, that's not the point. The point is native support for microthreading. This is in contrast with Apache, which will typically spawn 50 processes, each running mod_wsgi and taking up 20 megs of memory. It doesn't share code between processes, as safety against leaks and such. This is a non-issue with go.

>>54
Systems Expert, in da house!

>>55
He's right you know.

>>54
It doesn't share code between processes
Perhaps you need to learn what a fucking operating system is, sir.

>>56
O RLY MR TROLL

What does Go have to do with google? HIBT?

>>58
Well, if supporting lightweight threads in place of OS processes where appropriate is considered trolling then I have clearly been trolled, sir.

>>45
Better than reinventing on rails.

themacbook:gotest haxus$ cat test.go
package main
import "fmt"
func main() {
    fmt.Println("hax my anus")
}
themacbook:gotest haxus$ gofmt test.go
package main

import "fmt"

func main()    { fmt.Println("hax my anus") }
themacbook:gotest haxus$ 8g test.go
themacbook:gotest haxus$ 8l test.8
themacbook:gotest haxus$ ./8.out
hax my anus
themacbook:gotest haxus$ l
total 1176
-rwxr-xr-x  1 haxus  wheel  589617 Nov 12 01:20 8.out
-rw-r--r--  1 haxus  wheel    5171 Nov 12 01:20 test.8
-rw-r--r--  1 haxus  wheel      70 Nov 12 01:19 test.go
themacbook:gotest haxus$

That's nearly 30% larger than the equivalent haskal program.

>>64
Actually, has anyone done amy benchmarks, for instance those from computer language shootouts?

>>65
I just ran the binary-tree benchmark included with the Go source, and compared it to the C version. The C version finished in 19.04 seconds; the Go version finished in 230.99 seconds. That's 12x slower. Other benchmarks may be more favorable, and hopefully both the compiler and runtime will get more optimizations. They seem pretty confident that they're gonna get a latency-free, multi-threaded garbage collector, although currently it's just mark-and-sweep.

For these 4 Celebrities (Ken/Rob mostly) and backed by $USD from Google.
I was massively underwhelmed :(

The D programming language already solved everything better with a tiny community and people working in their free time.


Quick List (incomplete) of missing features in GO that D has
. exception handling
. generic programming
. metaprogramming     <-- I can't live without this one
. inline assembler
. interface to C
. RAII
. immutability for anything but strings
. vector operations
. operator overloading
. purity
. CTFE ( compile time function evaluation: again too valuable to miss )
. unit testing
. ability to write systems code like implement a GC
. conditional compilation <-- how can they possible NOT have this; am I mistaken?
. contracts
. 80 bit floating point
. introspection (runtime or compile time)
. reference parameters

btw: A high performance 3D game engine was written in D years ago. Can't write a garbage collector in GO either so it can never bootstrap.

From the syntax/design choises they took it's going to be really difficult/impossible to add most of these features.

oh and to top it off ... that goroutine code is actually 30 lines of unix C++ code that calls pthreads, it would be trivial for the c++ Boost library to have channel implemented, so all that go has really is the "duck type" interface system.

>>67
owned

Is dmr the only one left at Bell Labs?

Speaking about language benchmarks, is anyone else intrigued by the fact that the list of languages on http://shootout.alioth.debian.org is now in reverse alphabetical order, making Smalltalk, Scheme, Ruby and Python the first 4 languages listed?

>>70
Not really, no.

>>67
Except that D has no usable implementation satisfying its feature list, so congratulations on finding an imaginary language which has oh so many features more than Go.

>>67
Actually they do have a lot of things on this list, like unit testing and reference parameters. Some are also left off on purpose, such as exceptions and operator overloading. I'm glad it doesn't support these.

And for the low-level things you want, like asm, I can't imagine gccgo not supporting these already. Things like this take time; this is the difference between a language a day old and a language several years old.

>>72
Except it does.

^{SO DOES MY}ANUS

>>67
that goroutine code is actually 30 lines of unix C++ code that calls pthreads,

You're either trolling or an idiot. Goroutines are multiplexed onto a small number of threads, so just making a pthread for each goroutine is not the same. Goroutines are cheap because their overhead is just about 1 KiB of stack space each, unless they start needing more stack, in which case it'll grow. And blocking goroutines get rescheduled so that other goroutines get a chance to run one of the real threads.

>>76
EXPERT KOOLAID DRINKER

>>77
Return to slashdot please.

>>76
He might not be trolling as hard as you suspect. I'm testing with 100 goroutines, and I've got 100 host threads:

     ├─konsole─┬─bash───8.out───100*[{8.out}]

This is not what I expected to see. Usually lightweight threads do not appear as host threads, correct?

This language is looking a lot like MUMPS.
Seriously, anyone who was unfortunate enough to code in MUMPS will know what I'm talking about. Not good. Not good at all.