Code Generation from the AST in Go | Hacker News Reader

Code Generation from the AST in Go

blog.gopheracademy.com

83 pointsbketelsen14 comments

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

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.

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

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.

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.

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.

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

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.

What if they are right, and saying no is the reasonable way to keep the language lean and efficient?

People think focus means saying yes to the thing you've got to focus on. But that's not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I'm actually as proud of the things we haven't done as the things I have done. Innovation is saying no to 1,000 things. - Steve Jobs

Is there anything preventing a fork of Go?

A tremendous amount of human labour?

http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

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

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

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

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

Reply on news.ycombinator.com