8 ms·

Motivating examples include: macros: generating customized implementations given generalized packages, such as sort.Ints from ints If this is seriously th

Motivating examples include: macros: generating customized implementations given generalized packages, such as sort.Ints from ints If this is seriously their proposed solution to the lack of generics then my estimation of Go just dropped even further.

MichaelSalib 12y ago
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?
- zuzun 12y ago
  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 12y ago
    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 12y ago
    D, Rust, Nim(rod), Template Haskell, OCaml, C++...
    - mseepgood 12y ago
      I don't think these can open and read .proto files during compilation.
      - pcwalton 12y ago
        Rust can.
        tuxychandru 12y ago
        Are you referring to compiler plugins like the one providing regex! macro or is it something else?
        wycats 12y ago
        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 https://github.com/docopt/docopt.rs
      - pjmlp 12y ago
        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 12y ago
        Template Haskell code can runIO I/O actions, including reading files.
      - jeremyjh 12y ago
        Haskell can, but there is not an implementation that does this.
        hawkice 12y ago
        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 12y ago
    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 12y ago
    I don't want my language to be that complicated. "Powerful" has nothing to do with it.
- personZ 12y ago
  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 12y ago
    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 12y ago
      > 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 12y ago
      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.
- blablabla123 12y ago
  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 12y ago
    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 12y ago
      > being ignorant from history of programming languages Isn't that Go's design principle?
      - NateDad 12y ago
        People in the 70's knew a lot more about programming than you seem to think.
        frowaway001 12y ago
        Yes, but they weren't so self absorbed to dismiss the 40 years of experience in front of them.
        NateDad 12y ago
        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.
tptacek 12y ago
It sounds like this is just a clean way to run yacc and protobufs. And: using yacc from Golang programs is in fact ugly right now; it's actually a little worse than it is in C. I think you should just take this document --- whatever it's provenance --- at face value.
- 4ad 12y ago
  > using yacc from Golang programs is in fact ugly right now Why do you say that, and how does this mechanism affect the use case you have in mind? You run go generate instead of make. The advantage is that you don't have to have make; e.g. Windows and Plan 9 don't have make. Arguably, the advantage is pretty minor, but I don't see how it changes anything in your workflow. Remember that go generate does not run at build time. You still have to run it manually when you want it (just like before, with make) and commit the generated files into your repository.
  - tptacek 12y ago
    It's possible that I am just missing a trick that everyone else who uses Golang knows, but I never use "make" with go. (That's what makes yacc so much simpler with C; it's just another Makefile production.)
    - 4ad 12y ago
      It's not uncommon in Go programs to have makefiles (or shell scripts) that make some transformation to the code. This imposes no burden to the user since the generated files are checked into the repository, but it does put some burden on the developer (who has to run make), or to the prospective contributor, who not only has to have make, but potentially has to have all other tools invoked by make or learn the varying non-standard mechanism by which code is generated (e.g for the Go project itself, a new developer has to learn how to use the various shell and perl scripts that generate the code in the syscall package). Go generate does not eliminate this burder for the developer. Someone still has to write the yacc invocation and remember to run it; it won't know how to run itself, but it has the advantage that now there is a standard canonical way to generate code. Anyone can just type go generate instead of learning about makefiles or shell scripts or whatever the project is using. Code generation is normalized under the go generate umbrella.
