Have you programmed in Google's GO programming language by Google today?
Their Hello World is weeaboo!! It must be good!
Name:
Anonymous2009-11-10 22:21
No, because it's retarded. It calls itself a systems language, but has garbage collection. The whole point of a systems languages(like C) is to have complete control over everything. If the compiler or runtime is managing memory, then it's not a systems language, it's bullshit. Programmers these days are such pussies.
Name:
Anonymous2009-11-10 22:26
>>2 Cringe. Another poor imitation of C that I will never ever use. Why do people keep churning out shit like this? Who thought that Systems language + garbage collection == GOOD IDEA? I would like to kick them in the groin.
What is the origin of the name?
“Ogle” would be a good name for a Go debugger.
I don't get it.
Go has fast builds, clean syntax, garbage collection, methods for any type, and run-time reflection
Sure doesn't seem like a systems language to me - honestly, it seems like a replacement to the shit-show that is Java. It couldn't have gotten here soon enough. Not sure why they're calling it a systems language actually.
Some of it seems extremely attractive, in particular slices; that looks like a truly great language feature. Built-in concurrency looks really good; no other language has done this properly, and most new ones don't even try (I'm looking at you, Python). Another thing that in my opinion is good:
Go does not support function overloading and does not support user defined operators.
It's like D done right. It's like managed C with built in GC/threading libs and all the old legacy and error prone shit cleaned out (built-in arrays, no header files, no automatic type conversions, case labels don't fall through automatically, etc).
Some really nice improvements over C++; for instance C-style method declarations only (no duplicate syntax), open classes!!!, new() is a function, automatic interfaces (static duck typing! roxors!).
Here's one thing that doesn't look good:
When a package defines an object (type, constant, variable, function) with a name starting with an upper case letter, that object is visible to any other file which imports that package.
Having the language interpret naming conventions for things is a bad idea. It was a shitty idea in Python and it's still a shitty idea.
Name:
Anonymous2009-11-11 1:22
Go promotes writing systems and servers as sets of lightweight communicating processes, called goroutines, with strong support from the language. Run thousands of goroutines if you want—and say good-bye to stack overflows.
I'd just like to point out that these should have been called broroutines.
I find it mildly interesting that they did not use LLVM because they felt it was too slow, as one of the reasons people are excited about LLVM is because it's much faster than GCC.
Name:
Anonymous2009-11-11 10:58
>>17 because it's might one day be a little faster than GCC until GCC gets a patch the next day.
Name:
Anonymous2009-11-11 11:22
At first glance I like the look of it.
I'm a bit scared of GC and lack of pointer arithmetic, but coroutines and closures are sexy. Still, Java's GC left a bad taste in my mouth and I'm scared.
It's like everything I want in a non-C language: most of C, lightweight threads and stops short of being Perl.
Nastiest fugly syntax I've seen in a language, and that includes Erlang.
Here's hoping it dies a quiet death.
Name:
Anonymous2009-11-11 11:36
For what reason exactly do people dislike the concept of a garbage collector? is the dependency on pointers that strong?
Go language looks interesting. I'm rather uncomfortable with its weak enforcement of a standard statement termination (sometimes ';', sometimes not) but that's nitpicking. If I had the free time I'd take to learning its grammar.
Name:
Anonymous2009-11-11 11:37
>>20
Erlang isn't bad. I've liked languages with worse syntax. And at least it's not whitespace dependent.
Name:
Anonymous2009-11-11 11:42
>>21
I've been burned by bad GC on a few occasions. The GC here is probably alright though.
In Go, ; is not a terminator, it's a separator. It behaves a lot like Perl's treatment of commas (a tail comma is accepted.) Think of it as a means of appending a statement to the current line or group.
Name:
Anonymous2009-11-11 11:43
Issue 9: I have been working on a programming language, also called Go, for the last 10 years. There have
been papers published on this and I have a book.
I would appreciate it if google changed the name of this language; as I do not want to have to
change my language!
>>26
LLVM's problem scope is elaborate. Therefore, it shouldn't be surprising that LLVM is still incomplete and immature.
Name:
Anonymous2009-11-11 11:50
>>23 In Go, ; is not a terminator, it's a separator. It behaves a lot like Perl's treatment of commas (a tail comma is accepted.) Think of it as a means of appending a statement to the current line or group.
What is it in terms of C's comma operator?
but a) it's a semicolon and goes in semicolon places, and b) while it must come between grouped statements, it can be peppered throughout code willy-nilly:
fmt.Printf("Sup guys?\n");;;;
compiles with no complaints (just checked), even though none are needed there.
and c) caveats galore, strained analogy, etc.
Name:
Anonymous2009-11-11 12:01
Google will just tell francis mccabe to go suck some gay elephant cocks then they will go back to doing no evil as usual.
>>34 fmt.Printf("Sup guys?\n");;;; VALID C CODE, RETARD
Name:
Anonymous2009-11-11 17:10
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.
Name:
Anonymous2009-11-11 17:21
>>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.
Name:
Anonymous2009-11-11 17:57
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.
Name:
Anonymous2009-11-11 18:04
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.
Name:
Anonymous2009-11-11 19:30
>>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.
Name:
Anonymous2009-11-11 19:32
>>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.
Name:
Anonymous2009-11-11 19:35
oh lawdy shared libraries??? what will they think of next!
Name:
Anonymous2009-11-11 19:44
>>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.
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.
Name:
Anonymous2009-11-12 3:00
>>64
Actually, has anyone done amy benchmarks, for instance those from computer language shootouts?
Name:
Anonymous2009-11-12 4:23
>>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.
Name:
Anonymous2009-11-12 4:58
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.
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?
>>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.
Name:
Anonymous2009-11-12 9:22
>>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.
>>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
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?
Name:
Anonymous2009-11-12 17:37
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.
Name:
Anonymous2009-11-12 18:27
>>80
Why do you say it looks like MUMPS? I certainly didn't get that impression.
i'm tempted to learn just so i can say "i learned Go when it was still less than a year old".
Name:
Anonymous2009-11-12 21:05
>>84
With the way Google rapidly deploys their latest crap, I would expect the Go language to be of widespread use some time in the future. It's probably worth learning it now.
>>79
I haven't tested it buy maybe you need to create more than 100 for them to share threads.
Name:
Anonymous2009-11-12 22:11
>>86
Nah, I tried it with 100,000 but it died on me during a call to clone() (theirs, not Linux's) after about 8000 goroutines. These all just go to sleep for roughly ever. Each goroutine was spawning another host process every step of the way.
Name:
Anonymous2009-11-12 22:51
>>79 >>87
Post your code and let's try and figure out what's happening.
Name:
Anonymous2009-11-12 22:57
>>79,86,87
Never mind, I'm just a retard. I didn't realize that time.Sleep() actually causes the host process to block and so spawns another. Now I want a 'lightweight' Sleep().
Name:
Anonymous2009-11-13 1:00
GOTO considered harmful (not by Google obviously).
>>92
Your comment does not refer to any thread context.
Name:
Anonymous2009-11-13 10:28
>>90
Not using goto for error handling because you're afraid Dijkstra's ghost is going scorn you in front of your friends is the hallmark of a programmer too insecure to be of value.
>>94
Worse still, the majority of snickering "goto considered harmful" morons use break, continue and all of the other language features that Dijkstra despised, even though they are essentially gotos.
Name:
Anonymous2009-11-13 12:20
>>96
I'm an extremist: Branches considered harmful.
All machine code must write the code to follow. This is why we need 128bit instruction sets people!
Name:
Anonymous2009-11-13 18:56
>>97
That's not nearly extreme enough: Integers considered harmful
Name:
Anonymous2009-11-14 3:28
>>98
Semiconductors considered harmful. What we need is more tubes.
Name:
Anonymous2009-11-14 4:00
BROROUTINES
Name:
Anonymous2009-11-14 4:38
>>100
I'd let a hot japanese girl perform her routines on my erect bro, if you catch my drift.
Name:
Anonymous2009-11-14 8:55
>>100
I'd give The Cudder a go with my routines, if you know what I'm talking about.
Helpful material shared I’m very delighted to go through this particular article..thanks for presenting us great information.Fantastic walk-through. I enjoy this article.
Name:
Anonymous2010-08-17 6:27
>>54
I am really not understanding this argument. Why does it matter if thousands of threads each use a 5 MB stack? This stack is virtual memory. It's simply address space; it does not need to be allocated by the operating system unless you access it. So what the hell is the point of segmented stacks?
I understand that there are theoretical performance benefits to userland threads, but those are a long way from proven. Java had this idea too, you know; they originally had virtual userland threads, but they switched to native threads around 1.2 or 1.3 because they got better performance that way. But segmented stacks? Fucking useless.
>>106
Host threads have improved a lot recently, but getting better performance out of them than your own implementation just means your own implementation is bad to start with.
Check out GHC for some pretty sweet userland threads. Of course, Java comes from Sun, who made Solaris, which had an M:N threading model, which was utter ridiculous crap. Give me 1:1 any day of the week.