Only if you are inside the cult could you possibly have that opinion. Do you also think that Jim Jones was an expert on the New Testament teachings? If you take his word for it, of course he was.
We (the Go team) regularly have conversations about all kinds of programming paradigms, because we're into that kind of stuff. Some of us really like functional programming languages. But Go is not that kind of language, so those primitives do not belong there. Go is not everything to everyone, and it would be a mistake to try to make it that way. That doesn't mean that we don't see those things as generally valuable, just not in this context.
A bit OT, but probably the biggest roadblock for me switching over to Go is the wonky syntax. Are there any plans to make Go more accessible to someone coming from more traditional languages? (i.e. like "do" notation in Haskell) I've done the Go tutorial about 5 times last I checked (seriously), and I just can't stomach the syntax. I may be tainted by my years of C, though.
What?! If anything, your use of C should make Go's syntax really familiar (aside from putting the name before the type, which doesn't take long to get used to). It's exactly like any other C-like imperative language. C, C++, Java, C#, even Javascript. Those are pretty traditional langauges. Haskell is not what I think most people would call a "traditional language".
My point about Haskell was not to say that it was more intuitive for imperative programmers, rather, it was to demonstrate a syntactic sugar construct that eases programmers in. Because Go's syntax is so similar to C, it is confusing because as a coder, I can only context switch a finite amount of times.
You appear to know both Haskell and C, but find Go's syntax hard to deal with? This is one of the weirdest Go complaints I've read, for sure. Syntactically, it's just one of the many Algol/pascal-style imperative languages of the last 40 years. Most people get used to it quickly.
> I just can't stomach the syntax. I may be tainted by my years of C, though.
I can't relate to this.
That's exactly my years of C that makes Go quite attractive to me. The way I see Go is that it allows me to code as close to metal as C, but without the pains of C -- headers, make file/dependencies, memory management, and more.
Read again. As said "as close to ... but without", I didn't say "close to". If you are unable to make sense of what I wrote, don't blame me for your shortcomings.
To the siblings to this post: it seems rather unlikely as the research is being generated at a rate that far exceeds any one person's ability to read it (especially when they are already busy marrying C and CSP [which is easy to build as a library or add-on to any other existing language] & type theory isn't their specialty).
The portion of that material which is requisite is obviously a strict subset of the entirety of the material. But, for one to flippantly say "I've read it" without even establishing what "it" is, seems a bit dismissive and duplicitous to me. Regardless it is obvious to anyone who is knowledgeable that Rob Pike has not read what most who are in the know would consider "requisite".
Also, if you take a look at the thread I posted, his attitude and approach re: map, filter & reduce doesn't come across as the most academic or well thought out.
Rob didn't really say anything about map, filter, and reduce in that thread. His comments should be taken as being in addition to the earlier comments by Ian Lance Taylor, another member of the Go team.
You should address the gaps in your own knowledge before criticising others. For instance, you're obviously unaware that Rob designed and implemented a whole language based around map/reduce/filter style operations: http://static.googleusercontent.com/external_content/untrust...
I think his obvious implication is that Go doesn't need map, filter and reduce because (if I may summarize) "line feed is just a single character".
That's just really poor (and silly) reasoning honestly. A 12-yr old could look deeper. For instance:
-. Is 'writing' code all that matters?
-. Aren't there in fact 10s or 100s or 1000s more readers to code than writers (including the original author also as a reader)?
-. Do readers like to scroll between various blocks of logic and divine signal from noise by teaching their brain to ignore boilerplate?
-. And what if the brain at first sees something as boilerplate but only upon further examination finds a subtle difference in the pattern for this one rare instance?
-. And what if that happens when the programmer is investigating a long-standing bug that has just resulted in a great loss of human life (and will continue to do so)?
Rob, myself, and others have written tomes on this, on Hacker News, golang-nuts, and elsewhere. If you're trying to have an argument with Rob (he's not reading this, btw) over some pithy statement he made in February, you're wasting your time.
You've written tomes on how wasting vertical space and multiplying syntactic noise is a good idea? Even if so: ideas are not measured by the volume of noise you write in support of them.
You've written tomes on how wasting vertical space and multiplying syntactic noise is a good idea? Even if so: ideas are not measured by the volume of noise you write in support of them.
At the risk of prolonging this insufferable "conversation": my point is that it has been discussed to death, and you're being down voted because nobody is interested in discussing it with you, or even hearing you discuss it.
