Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-8081-120121-160161-

/prog/s opinion on Go

Name: Anonymous 2009-11-28 22:04

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.

Name: Anonymous 2009-11-28 22:08

JEWS

Name: Anonymous 2009-11-28 22:08

JEWS

Name: Anonymous 2009-11-28 22:08

JEWS

Name: Anonymous 2009-11-28 22:08

JEWS

Name: Anonymous 2009-11-28 22:08

JEWS

Name: Anonymous 2009-11-28 22:09

Protip: All the mainstream languages have taken years to develop support communities and libraries. Go won't be an exception to this.

Name: Anonymous 2009-11-28 22:23

I like it. I will probably use it almost exclusively when the GC is improved, dynamic loading/linking is implemented and cgo generally gets fixed (eg. I need callbacks.) I just wish they'd make some kind of guarantee for constant-space tail recursion.

Name: Anonymous 2009-11-28 22:25

systems programming
built-in garbage collection
i lol'd.  then went back to not paying attention to silly new things.

(but in all seriousness, >>7)

Name: Anonymous 2009-11-28 22:46

>>9
Yeah it will take time. I'm not sure how much because of the Google factor. They are taking it slow, but OTOH, the libraries will probably expand quickly if they adopt it internally.

Even without Google's involvement, the community is actually strong already: people have made various BSD ports and there's even a Windows port.

The GC isn't really a barrier to systems programming. You can't write an OS in it yet, but one of the guys on the Go team responded encouragingly to a suggestion that ARM targets shouldn't strictly require an OS, which I suspect will carry over to other architectures if implemented.

There is a need to be able to suspend GC and manipulate the scheduler though. They say mutexes are provided for writing device drivers. Sounds like they're going to finish up those details down the road.

Name: Anonymous 2009-11-28 23:22

>>10
That's insanity. If it becomes possible to do systems programming in Go, then, well.... You might as well do it in Haskell for that matter.

And that will be the end for America.

Name: Anonymous 2009-11-28 23:29

>>11
It's already possible to do system's programming in Haskell, it just may not be a very good idea for anything but a HaskellOS

Name: Anonymous 2009-11-28 23:42

>>11
Why is that so insane? Go seems like a great fit for the embedded^Wsmall devices market, now that it's saturated with Java. Android is insane for using Java.

Name: Anonymous 2009-11-28 23:46

>>13
Anything that means less Java is a Good Thing™.

Name: Anonymous 2009-11-29 0:01

>>14
signed

Name: Anonymous 2009-11-29 2:03

>>13
Write once, run everywhere. thread over

Name: Anonymous 2009-11-29 2:23

>>16
like anyone believes that

Name: Anonymous 2009-11-29 6:36

>>17
Apparently Google does along with anybody that believes enough to invest their efforts to Android.

Name: Anonymous 2009-11-29 8:22

>>18
Android is probably just a dry run anyway, shit will get real when they release a free desktop OS based on Go.

Name: Anonymous 2009-11-29 8:51

>>12
My dream is to write a SchemeOS, compile it with Gambit-C, build a small bootstrapper in C and...

Name: Anonymous 2009-11-29 9:07

>>20
And fuck lots of hot girls?

Name: >>20 2009-11-29 9:13

>>21
U MENA GUYS

Name: Anonymous 2009-11-29 9:34

Needs more FORCED INDENTATION OF CODE

Also I heard that what they released on day one was as terse as C, as slow as Python, has a bad garbage collector, and the whole goroutines thing didn't work well. So people are probably going to love it.

Name: =+=*=F=R=O=Z=E=N==V=O=I=D=*=+= !frozEn/KIg 2009-11-29 10:30

Go fails on several levels:
1.Search for Go - 58 meanings in English alone here http://en.wiktionary.org/wiki/go#English
2.No production Windows version. They aren't serious "Gccgo is a Go compiler that uses the GCC back end. There is also a suite of compilers with different (and odd) names for each architecture: 6g for the 64-bit x86, 8g for the 32-bit x86, and more. These compilers run significantly faster but generate less efficient code than gccgo".
3.No pointer arithmetic? C replacement without pointer arithmetic is absurd(all metaprogramming and pointer manipulation thrown out the window for a little bit of safety).
4.Garbage collection:("The current implementation is a plain mark-and-sweep collector but a replacement is in the works.")
In short this isn't a systems language and won't replace C or even Java for quite awhile, even if Google pours millions in it.

_______________________________________________
http://bayimg.com/image/aadbjaace.jpg
My Blog: http://frozenvoid.blogspot.com/
«I think, and my thoughts cross the barrier into the synapses of the machine - just as the good doctor intended. But what I cannot shake, and what hints at things to come, is that thoughts cross back. In my dreams the sensibility of the machine invades the periphery of my consciousness. Dark. Rigid. Cold. Alien. Evolution is at work here, but just what is evolving remains to be seen. »

