Hacker News Reader

Comment by adgar | Hacker News Reader

It seems you deleted your comment asking why you were downvoted. Here's why you were downvoted:

> Way more than 5 minutes. Where are generics or do I have to learn some new construct? Wait a minute, is this thing object oriented or what? If not, why not? Do I have to learn some new philosophy? Already feeling a sense of dread having been through this game 10s of times before with other languages.

If you didn't get past the fact that Go isn't object oriented, then you clearly didn't get very far into the language. And your resistance to "some new philosophy" shows you aren't interested in a new language with real ideas, but at most a different way to express what you already know and do while programming.

View on HN

It was no longer relevant and seemed to attract more downvotes. I have spent years with x86 + MIPS assembly language, C, C++, C#, Visual Basic and Q[uick]BASIC; months with Java, Scheme, Python, PHP; days/weeks with AS3, HaXE, Erlang, Scala, E, Objective-C, Ruby, Delphi, Pascal, Concurrent Clean, Prolog, ADA. I've probably missed a few.

My point is (a) I'm not a lazy developer that doesn't enjoy learning new things or experimenting with new languages and (b) I have found a great ecosystem in .NET and C# and I've been around the block; at first sight I simply cannot see a compelling reason to invest more of my increasingly limited time into learning Go.

If Go has great new vision or compelling difference from other languages then why isn't it there on the homepage at golang.org jumping out at me? All I see are technical details and a huge guide. While I applaud clear, detailed documentation, I'm not going to read through that documentation unless I have some idea of the payoff. I just spent half of my weekend researching and investigating a ton of message brokers for my current project because there's value in the outcome. Researching a new programming language needs to have a huge payoff, or I need to have lots of free time (which unfortunately I don't).

There is absolutely nothing to sell me on the language on the homepage, or in the OP's blog post, and nothing to distinguish it from the 10s of other new languages out there. The FAQ touches on the fact that e.g. it's not object-oriented but not WHY. It just mentions "interfaces" and says "we believe". So I'll have to go and play with it and build something substantial to find out what they might be talking about. The goals mentioned in the FAQ are really not interesting (have you read it?) - perhaps the ideas around concurrency are convenient but they are limited in scope and don't directly address the more complex concurrency issues better than my current platform that I'm facing while I build a web crawler.

To be clear once again: It may be that Go is absolutely amazing and awesome... but if I had to spent days looking into every new language that pops up on the Internet I would never get anything done, and this is the point I was trying to convey in response to the parent's post. It's still on my list to look into but I just don't have a week to commit to what looks like quite a lot to manually digest.

Given all the languages you already programmed with, and given that the Go specification is relatively short (approximately the same as Scheme), maybe you overestimate the efforts it would require to learn it. But you don't need to, that's all fine.

Heh I think you inadvertently proved my point. I spent 6 months with Scheme, working through half of the SICP for personal growth. Just because the specification is simple it doesn't mean the patterns and lessons are straightforward, and I'm a pretty slow learner. If you read the Go FAQ you will note that about 1/3 of it is along the lines of "Why doesn't Go...". When I see that sort of language it's clear that between the lines there's a lot to learn, and the only way for me to learn a language is to write code.

But after all of this I think I'm going to have to write one of my site-specific crawlers in Go for fun; since Go has a STOMP binding it should be easy to integrate into my existing architecture. Where things will get interesting is finding a compatible serialization library (and so we start getting into the real world problems of using a new language to solve interesting problems... hopefully one of the .NET protocol buffer implementations will work correctly with the one I imagine exists for Go).

> hopefully one of the .NET protocol buffer implementations will work correctly with the one I imagine exists for Go

That's one of the primary points of protocol buffers ;-)

you have nailed wisdom to these younger 16 years old crowd. But nowadays younger crowd needs fashion,pizzaz,Prestige etc. in my experience learning about Message Brokers is very important than learning new language.

I think the "Where are the generics" is the bigger issue there.

Why do you feel that? From the Go FAQ, which now I feel obliged to at least read in its entirety because of how much heat this post has stirred:

"Why does Go not have generic types?

Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do.

We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in [functionality] mean in many cases it is possible to write code that does what generics would enable, if less smoothly.

This remains an open issue."

Clearly the designers of Go consider generics a topic worthy of debate.

But apparently you consider "no generics" a deal-breaker without seeing why generics haven't been added yet, and why it isn't an issue for the many developers writing real-world production Go code.

I'm confused. I never called it a deal-breaker, just a surprise. The language designers, in their FAQ, acknowledge it as an opinionated gap where their own opinion hasn't been fixed, so I'm not imagining it as a gap either.

Your comment about "real-world" code is even more puzzling, as if all "real-world" code is somehow equivalent in abstraction needs. There are guys who've written serious code running in billions of cellphones where generics would be unimportant. Same thing for scientific or massive data crunching applications, e.g. Google's infrastructure.

In the space I work in - enterprise applications integrating large, disparate systems where you have zero control over interfaces and data formats but somehow need to get everything talking together nicely, generics are invaluable in structuring your code and making it reusable.

To be fair, I happen to be building a little search engine of my own and Go may turn out to be great for building the crawler components (the processing is site-specific), and I may end up using it for that purpose if I have the time to explore it or see value in it (if I find memory pressure to be an issue then saving 1/3 RAM on my EC2 instances over C# is a definite win, but since most of the work is I/O constrained I may never run into an issue at all).

> In the space I work in - enterprise applications integrating large, disparate systems where you have zero control over interfaces and data formats but somehow need to get everything talking together nicely, generics are invaluable in structuring your code and making it reusable.

Luckily for you, Go already solves these problems incredibly naturally! Unfortunately, you haven't looked into how Go solves those problems, primarily through its interfaces and type embedding, plus its slices and so on are already generic.

It's true they aren't sure if they need it or not, but you clearly haven't looked into many feel they are unnecessary and that the present language is more than sufficient for solving many needs. In fact, Go is almost explicitly designed to handle the production cases you tackle. But it seems you've said in other threads that learning new approaches isn't really worth it for you, in which case, it's unsurprising that new languages aren't offering you much.

I'm not sure interfaces are really the "incredibly natural" solution. Why, for example, should a container care about what interface its contained element implements? A list is really agnostic of such things and forcing an interface on the item is silly, just to contain it.

Reply on news.ycombinator.com