It is a bit astonishing what lengths the go community is willing to, er, go, in order to avoid compile-time code execution (the basis of lisp macros) or generics. I understand that neither of these ideas were invented at Bell Labs during the 1970s, but at some point, can't we just put aside the not invented here syndrome?
Could we all just agree to pretend that Bell Labs folks invented those ideas? Would that work?
There have been many lengthy disucssions about generics on the Go mailing list. Haven't checked them in a while but the essence used to be that generics are difficult. C++ has really powerful generics but unfortunately C++ templates are in many respects a nightmare. Java templates on the other hand are not really powerful. The idea was to wait until someone would come up with a powerful generics concept that is nice for the developer.
Not all languages need to have all the features of Haskell or Rust. Just as not All languages need to be dynamically typed. Just because a language is missing your favorite feature(s), doesn't mean it's a bad language. And maybe you have tried writing programs in go and didn't like it. That's fine. But there's no need to insult everyone who uses language. Every language has its niche, even perpetual punching bags like vb and php.
> But there's no need to insult everyone who uses language.
Is that from Go's social media handbook? I have never ever seen users of a language complain about perceived insults as consistently as Go. It seems like it's the only argument they are able to make if they disagree with other people.
The only thing cute is the way you are desperately trying to come up with ways to turn "I don't like what you say" into "it's wrong what you say" in your head. :-)
So how many programming languages besides LISP are powerful enough to support turning Protocol Buffers into code during compilation? And is this the ultimate must have?
It could be done in OCaml or Haskell, considering they both have compile-time AST generation/manipulation, but I'm not sure if anyone's written an actual implementation of this. Nimrod too, as that has AST macros. As does Elixir.
To be clear for the Haskell newbies, he's talking about an implementation of the protobuf library, not Haskell. You can fairly easily lift from Template Haskell types into IO in GHC (not sure about TH in other compilers).
The Go community are out building solutions productively and fruitfully, often finding the lack of generics an edge nuisance, but something that is by no means a showstopper.
The people who have no knowledge or skill in Go, on the other hand, fill the message boards, railing rabidly about how absolutely critical generics are, and don't these people (who almost universally have extensive experience across a number of languages) know what they're missing?
The point you are missing is that people who don't want to live in the 1970ies avoid Go in the first place, so the Go community by definition consists only of people who think Java-1.0 style programming is perfectly fine in 2014.
Yes, there are reasons why the intended audience of Go just didn't care and Go is mostly used PHP, JavaScript, Python, Ruby etc, developers today.
> Go is mostly used PHP, JavaScript, Python, Ruby etc, developers today
Could be dynamic typing has had its day, just like visual programming from the 1990's. Or maybe users of those languages wanted to use one with a large corp backing it, like Java and C# have. The most common glib response I get when I say I'm trying out Go to write something is "You're using Go? So you wanna work for Google, do you?" Perhaps that shows the real motivation of why a programmer learns Ruby or Python or Go.
There are people who want their language to be as complicated and feature-rich as possible. They have lots of choices available, including C++1*, Java, Ruby, etc.
Those languages probably don't have anything that has only one idiomatic solution. Even writing a for loop will have multiple different but viable alternatives.
Then there are people who want their language to be as simple as possible, yet still powerful enough to allow you to create all the things you can with Go.
There are very few such languages. In fact, there are a few things/special rules I'd like to see simplified in Go because they have less benefit than cost.
Having a simple language allows for some cool benefits, and if Go starts to compete with C++ for number of features, it will lose its main distinctive property.
The desire for a simple language doesn't mean you have to accept all the mistakes Go made. Go is just not a very good language. It would be completely irrelevant without the Google name behind it.
It certainly could be better (this is true of everything that's not perfect), but it is being improved (and it's open source, so you and I can help make it better). I already prefer it over many other languages.
> It would be completely irrelevant without the Google name behind it.
You mean... It would be irrelevant if Google and other people who work on it (being open source, many contributors aren't Google employees) did not make it what it is?
That's like saying... <any product> would be irrelevant if <those who made it> didn't make it as good as it is. It is a true statement, but how is it useful?
The things I care about can't be fixed, because they are fundamentally wrong in Go, they are not just some little oversight.
> I already prefer it over many other languages.
If I would start aiming low enough, I could also certainly find languages which are even worse than Go.
Honestly, I don't care. I prefer languages which do things better than X, not languages which are less worse than X.
> You mean... [...]
Eh no? I meant what I said. If the people who created Go wouldn't have been able to leverage the Google name (either by working at a company or by Google saying "don't use our brand for your toy projects") nobody would have cared.
But people said "OMG, Google invented online search!!! Then–by definition–they have to be language design experts, too!!!" and the tragedy unfolded.
Fair enough, it sounds like your needs are very different from what Go satisfies.
Just out of curiosity, what language(s) do you prefer to use over Go?
> Eh no? I meant what I said. If the people who created Go wouldn't have been able to leverage the Google name (either by working at a company or by Google saying "don't use our brand for your toy projects") nobody would have cared.
I have a very good counter-example for you. Google also made Dart. I have no interest in Dart and I don't think it's anywhere near as good as Go from what I can tell about it.
> so the Go community by definition consists only of people who think Java-1.0 style programming is perfectly fine in 2014.
This is a false analogy because there are significant differences between "Java-1.0 style programming" and Go.
> Yes, there are reasons why the intended audience of Go just didn't care and Go is mostly used PHP, JavaScript, Python, Ruby etc, developers today.
Why do you feel the need to bin people? I'm a Haskell programmer and yet I love Go. In your world view, this is an impossibility. But maybe I've given you too much credit.
Go is mostly used PHP, JavaScript, Python, Ruby etc, developers today.
Go is absolutely preferred by people building real solutions to real problems. Pure, idealized languages like Haskell seem to be preferred by people who don't actually do anything with it, but instead talk about it. It is the "big brother" language.
I don't mean this dismissively, though it invariably sounds that way, but there is a huge divide between things that actually get things done, and things that you can debate the intricacies of for weeks on end while you foment that grand plan that you'll never actually pursue.
Though I will add that your nonsensical, ignorant simplification and mischaracterization of Go merely belies the fact that you have virtually no real knowledge of it at all, beyond probably some rubbed off "knowledge" from advocacy boards.
Could we all just agree to pretend that Bell Labs folks invented those ideas? Would that work?