Name: Anonymous 2009-11-29 10:43

>>24
Wait a minute, why am I agreeing with FV? Have I gone insane or is he finally talking sense.

Name: Anonymous 2009-11-29 11:05

>>25

U MENA SAGE

Name: Anonymous 2009-11-29 12:20

>>25
No, he's know to sometimes say sensible things just to mess with people's minds.

Name: Anonymous 2009-11-29 12:21

s/know/\0n/

Name: Anonymous 2009-11-29 15:07

>>25
Er, points 1 and 2 there are obvious trolls (if you know anything about Go.) 3 and 4 are up for debate though.

Name: Anonymous 2009-11-29 17:41

>>29
It's not a troll if it's true, however irrelevant it may be.

Name: Anonymous 2009-11-29 18:35

>>30
A troll doesn't have to be a lie. Irrelevant statements used as arguments fit the bill just fine.

Name: Anonymous 2009-11-30 2:22

:=
No, thanks.

Name: Anonymous 2009-11-30 3:07

>>32
No shit.  Isn't using Pascal's assignment syntax just retarded at this point?

Name: Anonymous 2009-11-30 3:18

>>33
U MENA FJÖLNIR

Name: Anonymous 2009-11-30 3:27

>>33
U MENA OCAML

Name: Anonymous 2009-11-30 3:30

>>32,33
So nobody should use that symbol pair to represent anything ever again?  Not even what Go uses it for?

Name: Anonymous 2009-11-30 3:44

>>24
Hey, FV is back! *waves*

No production Windows version. They aren't serious
I fucking lol'd. You do know that Google, with their thousands of employees, uses almost exclusively Linux right? They have no Windows expertise in-house. Why would they bother with a Windows port when some winfag will (and did) port it for them in a few days?

No pointer arithmetic
I really don't understand why this is a "can't live without" feature. Granted it's probably pretty important for writing an operating system, but aside from that, what do you really need it for to write stuff like webservers? I can't remember the last time I needed pointer arithmetic in C.

Besides, the lack of raw pointers and pointer arithmetic makes it possible to write a real generational copying collector, which is a huge advantage that goes far beyond 'a little safety' (more on this below).

Garbage collection:("The current implementation is a plain mark-and-sweep collector but a replacement is in the works.")
Good garbage collectors take *a long time* to write. They're fucking complicated. However once they're written, they're typically faster than malloc/free. Java's allocator in recent versions is a lot faster than malloc/free (calm down folks, just the allocator/collector amortized is faster, Java in general is shit slow). Even just linking Boehm's with no other changes very rarely makes programs run slower, and occasionally (often?) makes them faster.

I'm not sure why it's a problem for Go that it doesn't have this yet. The real news here is that the language spec makes it possible to write. Go will get a copying collector soon enough, and all the goodies that come with it: amortized O(1) allocator, heap compaction to prevent memory fragmentation, realtime profiling to improve cache locality, the list goes on.

Besides, garbage collectors are just about essential for real multi-threaded apps. They really do go hand in hand. Sorry folks, but it's not 1995 anymore; CPUs have lots of cores and it's time to use 'em.

Name: Anonymous 2009-11-30 3:47

>>33
That's initialization shorthand. Assignment is just =. These lines are equivalent.


var x int = 0;
x := 0;

Name: Anonymous 2009-11-30 10:29

>>39
Please check all Google software which is Linux-only and that which is Windows-only. You will see shortly the latter outnumbers the former by wide margin. Google knows their users OS preferences. This project looks like sponsored hobby-work - not a Google project.
You are *incredibly* wrong. ALL of Google's core technology runs on Linux only. We're talking about their scrapers, all their algorithms e.g. MapReduce, PageRank, etc., all their websites include GMail, all of their servers, etc. Millions upon millions of lines of code, none of it ported to Windows.

Only about 1% of their software development is meant to run on end-user machines. Lately this is Google Desktop and Chrome, both of which run on all of Windows, Linux and Mac.

Pointer are fast, small and versatile:
So are array indices. In fact, a) on modern processors, indexing an array is the same speed and memory overhead as stepping using pointer arithmetic (the faq mentions this in fact), and b) these are interchangeable; a good compiler can switch array indexing to pointer arithmetic on its own (and still retain bounds checking).

Also, why on earth would you want to do polymorphism on your own when the language provides a facility for this already? And not just any facility, but the best and safest we know: implicit conversion to any implemented interface. Static duck typing. You do know that this is just a v-table under the hood, right? In fact if you do it by hand, you're doing EXACTLY what the compiler would just do for you.

Name: Anonymous 2009-11-30 11:42

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

Name: Anonymous 2009-11-30 11:58

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

Name: Anonymous 2009-11-30 13:05

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.

