[MichaelSalib]

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?

[blablabla123]

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.

[pjmlp]

Generics exist in multiple forms since CLU (1974).

To reduce them to what C++ and Java implementations offer, is just being ignorant from history of programming languages.

[frowaway001]

> being ignorant from history of programming languages

Isn't that Go's design principle?

[NateDad]

People in the 70's knew a lot more about programming than you seem to think.

[frowaway001]

Yes, but they weren't so self absorbed to dismiss the 40 years of experience in front of them.

[NateDad]

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.

[zuzun]

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?

[logicchains]

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.

[pjmlp]

D, Rust, Nim(rod), Template Haskell, OCaml, C++...

[mseepgood]

I don't think these can open and read .proto files during compilation.

[pjmlp]

D has meta-programming and compile-time evaluation, including reading files.

I bet C++ can do it with some clear use of template metatprogramming, compile time evaluation and processor macros.

Nim has meta-programming capabilities, including reading files.

Not sure about Template Haskell, though.

[thesz]

Template Haskell code can runIO I/O actions, including reading files.

[pcwalton]

Rust can.

[tuxychandru]

Are you referring to compiler plugins like the one providing regex! macro or is it something else?

[wycats]

Yes, compiler plugins. For a relevant example, check out the Rust docopt crate[1].

An identical technique could be used for yacc or protobufs.

[1]: https://github.com/docopt/docopt.rs

[jeremyjh]

Haskell can, but there is not an implementation that does this.

[hawkice]

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

[ben0x539]

F# type providers sound like they're for this sort of thing. I expect Scala has a similar macro facility. Nemerle can probably do it too.

[NateDad]

I don't want my language to be that complicated. "Powerful" has nothing to do with it.

[personZ]

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?

[frowaway001]

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.

[vorg]

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

[shurcooL]

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.

[frowaway001]

That's a false dichotomy.

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.

[shurcooL]

> Go is just not a very good language.

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?

[frowaway001]

> but it is being improved

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.

[burntsushi]

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

[personZ]

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.

[codygman]

> Pure, idealized languages like Haskell seem to be preferred by people who don't actually do anything with it, but instead talk about it.

Please stop, you're making yourself look stupid. Plenty of people create real solutions to real problems in Haskell every single day.

[personZ]

Unsurprisingly, you and frowaway both average less than 2 on your comments.

[frowaway001]

You understand the difference between being right and being popular?

Because you like fancy numbers, let's assume you probably rate a 7 on being butthurt.