/prog/s opinion on Go

You know, the google thing.  Personally I'm a bit excited for a compiled python-like C language.  It's going to take for fucking ever for it to become useful, though, especially with google's slow and steady attitude.  I could see it catching on though kind of like python did.

>>40
int n, a[3][20][5];
for (n = 0; n < 300; n++) {
    a[0][0][n] = n;
}
Now do that in a language that has strict bounds checking.

:= is to declare during assignment. you cannot re-declare, in case you are an Io fan.

gccgo produces faster code on average than the plan9 style compilers, possibly because it has no GC. it also uses pthreads (?) for all goroutines.

go is not conclusively slower than python. as you can see, the regex package is not great:
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=python&box=1

the proposed GC is documented here:
http://www.research.ibm.com/people/d/dfb/recycler-publications.html#Bacon01Concurrent

pointer arithmetic is certainly faster overall than safe arrays, perhaps not by much.

go provides "unsafe" and "reflect" packages for unsafe memory access and reflection.

cgo cannot yet create go callback functions for use in C bindings.

ken thompson > frozen void.

unsafe
BAWWWWW I'M A RETARD THAT CAN'T WRITE CORRECT CODE

Does anyone else feel that way whenever they hear "safe" as one of the main features of a language?

Also, something to think about: Those who give up freedom for security deserve neither.

>>43
You can still do all kinds of unsafe things(everything, just not as easily) in safe languages, as long as you have some sort of FFI or functions which allow you to interface directly with lower-level things.

>>41
Funny that this is your example - recent versions of GCC will transform this into nested loops. It's better for cache locality.

Optimization advice sure does have a short shelf life, doesn't it?

>>43
It is a typesafe language. "unsafe" is an accurate name for the package.

BAWWWWW I'M A RETARD THAT CAN'T WRITE CORRECT CODE
You probably are.

>>45
Funny that this is your example - recent versions of GCC will transform this into nested loops. It's better for cache locality.
What, no it's not.  Are you high?

>>47 is my friend

B         K
 O       C M
  U     E   Y
   N   H     A
    D C       N
     S         U
                S

>>49
I thought you'd be a fan of pink sock.

>>39
That's an interesting wiki, thanks FV.

>>40
indexing an array is the same speed and memory overhead as stepping using pointer arithmetic
I can't seem to grasp the difference between them. Aren't the two the same thing?

>>24
all metaprogramming and pointer manipulation thrown out the window
What kinds of things can you achieve with pointer arithmetic that you couldn't do otherwise? I haven't really written a lot of C and I think the only use aside from dynamic arrays was when I had some semi-inheritance going on.

>>51
indexing an array is the same speed and memory overhead as stepping using pointer arithmetic
I can't seem to grasp the difference between them. Aren't the two the same thing?
Where the above assertion is true, yes, they're the same thing. But indexing a safe array is not as fast as arithmetic, and the difference is bounds-checking.

>>51
How about allocating an array and then adjusting the pointer afterward, so that accesses to a[-1] or a[-2] are valid?
Or any case where you're iterating something and passing it between one function and another; if you can't manipulate pointers, then you have to pass around two variables for the array and the current index, and your functions have to account for this instead of simply writing a[0] a[1] a[2] etc. and adjusting the pointer when calling it.

Both cases can be "fixed" by adding more syntax to the language, but it's entirely unnecessary because a perfectly decent way to handle these scenarios already exists.

I have a feeling that in some years, people will rediscover low-level languages and pointer manipulation in much the same way that Lisp is currently being rediscovered.

>>51
That's an interesting wiki, thanks FV.
That's the wiki. That's the only wiki you can call "Wiki" without angering expert internet users.

>>52
Yeah, I know that. I just thought that there would be a fundamental difference of which I wasn't aware when >>40-chan said
on modern processors

>>53
You're right, that would be useful too. I'm more interested in the things you couldn't achieve through ordinary language constructs, though.

>>55
Nah, there's no difference. Now postmodern processors...

>>53
Bit of a question.  Is there a situation where writing a method or function (sub, etc., what have you) that takes an array and an index as parameters is inconvenient?

>>57
I suppose that if you were to implement a forEach :: [Pointer a] -> IO () function which would be tail-recursive and use null as a sentinel value.

>>58
Damn I'm stupid. Make that forEach :: (a -> IO ()) -> [Pointer a] -> IO ().

>>58
Sadly there's no tail recursion guarantees in Go. From what I understand there is some optimization being done presently, but it is subject to change.

>>57
You can't easily use an array+index as a callback for another function that expects the user function to take one argument; you have to wrap it in a struct first -- increasing the program's complexity.
You can't return an array and index from a function without special language support for it -- increasing the language's complexity. (I am aware that even C lets you return an aggregate type, but you still have to make a struct for something that shouldn't need one; and it's poor form because it changes how the function is handled on the assembly-code level.)
The extra variable and internal state needed in order to keep track of the index and array boundary increases the size of any function that handles arrays, and hogs up cache line space in memory -- thus, if these languages are ever to be as fast as C they will need ever-larger CPU caches to hold all this superfluous data.

