4 ms·

Code Generation from the AST in Go

83 points by bketelsen 12y ago

inconshreveable 12y ago
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#Exception_Basics https://code.google.com/p/google-breakpad/wiki/ClientDesign#... 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.
Dewie 12y ago
> 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 12y ago
It's kind of telling that they feel that they first need to tell Go developers what an AST is ... PHP redux?
tomblomfield 12y ago
"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"
- Supermighty 12y ago
  There is a difference between magic and automation. Magic is about obfuscation, hiding, and keeping the programmers only using the surface tools. You can auto-generated code as long as the programmers know the what and why for.
  - aikah 12y ago
    There is no difference between magic and automation. I'd say magic is better because you don't need third party tools, it's baked in the language,documented officially, testable, and doesn't need one to type "Go generate" in a terminal. I hate to say that , but at this point, C macros looks better than what the go team decided to do.And I hate C macros.
  - bsaul 12y ago
    Reminds me a bit of the way java first did aspect oriented programming. Compared to how .net does it, one can see how much better it is when a critical part of a language is actually taken care of inside the language itself, rather than as a separate process.
- aikah 12y ago
  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.
froh42 12y ago
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 12y ago
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

83 points by bketelsen 12y ago

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#Exception_Basics https://code.google.com/p/google-breakpad/wiki/ClientDesign#... 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.

Dewie 12y ago

> 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 12y ago

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

tomblomfield 12y ago

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

Supermighty 12y ago
There is a difference between magic and automation. Magic is about obfuscation, hiding, and keeping the programmers only using the surface tools. You can auto-generated code as long as the programmers know the what and why for.
- aikah 12y ago
  There is no difference between magic and automation. I'd say magic is better because you don't need third party tools, it's baked in the language,documented officially, testable, and doesn't need one to type "Go generate" in a terminal. I hate to say that , but at this point, C macros looks better than what the go team decided to do.And I hate C macros.
- bsaul 12y ago
  Reminds me a bit of the way java first did aspect oriented programming. Compared to how .net does it, one can see how much better it is when a critical part of a language is actually taken care of inside the language itself, rather than as a separate process.
aikah 12y ago
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.

froh42 12y ago

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 12y ago

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