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`?
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.
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.
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.
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.
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").
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`?
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.
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`?