Hacker News Reader

Comment by Sharlin | Hacker News Reader

  type planet int // Gravity[float64],RadiusKm[float64],MassKg[float64], ...

Sorry, but what? Is this really an ad-hoc DSL embedded in a regular comment that's then preprocessed by… something, to generate the actual Go code? Certainly there's something that sucks here!

Edit: I'd find it marginally less sucky if there at least were some special prefix like `//#` or `//my-preprocessor` or whatever to mark magical semantically significant comments. And what's the deal with the `field[type]` syntax that seems totally ad hoc, why not use the standard Go syntax `field type`?

View on HN

Horrible isn't it.

Not sure why they don't just use a struct with some fields, then just create instances of those instead of magic comments and a preprocessor.

https://go.dev/play/p/uUNHxM8zqY9

Mercury = {"Mercury",190.0,...}

It would not be any more verbose and would let them define constants for use elsewhere if they wish. If they want to control values for validity they can use a NewPlanet func.

I do agree go's enums suck but they need to take a step back and look at what they've created and what would be an easier way to create this if they really need it. It seems like they want real types here, not an enum and if they do want constant planet types it's very easy to make them without all this busywork.

> I do agree go's enums suck

There's not much more you can do with them. A enumeration is literally assigning a number to something. That is all. Enums suck, fundamentally.

Other language features, like value constraints, can help improve the experience of using enums, but, really, if we are inventing a language, why have enums at all? If you think you have a use case for enums, a more advanced type system will offer a better model for your problem.

Sure, enums were a clever hack in the days of yore when we didn't have a good grasp of type theory, but are pointless in a modern language. Of course, Go is purposefully trying to be a language of yore, so it stands to reason that it would have them and all the suckiness that goes along with it, but, again, if we want it to be a modern language then you don't need to hack on top of enums with new features to make them nicer. You can get rid of them entirely.

They clearly want an enum/sum type which an array of structs (which is the trivial solution they started at) doesn't provide.

You're seeing someone try to address their issues with X and suggesting "here's how you use X." It doesn't track.

Nope, I'm saying don't use X at all, because enums are not the right thing to use to solve this problem. This solution of magic comments and a precompiler is worse than not using enums at all.

That's idiomatic go. See https://go.dev/blog/generate and '//go:generate stringer -type=Pill'

See also '//go:embed', which also turns a variable into a magic type via an ad-hoc comment-only DSL.

In go, it is idiomatic to say "macros slow down compilation and often require a second pass, go compilation is fast, macros are bad", and then also to have an extra "make sure go generate is up to date" CI step which parses your go codebase 10 more times, forks dozens of processes, and isn't type-safe since of course it's not it's literally a comment you can typo "//gog:enerate" and no one will notice.

Worth noting that most go codebases don't contain magic comments like this.

I've certainly never used them and agree they are horrible in every way.

I frequently tell people that Go is my least favorite language for reasons like this and the response is often some form of the no true Scotsman fallacy.

Having to make ad hoc domain specific languages embedded in your comments that are then processed and expanded by entirely separate compilers, essentially reinventing the C macro preprocessor, is in my opinion the mark of a terminally underpowered language that even the people regularly using it realize is underpowered even if they don't admit it to themselves.

I don't understand what's wrong with using an actual DSL?

I have this ASDL generator I use for all my grammar parsing experiments (to build the AST to parse into) that it isn't all that complicated -- mostly because it has zero error checking -- and, if I understand TFA correctly, could be adapted to what they are attempting to do in about an hour. And most of the complexity comes from using mustache as the template language and having to read their docs every single time I want to change something.

True, it does add an extra build step and the reason it's 'simple' is because I've rewritten it at least three times (but that's mostly to learn how a new (to me) parser generator works) but it's now at the point where I can add new AST nodes in conjunction with filling out the grammar rules without having to really think about it. Oh, and I do kind of enjoy shaving yaks so there's that.

There’s a history of this sort of faked annotation thing in Go. The most notable example being comments used to denote how a struct’s fields are mapped to/from JSON.

The struct field tags thing (which are not comments) is at least something built into the language, that other code can access via reflection. Not being able to do this for this use-case, and having to rely on comments that are preprocessed by a code generator, is just a shame.

Maybe it's slightly better than total shit, but it's still pretty shit. Half the struct field tags aren't even typechecked, and will force you to go on hours long goose chases wondering why something isn't working only for you to realize eventually that 'someField string `db_orm_field_1:"0"' is actually supposed to be '"someField string `db_orm_field1:"0"'.

Something like this just doesn't happen in C#. Neither in runtime reflection based ORMs nor in code generation based (micro)-ORMs (which, unlike Go, does not need extremely clunky manual scripting and "just works").

Yeah extending the struct tags to iota definitions would have made things much better.

I believe back in the Java days, there are packages that are also doing something like this (comment preprocessor for generating code)

Those plugins would try to point out that the comments that they would preprocessed would look somewhat different from regular comment, e.g.

//this is a regular comment

//#while comments that start with '#' would be preprocessed.

It's still an issue that would shoot the foot of the next person who would maintain your code though.

Yes, I'd find it marginally less sucky if there at least were some special prefix like //# or whatever to mark magic semantically significant comments. And what's the deal with the `field[type]` syntax that seems totally ad hoc, why not use the standard Go syntax `field type`?

That is the whole Go mindset right there.

Yes, I think it's actually a decent way of doing it, given how limited golang is when it comes to enums. (Better might be to use tags, but I think they are only allowed on struct fields.)

I think codegen is generally fine for repetitive tasks. It's just a shame that golang doesn't give you a way to do this built-in. Even java has this feature, even if it's lacking in some regards.

Not sure if I understand you correctly, but Go has had a built-in way to do codegen for 10 years now: https://go.dev/blog/generate

Reply on news.ycombinator.com