"I want all this <-done synchronizations and select sacramentals to be entire hidden"
Then perhaps Go is not the language for you. There are a lot of design decisions in Go that seem arbitrarily restrictive at first but are there, AFAICT, to (as much as is reasonable) force programmers to write code where what is happening is explicit and obvious without having to dive down into layers and layers of abstraction to find "the magic".
Go has plenty of "magic": garbage collection, maps, slices, channels, goroutines. It just wants you to stick to the abstractions provided by the language and not create your own.
This is fine, it's a design goal of the language, but it's unsurprisingly frustrating for people used to more expressive languages.
> but it's unsurprisingly frustrating for people used to more expressive languages
Speak for yourself. I know you certainly don't speak for me. I love Go. I love Haskell. I love Rust.
There are things in all languages that frustrate me. I can appreciate the particular trade offs made in each language. Believe it or not, I think the language specifications for both Haskell and Go are things of beauty. It's amazing how close the core of Haskell is to just a simply typed lambda calculus. It's amazing at how Go can be so well specified in such a short document with near perfect orthogonality in the language.
Many of your comments in this thread read (to me) as if you're speaking from a position of authority on what the right design for a language is. I think your comments would be better received if you expressed your thoughts as opinions rather than as things you consider facts.
I don't know what in my comment suggests that you can't love both Haskell and Go, but that's certainly not what I meant. Nothing I've said here is anything other than my own observation and opinion.
> I don't know what in my comment suggests that you can't love both Haskell and Go
I quoted it in my comment. You said: "but [Go is] unsurprisingly frustrating for people used to more expressive languages." I'm used to more expressive languages too, but I don't find Go frustrating. Therefore, your statement is false.
You probably intended it to read like: "I am unsurprisingly frustrated with Go because I prefer more expressive languages."
Many of your other comments are similarly phrased. The read as if you are privy to some truth that people who like Go do not understand.
I wasn't making a statement about myself at all. The tradeoffs involved in Go's design are well-known, well-explained, and intentional. There is a great deal to admire and respect about Go and its community. Hell, my first comment in this thread was noting that Go's design makes it particularly easy to learn.
If it helps, substitute "it can be frustrating" for "it's frustrating".
I am unsurprisingly frustrated with Go because I prefer more expressive languages, fwiw.
(...and no, I don't think it's particularly wrong to assert that this is the case for other people too; there's plenty of evidence to support that people find the lack of generics in a fully featured language like go frustrating; and it's not surprising what so ever that this is the case)
> I am unsurprisingly frustrated with Go because I prefer more expressive languages, fwiw.
So? My point was not to claim the opposite of the OP, it was to point out that the generalization is false.
> (...and no, I don't think it's particularly wrong to assert that this is the case for other people too; there's plenty of evidence to support that people find the lack of generics in a fully featured language like go frustrating; and it's not surprising what so ever that this is the case)
I guess, if your evidence consists of people on HN and reddit complaining about Go.
A majority of all people who use go? Certainly not.
...but consider that if you see lots of people complaining about something, its possibly not because they're all idiots, or pretentious self important HN posers (who certainly do exist).
The key issue being raised in this thread is that the golang community is dismissive of complaints, even when there are lots of them. and there are, quantitatively, lots of complaints.
That doesn't mean go is a bad language; it means its a popular language in the spot light, and its maintainers and community should probably make a bit of effort to be slightly more humble about that, rather than themselves becoming a pretentious 'there no problem here' self agreeing community.
I think thats a very valid concern, worth thinking about.
(and to be clear; I like go, but I dont visit golang-nuts anymore, because of the community there)
> ...but consider that if you see lots of people complaining about something, its possibly not because they're all idiots, or pretentious self important HN posers (who certainly do exist).
My only point was that just because you like languages like Haskell, that doesn't mean you can't have a fun time with Go. The reason why I said it was to push back against this notion that generics are clearly necessary in all modern languages. We should embrace alternative designs and consider them for the trade offs they make, not denigrate them as objectively incorrect.
If I had it my way, a good discussion of language design withholds judgment and outlines the trade offs. Once the trade offs are made clear, we can start to express opinions (or needs or judgments) based on which ones we want to make. This avoids the popular notion that there is some sort of minimal feature set that makes a language minimally viable.
FYI, these are not well formed thoughts. You could probably poke holes in them, but at the end of day: we should endeavor to balance trade offs in lieu of speaking from authority. (I'm not saying you are doing that, but certainly, others in this thread are.)
> The key issue being raised in this thread is that the golang community is dismissive of complaints, even when there are lots of them. and there are, quantitatively, lots of complaints.
What do you mean by "dismissive"? Most of the popular criticisms have been hashed out repeatedly on golang-nuts. Usually it comes down to the fact that a particular feature doesn't have a known implementation that fits into the design goals of the project.
The design goals are important because they say up front, "Here are the things we think are important and our project will be based on those things. If you think there are other things that are more important, then this project may not be for you."
That isn't dismissive IMO. It is an explicit statement of project scope.
> rather than themselves becoming a pretentious 'there no problem here' self agreeing community.
The problem is that they acknowledge the value of generics but don't know how to incorporate it without sacrificing other goals that are paramount to the project.
Just as you think Gophers blissfully cover the ears in wild ignorance, so to do they think that plenty of others aren't acknowledging trade offs. There is truth on both sides here. It is quite agreeable to say, "I have a really hard time programming without generics, so Go just isn't for me." It is quite another to say, "Go doesn't even have generics? Wow, they just ignored 3 decades worth of PL research."
> (and to be clear; I like go, but I dont visit golang-nuts anymore, because of the community there)
Yes, the community can be very thorny. But I can't blame them. They've been ruthlessly attacked since the start (generics, nulls, exceptions) for preferring a Worse Is Better approach to solving problems.
I find your response condescending and hostile, actually. The parent was making a basic generalization; he didn't categorically claim that his statement applied to all people.
People de facto speak in the form of opinions, and if we are all to qualify our statements with "...in my opinion" for fear of accidentally making an authorative statement, then HN would become a very unhappy place.
> I find your response condescending and hostile, actually.
I don't follow. The rest of your comment posits an argument for why you think I was wrong. If you're going to accuse me of being condescending and hostile, then I think you at least owe me the courtesy of explaining why.
> People de facto speak in the form of opinions
I agree.
> and if we are all to qualify our statements with "...in my opinion" for fear of accidentally making an authorative statement, then HN would become a very unhappy place.
I did not say we should do that.
> The parent was making a basic generalization; he didn't categorically claim that his statement applied to all people.
In a discussion of design trade offs, it is important to distinguish between technical fact and opinion. In language design in particular, it is too easy to conflate these things. This thread, for example, is full of it. (For and against Go, FWIW.)
You don't consider condescension and hostility to be "wrong"?
To be explicit, then, I think your comment's tone was inappropriate for HN. You're taking a generalization and expressing displeasure in the fact that the generalization seems to have inadvertedly included you, and then blaming the commenter for having done so.
You have to be deliberately obtuse to assume that the parent's statement was intended as absolute fact. It doesn't matter if we're discussing technology, this is a conversation, not a textbook; it's a normal part of discourse to give the other party a little slack and not treat every utterance literally and in absolute terms.
> You don't consider condescension and hostility to be "wrong"?
Huh? I used "wrong" in the sense, "your argument is incorrect," not, "you shouldn't do that," precisely because your comment explained how you disagreed with me (not why you thought I was being a jerk). In that way, "wrong" and condescension/hostility are orthogonal concepts.
> You have to be deliberately obtuse to assume that the parent's statement was intended as absolute fact. It doesn't matter if we're discussing technology, this is a conversation, not a textbook; it's a normal part of discourse to give the other party a little slack and not treat every utterance literally and in absolute terms.
I stand by what I said. I don't know what textbooks have to do this. I'm not asking for rigorous debate here. I'm asking for a modicum of clarity in a type of conversation where clarity is important.
I agree that we should give each other a little slack. But I also think we should encourage clarity where we think it is necessary. I think it is necessary in this context.
> You have to be deliberately obtuse
But thanks for the insult all the same. Do you think that is appropriate for HN?
A snarky comment, but I experienced the same on the golang-nuts mailing list. If you dare to question conventional wisdom be prepared to be shot down rather unceremoniously.
At least by now, they updated their docs a little bit.
I still think the "How to Write Go Code" article, which most beginners will encounter, is absolutely misleading by its advocacy of 'go get' - I cannot envision a universe where 'go get' makes sense. You absolutely have to vendor your dependencies if you want any kind of stability with your project.
> You absolutely have to vendor your dependencies if you want any kind of stability with your project.
I have several open source Go projects and I have been maintaining them for years by just using `go get`. I've never once had a stability problem because of it.
Of course, your point is absolutely correct. But I'm pointing out that `go get` can absolutely be useful in some universes. In fact, it's one of the things I love most of the Go toolchain.
So, umm, can we stop presupposing that everyone else's opinion and experience is just wrong?
My explanation is that there is some kind of positive feedback loop involved:
(1) Go developers/creators think they are really really smart.
(2) Experienced developers see their flaws, stay away from Go, and never participate in the mailing list.
(3) Clueless developers join the mailing list and ask simple/stupid/beginner questions. Go developers can easily answer them, reinforcing their self-assessment in (1).
It's a scary feeling watching their echo chamber ...
My experience interacting with the Go community on golang-nuts was generally pleasant and productive. I haven't experienced or witnessed any hostility, except maybe some hotted debates, but they happen on all programming languages mailing lists. What makes you think the Go community can be hostile?
If there's any magic on that list, it's limited to the garbage collector, and to whatever extent it's magic, that magic would vanish if it were based on strict automatic reference counting.
The others are conveniences to avoid subtle bugs and millions of developers writing the exact same code in every project.
I've mentioned this before, but my experience is that "expressive" is synonymous with "obfuscated". Go helps us in writing clear, maintainable code, not clever code.
Generics also are a convenience to avoid subtle bugs and millions of developers writing the exact same code in every project. That's precisely what they're for.
Any abstraction can be "magic" to people who don't find it appealing or useful. Go includes some of those abstractions and excludes others, like any language. I don't know of any consistent criteria by which the abstractions Go provides are non-magic and the ones it eschews are magic.
My criteria for magic is basically "this is difficult for the average developer to reason about the behavior of". With the exception of garbage collection (with the "asterisk" I mentioned), the things you listed are minimal abstractions which are very easy to reason about.
We all understand how maps, slices, channels, and goroutines work. Their behavior is simple and mostly predictable. Developers working in C wrote these or analogous systems all the time. Over and over again, albeit commonly with subtle errors, particularly with regard to concurrency.
Slices and maps (or their close equivalents) are universal. They exist in a generic form in Go because everybody needs them, in pretty much every significant codebase. There aren't many other data structures for which that is true. Perhaps as importantly, many nontrivial codebases don't really need much in the way of other data structures.
Concurrency features are less universal, but are also the source of many critical bugs. One might reasonably say concurrency is inherently magic under my criteria, but unfortunately some form of it is unavoidable. Go's concurrency primitives at least make it easier to avoid common errors while minimizing additional magic.
My personal problem with adding generics directly to Go is not that they are magic, exactly (which I think you may have misinterpreted georgemcbay's comment to imply), but that they lead easily to magic. Go discourages overengineering, which is a common outcome of certain people applying generics (and there are a lot of those certain people, and I've had the misfortune to deal with their code throughout my career).
What I would like is for something like gen to become the de-facto standard (presumably in conjunction with the generate feature proposed for Go 1.4). I doubt if I'd use it much myself, but that outcome would at least placate demands for generics without making it all that easy to obfuscate what is actually going on in the Go code.
What exactly do you mean by "magic"? Most of the time when I hear people talk about "magic" they usually mean a theory or abstraction that they don't understand or don't want to understand. Are generics magical in your opinion?
What makes things magical or not (the way I think of magical) isn't about the theory of the feature but rather how they are implemented and how much is hidden from the person using them in terms of code complexity and just overall work being done relative to what they think they did.
I'm perfectly comfortable with the "theory of generics", but when generics first came on the scene for C++ back during the time period I used to program primarily in C and C++ they were very magical. Not on the run-time side where the eventual result of any sane compiler is easy to understand, but magical on the compile-time side where when using them it was nearly impossible to determine how much time they would add to the overall compilation and how complex and unreadable the error messages would be if you had a problem. When you make a single simple syntax error and the compiler presents you with an error that is 2 pages long that is the result of an implementation that is, IMO, very "magical".
There is a bit of contradiction in your definition then. I don't think anyone using Go understands how the compiler does all the transformations necessary to get from Go to machine code. In that sense Go as a whole is pretty magical but you seem perfectly happy with that.
Modern application programmers and even system programmers by your definition rely on a lot of "magic". Even the machine code these days is a layer or two removed from the actual metal with all the caching and microcode that reside on the CPU.
Go doesn't prevent "magic", it just makes you hide the magic in ugly places.
Can't have a flexible iterator system because it might introduce complexity? Better just hide complexity in a next() function.
Can't have generics (except for the google-approved map, slice, chan...) because it might introduce complexity? Better just shift that complexity to unsafe use of interface{}.
It doesn't "prevent" "magic", but it "highly discourages" it.
And again, I think it is a feature and not a bug.
I didn't always think that way, I had a really rough start with Go because I was using it as if I were programming in a slightly different dialect of C++ which it isn't. When I write Go as if it is Go, I just don't see these "missing features" as problems at all.
But this debate has been going back and forth since Go was first made public, so anyone who has tried Go and dismissed it based on these lack of features is unlikely to be persuaded otherwise here and they should continue to use other languages until such a time as Go supports what they want (if ever). That's the beauty of having so many languages to choose from.
I pasted this in the gist comments, and I'll reproduce it here from Hoare's Communicating Sequential Processes: [0]
> But the dangers of convenient facilities are notorious. For example, the repetitive commands with input guards may tempt the programmer to write them without making adequate plans for their termination; and if it turns out that the automatic termination is unsatisfactory, reprogramming for explicit termination will involve severe changes, affecting even the interfaces between the processes.
Then perhaps Go is not the language for you. There are a lot of design decisions in Go that seem arbitrarily restrictive at first but are there, AFAICT, to (as much as is reasonable) force programmers to write code where what is happening is explicit and obvious without having to dive down into layers and layers of abstraction to find "the magic".
This is, IMO, a feature and not a bug, but YMMV.