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

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

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

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

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?

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

>>85
SCHEDULE MY ANUS

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

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

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

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

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

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

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.

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.

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

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

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

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

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.

>>99
Ivory-tower academic detected

>>100
Blub detected

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

>>100
There's an XKCD for that

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.

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

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.

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

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

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

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

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.

suck my slippers

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.

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

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

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

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.

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

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

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