Name: Anonymous 2009-11-30 13:09

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

Name: Anonymous 2009-11-30 13:18

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

Name: Anonymous 2009-11-30 13:19

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

Name: Anonymous 2009-11-30 15:48

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

Name: Anonymous 2009-11-30 16:07

>>47 is my friend

Name: Anonymous 2009-11-30 16:12


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

Name: Anonymous 2009-11-30 16:22

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

Name: Anonymous 2009-11-30 16:33

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

Name: Anonymous 2009-11-30 17:13

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

Name: Anonymous 2009-11-30 17:14

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

Name: Anonymous 2009-11-30 17:46

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

Name: Anonymous 2009-11-30 18:00

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

Name: Anonymous 2009-11-30 18:08

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

Name: Anonymous 2009-11-30 18:30

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

Name: Anonymous 2009-11-30 18:34

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

Name: Anonymous 2009-11-30 18:36

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

Name: Anonymous 2009-11-30 18:51

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

Name: Anonymous 2009-11-30 19:13

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

Name: Anonymous 2009-11-30 19:35

>>61
Good points, in MY Prague?

Name: Anonymous 2009-11-30 19:39

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

Name: Anonymous 2009-11-30 19:47

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

Name: Anonymous 2009-11-30 19:50

>>64
Close enough isn't slow, because slow isn't close enough.

Name: Anonymous 2009-11-30 20:02

>>65
And then the Pragueraider was enlightened.

Name: Anonymous 2009-11-30 20:17

>>66
I read my SICP for this?!

Name: Anonymous 2009-11-30 23:00

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

Name: Anonymous 2009-11-30 23:17

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

Name: Anonymous 2009-11-30 23:33

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

Name: Anonymous 2009-11-30 23:55

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

Name: Anonymous 2009-12-01 0:05

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

Name: Anonymous 2009-12-01 0:22

>>72
Which is what I said.

Name: Anonymous 2009-12-01 1:12

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

Name: Anonymous 2009-12-01 10:24

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

Name: Anonymous 2009-12-01 10:42

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

Name: Anonymous 2009-12-01 11:33

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

Name: Anonymous 2009-12-01 12:16

>>77
Lies

Name: Anonymous 2009-12-01 14:15

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

Name: Anonymous 2009-12-01 15:43

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

Name: Anonymous 2009-12-01 16:01

>>80
There's more information than that, and it fits in less space than you claimed. This is clearly something different than what you described.

Name: Anonymous 2009-12-01 16:39

less space
Sure, 12 bytes is different than 12 bytes. IHBT

Name: Anonymous 2009-12-01 16:48

>>82
Sorry, I didn't realize you were still running 32bit. I didn't mean to make you feel bad.

Name: Anonymous 2009-12-01 19:37

These quibbles are still completely and utterly trivial. If you have to care deeply about your L1 cache performance, you write *that specific function*, or those few hundred lines of code, in C or assembly anyway. No one is arguing this.

But writing an entire program in C because 0.1% of it needs to be fast is, well, insane.

Can we please just grant that you'll write that 0.1% in C, and take this discussion back to the actual high-level semantics of Go?

Name: Anonymous 2009-12-01 20:10

>>84
You don't even need to write it in C. "reflect" and "unsafe" generally give very good performance.

The only thing you can't get around is the GC and calling out with FFI won't really help there, the GC is going to run anyway. For example, I have code in C that needs to run during every millisecond, but this is impossible in Go, even if I write that in C and the rest in Go, the GC puts me off schedule whenever it runs.

Name: Anonymous 2009-12-01 20:11

>>85
SCHEDULE MY ANUS

Name: Anonymous 2009-12-01 20:26

>>85
It *currently* does this. The GC is very primitive. Java's GC does not have this problem, and neither does Objective-C's GC. Just give it a little time.

Name: Anonymous 2009-12-01 21:14

>>87
Objective-C's GC is Boehm, i.e. the fucking same.

Name: Anonymous 2009-12-01 21:52

>>88
Really? I was under the impression that Boehm's did not have these problems. As far as I know it does not halt threads during a collection...

Name: Anonymous 2009-12-01 21:58

>>89
Reading more about it, it seems I'm wrong, and that the collector does not run on a separate thread; collections are incremental (a side effect that occurs when you alloc), whereas the sweep phase actually does halt execution for a short period.

Ah well, there are forks of Boehm's that are properly threaded, and Java's collector does not work this way. Just needs more time.

Name: clever guy 2009-12-01 22:38

>>87
Google's sufficiently smart GC is vaporware until it isn't.

Anyway, Go is currently intended to be a language for Google's *internal use*, so they're not really concerned about it catching on elsewhere at this stage; at least, that's what I got from the original announcement. I don't think what Go is doing is very impressive, though. OCaml is faster and terser than Go and it exists *today*; SBCL and LuaJIT2 also beat Go while having dynamic typing. Hell, even thin layers on top of C, like OOC and Vala, are beating Go in terseness and speed at this point, and, I'll wager right now, they'll continue being better for at least the next two years.