>>61
Good points, in MY Prague?

>>61
Go has multiple return.

Really, it doesn't have to be as fast as C. Close enough is good enough. 80% is pretty good for a debut with a to-be-fixed collector.

What you *should* be worried about is GC-induced latency. The GC being implemented claims to pause for only 1ms, which is usable. People are already writing Java for embedded "realtime" systems you know, and people are even paying good money for those devices.

>>63
Close enough is only good enough in PHP and Lisp. Do you see dollar signs? Do you want more parentheses? Slow is pig disgusting.

>>64
^{Close enough isn't slow,} because _{slow isn't close enough.}

>>65
And then the Pragueraider was enlightened.

>>66
I read my SICP for this?!

>>61
Where the above assertion is true, yes, they're the same thing. But indexing a safe array is not as fast as arithmetic, and the difference is bounds-checking.
Why does everyone keep saying this? It's not true. Once allocated, Go's arrays and slices are fixed size; you do the bounds check *once* at the start of the loop, and the compiler can then transform it into pointer arithmetic. There is no overhead. For all its faults, Java has solved this particular problem a decade ago.

You can't easily use an array+index as a callback for another function that expects the user function to take one argument; you have to wrap it in a struct first -- increasing the program's complexity. You can't return an array and index from a function without special language support for it -- increasing the language's complexity.
Uh, folks? Go does have this. It's called slices. It's a built-in language feature that creates a reference to a portion of an existing array.

This is a very minor increase in the complexity of the language for a rather massive reduction in complexity in the resulting libraries. Every goddamn function in the entire Java library that takes an array also takes offset and length. Every function in the C library that takes a pointer for an array also takes count. Go solves this elegantly in a way no other language does; not Lisp, not C, and not even Python, whose slices are actually array copies.

The extra variable and internal state needed in order to keep track of the index and array boundary increases the size of any function that handles arrays, and hogs up cache line space in memory -- thus, if these languages are ever to be as fast as C they will need ever-larger CPU caches to hold all this superfluous data.
Total bullshit. Under the hood, slices are probably implemented as a small struct passed by value containing a pointer to the first element of the slice and the length of the slice. This is the same exact overhead as if the function just took a count parameter (like they ALL do in C, aside from the brutal string functions).

And this is insignificant compared to the size of the array itself! You are absolutely grasping at straws here.


I am really surprised at how much bullshit is being spewed here, and how much you are all worrying about insignificant and trivial overhead for pointer safety. You guys honestly think the extra four bytes for an array size, the one extra jne instruction at the start of a for loop are going to make a difference here? You really think that THIS is the thing about Go worth arguing about, and not anything else about the actual semantics of the language?

>>68
; not Lisp
http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_d.htm#displaced_array

>>68
Go does have this. It's called slices. It's a built-in language feature
Which was the entire point of the text you quoted.

Total bullshit. Under the hood, slices are probably implemented as
I love how you call bullshit, and immediately confess to not knowing a goddamn thing about what you're discussing. That's a masterful trolling technique you have.

And this is insignificant compared to the size of the array itself!
And yet, the pointer to the current position in the array will still take 4 (8 for 64-bit) bytes of cache, versus the 12 (or 24) required to hold either a start/current/end pointers or an array/index/length triple. When you're optimizing for speed, keeping your L1 cache clean is hugely important, and even on the most modern CPUs, you only have a few hundred bytes to work with. You'll never match the speed of a very tight pointer-based function if you keep invalidating cache lines with "safe" array training wheels. The size of your array is irrelevant.

>>68
you do the bounds check *once* at the start of the loop
You still need to do it at runtime for dynamic arrays and computed indices. That's not free, even if it is optimized to once per loop in the ideal cases.

Go solves this elegantly in a way no other language does
Gag me.

I am really surprised at how much bullshit is being spewed here
If you'd stop pretending that every little observation must somehow be refuted at all costs there would be a lot less bullshit.

>>70
Just so you know, Go slices are a pointer, length and capacity values. I believe the pointer is native word sized and the len and cap values are 32bits everywhere. There is no reference to the original array. So that's 12 or 16 bytes for the whole struct.

>>72
Which is what I said.

>>73
Not in this thread you didn't.

>>74
12 (or 24) required to hold either a start/current/end pointers or an array/index/length triple
12 or 16 bytes for the whole struct.

>>75
Those numbers a) describe a different set of values and b) are sums of different properties.

>>76
"Pointer, len, and cap" are different from "start, current, end" only if you are a fool.

>>77
Lies

>>77
You don't understand. There is no "start"; "pointer" is "current", comparing "len" and/or "cap" to "end" isn't very accurate, though it is part of their function. You're the HIBT? for being willfully ignorant.

>>79
You don't understand. No matter what fucking way you store the data, you're still in one way or another tracking the boundaries and current position of your array or slice thereof.