Not really related to the topic, but one of the things that I most dislike in Go is the heavy usage of magic comments.
I understand the idea that they want new code to be parsable in older versions of the language, but considering how heavily the language relies on magic comments I can’t see why it didn’t had a preprocessor marker like C and # instead.
I wouldn’t stay it’s “heavy”, more like a sprinkling. There are only three magic comments that are generally used (build, embed, generate) and even then it’s sparingly. Grafana’s Tempo has ~170k lines of Go and only 5 of those lines are //go: directives. A very large class of programs will never use any of them.
It really depends, for example I have a small project of around 2k lines of code in Go and I had to use multiple build flags since the code is for a desktop application and I had to create different code paths for Linux/macOS/Windows.
It is even worse if you need to use CGo, since if you need to embed C code you basically need to write C code as comments. And since they’re comments, you don’t have syntax highlight at all (or at least I don’t know one text editor that supports it, and my Neovim does support embedded code since it works fine in Nix).
Now keep in mind that in general I don’t think it is a huge issue, but I still think the language would have been more elegant if it had something else to do those transformations. But again, this is Go, so maybe being ugly is better.
Quick reply, but it’s more about being simple rather than ugly. A preprocessor is even more magical and unwieldy than magic comments. C code often has endless runs of #ifdef ... #ifndef ... to separate build platforms making the code mostly unreadable. Not to mention the magic macros that change the code from underneath your feet so you don’t even know what you’re reading.
Even Rust’s macros allows one to create their own little language which no one else understands. Given how the express purpose of Go was to be easy to read for anyone not familiar with the codebase that’d have been a non-starter.
I figure the Go authors wanted, rightfully, to steer clear of the mess that is preprocessors.
Maybe I was not clear, I was not suggesting for Go to have a preprocessor, just that those kind of magic be indicated with a symbol different from comments. I suggested that it could be the marker of preprocessor in C (e.g. #), but not that this is a preprocessor per see.
The idea is because this creates a clean separation between what a comment is and what is something special interpreted by the compiler. Something that was different so it is easier to see that it is doing something, e.g. have different syntax highlight for it.
Not really related to the topic, but one of the things that I most dislike in Go is the heavy usage of magic comments.
I understand the idea that they want new code to be parsable in older versions of the language, but considering how heavily the language relies on magic comments I can’t see why it didn’t had a preprocessor marker like C and
#instead.But anyway, I know that the ship already sailed.
I wouldn’t stay it’s “heavy”, more like a sprinkling. There are only three magic comments that are generally used (build, embed, generate) and even then it’s sparingly. Grafana’s Tempo has ~170k lines of Go and only 5 of those lines are
//go:directives. A very large class of programs will never use any of them.I think that’s a pretty good deal.
It really depends, for example I have a small project of around 2k lines of code in Go and I had to use multiple build flags since the code is for a desktop application and I had to create different code paths for Linux/macOS/Windows.
It is even worse if you need to use CGo, since if you need to embed C code you basically need to write C code as comments. And since they’re comments, you don’t have syntax highlight at all (or at least I don’t know one text editor that supports it, and my Neovim does support embedded code since it works fine in Nix).
Now keep in mind that in general I don’t think it is a huge issue, but I still think the language would have been more elegant if it had something else to do those transformations. But again, this is Go, so maybe being ugly is better.
Quick reply, but it’s more about being simple rather than ugly. A preprocessor is even more magical and unwieldy than magic comments. C code often has endless runs of
#ifdef ... #ifndef ...to separate build platforms making the code mostly unreadable. Not to mention the magic macros that change the code from underneath your feet so you don’t even know what you’re reading.Even Rust’s macros allows one to create their own little language which no one else understands. Given how the express purpose of Go was to be easy to read for anyone not familiar with the codebase that’d have been a non-starter.
I figure the Go authors wanted, rightfully, to steer clear of the mess that is preprocessors.
Maybe I was not clear, I was not suggesting for Go to have a preprocessor, just that those kind of magic be indicated with a symbol different from comments. I suggested that it could be the marker of preprocessor in C (e.g.
#), but not that this is a preprocessor per see.The idea is because this creates a clean separation between what a comment is and what is something special interpreted by the compiler. Something that was different so it is easier to see that it is doing something, e.g. have different syntax highlight for it.