http://live.gnome.org/Vala
http://ooc-lang.org/

So I don't find Go to be particularly special.

Name: Anonymous 2009-12-01 22:57

>>87
No, I was describing the new proposed GC (linked above) which claims to halt every thread for roughly 1ms during its collection pass. The current one presumably halts for longer due to running a full sweep, but I have no idea really.

Name: Anonymous 2009-12-01 23:54

I love how all you fags pile as much shit as you can on top of this new language, suggesting it's not as good as what we already have. Fags like y'all have been saying that for years, and what has it given us?

C++0x

Once you massive homosexuals finally stop jerking each other off, maybe we can try to support new languages that may some day be better than the massive piles of feces we're stuck with today.

Name: Anonymous 2009-12-01 23:58

I've used The D programming language for 2 years now. When I saw GO I laughed my ass off; but then then raged when Pike said no "major" language has attempted fixing C/c++. What an arrogant cunt thinking you need a Corp to be major these days. D has enough Celebrities developing it to be tagged "Major".

tr;dr version:
nice toy language for making web/email servers.

Name: Anonymous 2009-12-01 23:59

>>91
Never mention OOC. Its horrible shitty syntax has nothing to do with C, and it doesn't offer anything remarkable in any form whatsoever.

Name: Anonymous 2009-12-02 0:12

With the help of CLAG, I can see Go achieving similar speeds to C/C++ in perhaps a year or two.

Name: Anonymous 2009-12-02 0:44

With the help of /prog/, I can see no one here caring about Go anymore in perhaps a month or two.

Name: Anonymous 2009-12-02 1:27

>>94
HIBT? Ignoring for the moment that D does not "fix" C/C++, a major language needs a strong userbase, not celebrity endorsement. I can't think of any standard software written in D, let alone much of it. (Besides, Ken's celebrity trumps just about anyone alive today.)

>>95
I thought it looked nicer than Vala. (Then again that's not hard: don't take cues from any language with non-alpha characters in the name.)

Name: Anonymous 2009-12-02 8:38

I can't think of any standard software written in D, let alone much of it.
I hate this argument. There's plenty of good languages out there, and people don't use them because they're not used much/not popular in the industry? Why do you care, just learn the language and find out for yourself if it fits your needs. This is a general argument, and doesn't apply to D. It's even worse that people just pick languages mostly just because of how good their marketing is.

Name: Anonymous 2009-12-02 9:40

>>99
Ivory-tower academic detected

Name: Anonymous 2009-12-02 9:49

>>100
Blub detected

Name: Anonymous 2009-12-02 10:39

>>99
That wasn't my argument. My argument was that the language is not a "major" language for that reason, not that it is not worth using for that reason.

But honestly, it's generally not worth using over C for that reason - the advantages are muddled in some weird decisions (no worse than C++ mind you) and the existing support for C trumps these dubious advantages.

Name: Anonymous 2009-12-02 12:44

>>100
There's an XKCD for that

Name: Anonymous 2009-12-02 16:10

Speaking of Go's chance to be a "major" language, let's look at it from a historical perspective.

Right now, Google has some of the best intellectual capital in software engineering among all companies on earth. Their reputation is good enough to hype fucking COBOL as the Next Big Thing (tm) and people will still drink their Kool-Aid. They have a prime opportunity to revolutionize the current sorry state of software engineering. And now that they've decided to release a programming language, I feel that they are responsible to software engineers and computer scientists everywhere for making it COUNT.

This is why I am so disappointed with Go. Reading through the specification gives one a sense of deja-vu. All the stuff in there has been around for decades, and there are features NOT there that should be given that it's 2009. In fact, Go the language could have been invented circa 1989 by a CS graduate student and nobody would have batted an eye.

Google, with their not inconsiderable political sway, could have taken 40 years of research and made something AMAZING, and that language would have as much buzz surrounding it as Go does right now, even if it looked like it came from the highest ivory tower, simply because IT WAS DESIGNED BY FREAKING ROB PIKE AND KEN THOMPSON. No other people had that opportunity. Sure, one could put one's creation on the Internet and hope for the best, and it's worked small miracles for Haskell, Clojure, Factor, etc.. But reality dictates that these languages, no matter how inherently well designed they are, will never even touch the popularity of the major players.

Instead, we get a language that is only incrementally better than C, Java, and C++, which, I'm going to say straight, isn't much of an accomplishment at all. Ignoring syntax, here's what Go should have, at a MINIMUM:

Full type inference;
Parametric polymorphism, a.k.a. generics;
An effects system;
A macro system;
Type operators;
Exception handling or, even better, continuations;
NO null/nil construct. Seriously, that shit's not necessary in this day and age.