jasode 12y ago
>If this is seriously their proposed solution to the lack of generics then my estimation of Go just dropped even further. On a related note, in one of the videos with Rob Pike (audience q&a I think but can't remember if it was GopherCon2014 or other event), he specifically mentions external "code generators" as a workaround for lack of generics. If anyone (not saying you specifically) is saying that the Go team is proposing code generators as the solution instead of a workaround to lack of generics, that would be an inaccurate reading of their position.
- weitzj 12y ago
  I heard something similar from a talk about Youtube Vitesse at Fossdem 2014. They are suggesting gofmt for rewriting.
NateDad 12y ago
It's not about generics. It's just a helpful part of the tooling to do some stuff before you compile. Like many projects already do, this just standardizes it.

MichaelSalib 12y ago

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?

zuzun 12y ago
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 12y ago
  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 12y ago
  D, Rust, Nim(rod), Template Haskell, OCaml, C++...
  - mseepgood 12y ago
    I don't think these can open and read .proto files during compilation.
    - pcwalton 12y ago
      Rust can.
      - tuxychandru 12y ago
        Are you referring to compiler plugins like the one providing regex! macro or is it something else?
        wycats 12y ago
        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 https://github.com/docopt/docopt.rs
    - pjmlp 12y ago
      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 12y ago
        Template Haskell code can runIO I/O actions, including reading files.
    - jeremyjh 12y ago
      Haskell can, but there is not an implementation that does this.
      - hawkice 12y ago
        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 12y ago
  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 12y ago
  I don't want my language to be that complicated. "Powerful" has nothing to do with it.
personZ 12y ago
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 12y ago
  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 12y ago
    > 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 12y ago
    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.
blablabla123 12y ago
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 12y ago
  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 12y ago
    > being ignorant from history of programming languages Isn't that Go's design principle?
    - NateDad 12y ago
      People in the 70's knew a lot more about programming than you seem to think.
      - frowaway001 12y ago
        Yes, but they weren't so self absorbed to dismiss the 40 years of experience in front of them.
        NateDad 12y ago
        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.

tptacek 12y ago

It sounds like this is just a clean way to run yacc and protobufs. And: using yacc from Golang programs is in fact ugly right now; it's actually a little worse than it is in C. I think you should just take this document --- whatever it's provenance --- at face value.

4ad 12y ago
> using yacc from Golang programs is in fact ugly right now Why do you say that, and how does this mechanism affect the use case you have in mind? You run go generate instead of make. The advantage is that you don't have to have make; e.g. Windows and Plan 9 don't have make. Arguably, the advantage is pretty minor, but I don't see how it changes anything in your workflow. Remember that go generate does not run at build time. You still have to run it manually when you want it (just like before, with make) and commit the generated files into your repository.
- tptacek 12y ago
  It's possible that I am just missing a trick that everyone else who uses Golang knows, but I never use "make" with go. (That's what makes yacc so much simpler with C; it's just another Makefile production.)
  - 4ad 12y ago
    It's not uncommon in Go programs to have makefiles (or shell scripts) that make some transformation to the code. This imposes no burden to the user since the generated files are checked into the repository, but it does put some burden on the developer (who has to run make), or to the prospective contributor, who not only has to have make, but potentially has to have all other tools invoked by make or learn the varying non-standard mechanism by which code is generated (e.g for the Go project itself, a new developer has to learn how to use the various shell and perl scripts that generate the code in the syscall package). Go generate does not eliminate this burder for the developer. Someone still has to write the yacc invocation and remember to run it; it won't know how to run itself, but it has the advantage that now there is a standard canonical way to generate code. Anyone can just type go generate instead of learning about makefiles or shell scripts or whatever the project is using. Code generation is normalized under the go generate umbrella.

jasode 12y ago

>If this is seriously their proposed solution to the lack of generics then my estimation of Go just dropped even further. On a related note, in one of the videos with Rob Pike (audience q&a I think but can't remember if it was GopherCon2014 or other event), he specifically mentions external "code generators" as a workaround for lack of generics. If anyone (not saying you specifically) is saying that the Go team is proposing code generators as the solution instead of a workaround to lack of generics, that would be an inaccurate reading of their position.

weitzj 12y ago
I heard something similar from a talk about Youtube Vitesse at Fossdem 2014. They are suggesting gofmt for rewriting.

NateDad 12y ago

It's not about generics. It's just a helpful part of the tooling to do some stuff before you compile. Like many projects already do, this just standardizes it.