
Code Generation from the AST in Go - bketelsen
http://blog.gopheracademy.com/code-generation-from-the-ast/
======
inconshreveable
This is super cool work from Ian here.

Go is quickly engendering a renaissance in command line programs and other
services that run in hostile environments. I talked about this in my GopherCon
2014 talk: if you want to build quality code and deploy it into hostile
environments, you need good crash reporting. The conversion rate from crash ->
crash report is abysmal without automation, and it's critical to close your
quality feedback loop.

Crash-reporting is hard. Cross platform crash-reporting is harder. Cross-
platform crash-reporting for unsafe languages is harderer. Terrifyingly so:

[https://code.google.com/p/google-
breakpad/wiki/ClientDesign#...](https://code.google.com/p/google-
breakpad/wiki/ClientDesign#Exception_Basics)

Making this so easy that it's just an extra step in your build process is a
huge step forward. That it can work even on dependency code is hugely
important.

That's not to say it's without its tradefoffs, but I think this approach has
the best ratio of value to effort.

I'm looking forward to experimenting with this in deployed code to help me
catch bugs in the wild.

------
tomblomfield
"Go as a language is very opinionated... Go engineers are an anti-magic
crowd."

Great so far. But why does this always end up as....

"This tool... auto-generates the code for you"

~~~
aikah
My thought exactly. And now Go even has a code generator tool bundled with it
... I don't understand Go designers. This goes against everything they said Go
was. But 2 problems illustrate in my opinion the Go team mindset.

People want a package manager, the Go team says vendor deps.Well except
vendoring has nothing to do with managing lib dependencies.So there will be
multiple incompatible package managers.

People want generics(Go has generics,you just can't define your own generics)
, the Go team answers use "go generate", so people come up with their own
"generate generics from Go source files" tools which of course use
incompatible systems.

People want a spec for struct tags, the Go team says no.Why the hell would you
want to use struct tags if different libraries parse them different ways ?
What if a user wants to use 2 libs that use struct tags in an incompatible
way?

So basically the Go team isn't interested in 3rd party input,which is a choice
I respect,even if I don't agree.

the reason of all this is that the Go team isn't interested in adding new
features to the language, period, so they could care less about user
input,which IMHO will lead to language FRAGMENTATION eventually. (source :
changelog podcast :
[https://thechangelog.com/148/](https://thechangelog.com/148/) )

It's terrible because Go is this close to be the language most developers
would need and has great concurrency primitives unlike D or others.

~~~
meddlepal
Is there anything preventing a fork of Go?

~~~
mjburgess
A tremendous amount of human labour?

------
froh42
[http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule](http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule)

Writing code generators, inventing the wheel over and over again.

------
bouk
Code generation in Go is so fantastic. I made this in one late evening:
[https://github.com/bouk/go-faster](https://github.com/bouk/go-faster)

------
Dewie
> Maybe like me you use Fresh

> and you have a OCD of hitting save every 2-3 seconds as you are thinking

Please stop with this "OCD" bullshit.

------
frowaway001
It's kind of telling that they feel that they first need to tell Go developers
what an AST is ... PHP redux?