A few of these require a little runtime overhead, but like >>84 said, if you really need that much speed, just go back to C. Hell, Go's already got GC and virtual methods. A little bit extra is just a drop in the bucket. To be fair, I like their inclusion of first-class functions, interfaces (which I feel are even better than Haskell's type classes), and CSP, but it's not enough. If they had managed just to eliminate null, I'd be all over this language, but alas, they failed.

Name: Anonymous 2009-12-02 16:16

>>104
I'm not going to comment on the feature set you selected, however you are completely right about Google wasting an opportunity to better programming in general by promoting a language worth using.

Name: Anonymous 2009-12-02 16:59

Full type inference;
A macro system;
Type operators;
These were rejected as problematic. Part of the goal is unambiguous code.

Parametric polymorphism, a.k.a. generics;
Exception handling or, even better, continuations;
To reiterate from earlier in the thread, the language design is not complete. These are two items that are being discussed and the question on both of them seems to be more one of "how" than of "if".

Generics are a non-issue to me. Interfaces are pretty alright. Ideally, exceptions would be made more or less irrelevant. I'm glad they didn't just tack on nonsense facilities for these items, because it would really make a mess of things.

NO null/nil construct. Seriously, that shit's not necessary in this day and age.
What's the problem? No really, I'd like to know.

Closures are, agreed, a great thing to have. The CSP falls a bit short for me on a few miscellaneous points.

The few changes that were made to the standby feature sets produces a greater change than incremental change, there's a minor paradigm shift involved.

There are a lot of rough edges, but the complaints that "excluded feature X is missing" are only made by people who don't use the language. For those who do, there are still complaints, mostly "included feature Y comes up short." This reflects the paradigm shift, and a proper attitude to working assessing the language: don't hate what makes it different, hate what makes it insufficient.

Name: Anonymous 2009-12-02 17:10

>>104
Parametric polymorphism, a.k.a. generics;
So it doesn't have them? Would be indeed useful.

An effects system;
What's that?

A macro system;
Wouldn't that require the code to be homoiconic? Or do you mean like C macros, in which case you can just run your source code through cpp before compiling.

Type operators;
Elaborate please?

>>104,106
CSP
?

Name: Anonymous 2009-12-02 17:14

>>104
Null considered harmful?  I am curious, please explain sir

Name: Anonymous 2009-12-02 17:24

>>104
Full type inference;
Parametric polymorphism, a.k.a. generics;
Exception handling or, even better, continuations;
I couldn't help but notice that Java 7 supports all of these things.

Name: Anonymous 2009-12-02 17:26

>>109
Nope, Java 7 doesn't have full type inference, just local variable type inference. For real type inference, see ML or Haskell.

Name: Anonymous 2009-12-02 17:42

I want to know what's wrong with null values too.  The only problem with null values is when it isn't handled very well.

Name: Anonymous 2009-12-02 17:44

suck my slippers

Name: Anonymous 2009-12-02 17:47

Google just wanted something they could sell to the ENTERPRISE, and use themselves. Having cool features(for example 'real macros') that programmers can (ab)use to write code much more productively is not in their interest as they still need the average joe programmer to be able to understand code written by others, and they need to be able to replace programmers like cog pieces. If you want better languages, just pick what you like from the good ones that already exist, and USE IT, regardless if some large corporation likes it or not. It may mean you won't get to write code in such languages when hired by such corporations, but that's not all there is to programming.

Name: Anonymous 2009-12-02 18:01

>>113
I agree with your sentiment,but
and they need to be able to replace programmers like cog pieces
I hope you are talking about the Enterprise in general and not Google. Last I checked, people are still fawning over what it would be like to work at Google, giving them the chance to pick whichever talented and deluded fanboys they want

Name: Anonymous 2009-12-02 18:14

>>114
Google may be a nice place to work, but it's still the Enterprise. Peter Norvig(wrote PAIP and other interesting books) works there and he agrees that languages that are powerful and offer a lot of features, but can't be understood by average programmers don't belong in their company, as it's just an unacceptable risk. He also agrees that if he was the one writing the application, he'd just pick the better language and be done with it, but since they have the money and the workforce, picking easier to understand, but less capable languages are the sane choices for a company in the long run.

Name: Anonymous 2009-12-02 18:17

>>107
Parametric polymorphism, a.k.a. generics;
So it doesn't have them? Would be indeed useful.
They don't add too much to what is already present in Go. Go's interfaces don't quite cover the whole thing (and the approach is completely different), but they really are quite something.

Name: Anonymous 2009-12-02 18:56

Lisp is easy mode for acting like a "smarter than thou" elitist retard.
Seriously, if you want to feel smart then just read a damn textbook book, you lazy morans.

Name: Anonymous 2009-12-02 19:00

>>115
I believe you, but I'd like a citation.
'Easier to understand' is a very subjective, but since everyone is generally taught an Enterprise Quality Language anyway, it doesn't really matter.

Name: Anonymous 2009-12-02 19:38

>>118
Lisp is only used by 1 out of 1000 programmers;
Therefore it is obviously better than ENTERPRISE languages which everybody knows.
This is what Lispers actually believe. Damn hipsters.

Name: Anonymous 2009-12-02 19:40

>>119
Haskell is only used by a little over six hundread people all over the world. This makes it better than Lisp.

Name: Anonymous 2009-12-02 19:44

>>117
Who said Lispers don't read their textbooks? Most of them read more textbooks than the average programmer.

Name: Anonymous 2009-12-02 20:08

>>121
My theory is that since we have better books than other languages Little Schemer/SICP/AMOP/PAIP it makes us more inclined to read them

Name: Anonymous 2009-12-02 20:11

factorial n = if n > 0 then n * factorial (n-1) else 1

Name: Anonymous 2009-12-02 20:11

>>121
Oh, Lispers read textbooks, yeah.
But they're the kinds of people who then write a blog post about how they read the book, whereas for most people finishing a book is not an earth shattering event

Name: Anonymous 2009-12-02 20:15

>>122
My theory is that since C has better books than other languages K&R/APitUE/Lions' it makes us more inclined to read them.

My theory is that since Perl has better book than other languages Learning Perl/Intermediate Perl/Programming Perl it makes us more inclined to read them.

etc etc etc for every common language in existence.

Name: Anonymous 2009-12-02 20:18

>>125
etc etc etc for every common language in existence.
You are supposed to do 1 and then leave it for others to continue on. Seriously, the manners of some people

Name: Anonymous 2009-12-02 20:32

>>124
I don't think that is the case.
1) There's not a lot of Lispers
2) I don't own a blog, and don't plan on having one in the future
3) I've only seen a handful of Lisp blogs. A few were interesting, but they talked about things like what was the latest feature someone added to their compiler or something along those lines. Sometimes, those may be worth reading. From the few Lisp blogs that I've seen, only like 2 of them talked about reading some Lisp book, and it was a newbie's blog, which means most people won't be reading those.
4) I find some books to be insightful(wether about Lisp or in general), but I haven't encountered that many books which lead to an "earth shattering event".
5) The general attitude in the Lisp community is that people should write more code, instead of talking about how great Lisp is. Graham did a bit too much of the latter. There's also some strange people who don't actually know Lisp, but sing praises to it, and view it as some perfect language in which they'll never code in, instead they come to Lisp for "enlightment" - this is the wrong attitude, Lisp may give a programmer new views on certain problems, but that's not going to happen unless you actually learn the language well and use it.

>>125
There's actually a surprising few Lisp books, but the overall quality is fairly high. More popular languages tend to have a lot of books written for them, but only a handful are top quality. It's only natural that there will be more low quality books in a market where the demand is high, while in a market where the demand is low, only those actually interested in will write the books. This ratio isn't very important, as long as the reader knows which books to read.

Name: Anonymous 2009-12-02 20:50

>>116
No, parametric is slightly different from ad-hoc polymorphism. In terms of System F, the former is expressed as
/\T. \x:T. do something with x
whereas the latter is
/\T. \x:T. if (T can be unified with A) then foo x
      else if (T can be unified with B) then bar x
Yes, you can simulate the parametric variant by simply providing the same code for foo and bar, but that defeats the abstraction.

Name: Anonymous 2009-12-02 21:08

>>128
No I get it. What I'm saying is that if Go's approach is used correctly, there's little need for parametrics. The problem is there's still a small gap and it's kind of annoying. On the other hand, I would rather see every other problem addressed first.

Name: Anonymous 2009-12-02 21:14

>>128
Lets see if I've understood this correctly
foo :: a -> [a] would be parametric
bar :: (Baz a) => a -> [a] would be ad hoc

Name: Anonymous 2009-12-02 21:21

>>107
Type operators are simply abstractions over types as if they were values, and works in tandem with polymorphism to allow the programmer to write generic code. For example, LinkedList in Java is an operator that takes a type and gives another type, and the type inside angle brackets is the argument. LinkedList<Int> returns the type of linked lists specialized to hold integers.

With generalized type operators, it is possible to do all sorts of crazy shit, like defining null-safe lists (cliche pseudo-Haskell here):

data Zero :: *
data Succ n :: *
data List n a where
  cons :: forall n a. a -> List n a -> List (Succ n) a
  nil :: forall a. List Zero a
head :: forall n a. List (Succ n) a -> a
head [x] = x
Note that head is typesafe. If passed an empty list, the compiler will throw a type error. Succ and List are both type operators. The former takes one argument, while the latter takes two.

Name: Anonymous 2009-12-02 21:29

>>130
Your second snippet would be ad-hoc if bar is defined within a typeclass instantiation. If it is just a vanilla function, then it's still just parametric, except now the type parameter has an extra constraint: that a is an instance of Baz.

Name: Anonymous 2009-12-02 21:39

>>132
Ah yes, I knew I was missing something. Thanks

Name: Anonymous 2009-12-02 22:02

>>106,108,111

The only place where null is useful is as a sentinel value for collections. But if you really think about it, any well-chosen user-defined value can fulfill that role. Everywhere else, it's a pain in the ass to deal with. Don't tell me you've never been annoyed with NullPointerExceptions, because that's bullshit.

Having null in the language amounts to admitting the possibility of run-time errors *every time* you use a pointer/reference, but null is obviously only useful *sometimes*. See Scala or OCaml's Option and Haskell's Maybe for alternative ways to solve the null problem when they *are* needed. Note that OCaml is object-oriented, but its variables can never be null. That is because the ML language family actually has type systems that advanced beyond the 70s, unlike C++ and Java, who use glorified structs and are object-oriented in name only.

In short, think of null as the equivalent of Haskell's _|_. Both can be values of any type, but Haskell actually has the courtesy to crap out and allow the programmer to give a helpful text message every time it is encountered, whereas Java, C++ (pointers only, not references), and Go will happily chug along until the problem is encountered so far from its source that hours of frustration ensue.

Remember, kids: When you must fail, fail noisily and as soon as possible.

Name: Anonymous 2009-12-02 22:19

>>134
I've never been annoyed by null pointer exceptions because I generally don't spend much time in languages that make heavy use of exceptions. Not to mention I check operations that could return null. It's not like it is somehow required to throw over every encountered null value anyway, but people do. Don't hate the player.

Besides which, I rarely find libraries that will return null when it should be meaningless. In other words, testing on null in practice ought only be necessary when some kind of test is necessary anyway. Your null pointer exception stems from the fact that exceptions are being misused, presumably in order to prevent the problem of having to try { everything }, which is also frustrating. The exceptional case should be truly exceptional; "degenerate state" not "operation failed." (Ignoring the latter is cause #1 of the former. Throwing on the latter promotes it to the former.)

Name: Anonymous 2009-12-03 0:05

>>107
Thanks for helping the rest of us idiots (this is not sarcasm, I actually was wondering the same things but was afraid to ask a bunch of stupid questions).

I'll ask a few more:

Full type inference;
These were rejected as problematic. Part of the goal is unambiguous code.

Why is full type inference problematic? Is it that it did not play nice with their (quite cool) system of inferring implemented interfaces?

I've never used a language that has it, but as I'm reading about it, full type inference seems pretty awesome to me. It's like everything is a template. Why is this not in the language?

Does type inference cause problems with break/continue, return, goto, etc? I've heard that in many languages (especially functional languages), if/else blocks return values, which is great except that because of type inference and static typing, Haskell has the additional restriction that both blocks must return the same type. Is this true? Is this a huge pain in the ass, especially when the language doesn't have null?

null

I've never used a language that doesn't have some sort of null, but I've heard people talk about why this is great also. Personally, I know that in C I like the ability to take several parameters, and just ignore them if they are null (for example a function that outputs to a pointer and returns length; if the pointer is null, nothing is written, and you get the length you need to allocate).

Are you forced to write separate functions that call eachother in this scenario? Is this somewhat mitigated by function overloading?

An example that springs to mind where this might be problematic is a function that takes a 'logger' argument, and if it's non-null, it prints to it at several points throughout the function. How does this work if the logger can't be null? Surely you can't duplicate that code. Do you make a 'dummy' logger that ignores calls to print into it? This seems inefficient; you're probably doing lots of string formatting, and you'd like that code skipped. Do you make a sentinel value for 'no logger', and the function checks against it before trying to print? Seems like a hack to implement a (typesafe) null manually. How do you solve this problem?

Side note, nice to see a decent programming thread here once in a while. Thanks for not being dicks.

Name: Anonymous 2009-12-03 0:38

>>136
whoa whoa take it easy buddy, one question at a time, one question at a time! oxygen, I need oxygen here. you're smothering me

Name: Anonymous 2009-12-03 1:30

how does one pronounce "haskell"?

Name: clever guy 2009-12-03 1:52

>>95
it doesn't offer anything remarkable in any form whatsoever.
Of course, neither does Go.

Name: Anonymous 2009-12-03 3:30

>>138
LISP

Name: Anonymous 2009-12-03 5:43

Frozen Void is right.

The only interesting things with Go are
- the no inheritance motto, only interfaces
- goroutines

The rest of the language is pure distillated fail.

Name: Anonymous 2009-12-03 7:10

>>141
3/10

Name: Anonymous 2009-12-03 9:21

>>136
Type inference is not an implementation issue, not that I know of anyway. The idea I keep getting is that being forced to write out a conversion is better for code clarity.

Also, in Go you only ever return a specified type. If you think this is a problem, the type can be interface{} which every type satisfies, but putting an int in there won't make the LHS an int, it will just be interface{}. (You can still use it like an int, but you basically have to cast it.)

For non-nullable types, people mostly want to see them included in the language so return values and required parameters can never be nil. This would be awkward because there are no exceptions at the moment, so potentially recoverable situations would be promoted to irrecoverable ones. (The bigger part of the idea is to remove the need for defensive programming. I really don't buy that though.)

Name: Anonymous 2009-12-03 11:53

>>141
Frozen Void
Stopped reading right there.

Name: Anonymous 2009-12-03 11:59

>>144
You should have stopped posting right there. Announcing that you're ignoring something is pretty lame dude.

Name: Anonymous 2009-12-03 12:14

>>145
Ignoring FV should be mandatory. Because it isn't, we must exert peer pressure in order to preserve social order and have sensibility dominate /prog/. As you are unaware of this, I will also say, welcome to GTFO.

Name: Anonymous 2009-12-03 12:36

>>146
You should try actually ignoring him rather than making a stink and drawing yet more attention.

Name: Anonymous 2009-12-03 13:26

>>146
Although it is flattering to "dominate /prog/", in fact, it is a very bad idea. Unlike most of human society, science and engineering are based on the idea that each of us is capable of evaluating evidence and thinking on our own. Each of us can do experiments, work out the reasoning, and determine the truth for ourselves. There is no room in science or engineering for "sage" representing group disapproval over individual thought.

Name: Anonymous 2009-12-03 15:27

>>148
Did you mean, "Acceptance and rejection of theories in technical disciplines involve group approval or disapproval over individual thought"?

Name: Anonymous 2009-12-03 16:10

>>149
I see he's gotten to you already.

Damn it, MDickie, you're a programmer.  You know that science and engineering can't be taken away with the wave of a magic paintbrush.  They're the things we carry with us, the things that make us who we are.  If we lose them, we lose ourselves.  I don't want my science taken away!  I need my science!

Name: Anonymous 2009-12-03 16:15

And then >>150 was replaced by an artist.

Name: Anonymous 2009-12-03 17:57

>>107
An effects system is an extension to the language, usually in the type system, that statically infers the source and scope of side effects. In a systems programming language like Go, such a feature is ridiculously useful, because not only does it require no runtime overhead, it drastically reduces the number of errors usually attributed to "invisible" changes to state.

Name: Anonymous 2009-12-03 17:57

>>141
distillated
（　≖‿≖）

Name: > 2009-12-03 22:21

package main
import "fmt"
 
func main() {
    fmt.Printf("Hello World !!! \n")
}

Name: Anonymous 2009-12-03 23:04

>>154
package main

func main() { println("EHLO 世界") }

Name: Anonymous 2009-12-10 9:00

>>152
type inference
no runtime overhead
（　°‿‿°）

Name: Anonymous 2009-12-10 13:50

>>156
Do you somehow doubt this?

Name: Anonymous 2009-12-10 14:04

>>157
（　°‿‿°）

Name: Anonymous 2009-12-10 14:12

（　≖o≖）

Name: Anonymous 2009-12-10 14:15

(　≖‿≖)　　D
( ≖‿≖ ) 　　I
(≖‿≖　)　　C
(‿≖   ) 　　K
(≖　　　) 　　
(　 　　 ) 　　T
(　 　　 ) 　　O
(　　　≖) 　　W
( 　≖‿) 　　E
(　≖‿≖)　　R

I'm pretty sure that he'll enjoy being stuffed into anuses of clueless toddlers. (　≖‿≖)

(　≖‿≖)　　R
( 　≖‿) 　　E
(　　　≖) 　　W
(　 　　 ) 　　O
(　 　　 ) 　　T
(≖　　　) 　　
(‿≖   ) 　　K
(≖‿≖　)　　C
( ≖‿≖ ) 　　I
(　≖‿≖)　　D

Name: Anonymous 2009-12-10 14:56

>>141
Lua already essentially had goroutines, though, since coroutines could be distributed across multiple VM instances using luaproc.
And CLOS had support for the type of object system Go uses twenty years ago.

Name: Anonymous 2009-12-10 15:22

>>161
I go routinely to the toilet to EVACUATE MY ANUS

Name: Anonymous 2009-12-10 16:09

>>161
Please, stop talking about Lisp, we all know it has support for everything - it's just boring.

Name: Anonymous 2010-12-25 16:59

Name: Anonymous 2011-02-02 22:59

Name: Anonymous 2011-02-03 5:20

Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -