I don't think it's the "least amount of magic". A lesser amount of magic would be what rust has: let s = include_bytes!("./file.txt");

As a bonus, if you typo the "include_bytes!" macro, as say "includ_bytes", you get a compiler error.

With the go one, if you typo it as "//gp:emebd hello.txt", then you get no compilation error, just an empty string.

If someone compiles your program with an old version of the go compiler, they get no error, just a totally broken program.

Meaningful comments are some of the worst magic you can add to a language IMO.

It's far simpler to reason about compiler-checked preprocessor instructions or macros, both of which are valid alternatives the go team could have added just as easily.

Um, macros are a huge amount of magic. You basically give language design in the hands of users.

The go authors could do what they originally did with generics: only let the compiler/stdlib have macros.

Also, go users have _already_ started parsing comments for magic strings, so it's not like setting an example of using comments is stopping users from doing this crap too.

A macro language which is defined in a clear and consistent way definitely seems less magic than a macro language which has no real definition, other than examples of comments.

The language relies heavily on comments from way way back.

Yeah, it's magic, but not black magic; it's a civilized way of doing things like these.

> they get no error, just a totally broken program.

Actually now - the import protects from that.

Actually, it's not. The compiler using the comments for non-commenting purposes makes me puke. It's a dirty workaround and degradation of the language.

If you want a new compiler feature, add a new statement.

I do agree, I feel like they’ve used this hack to sneak changes into the language which technically don’t break their Go 1 guarantee. I hope they tidy that up in Go 2 and add proper macro commands with a syntax the compiler checks.

Otherwise these magic comments will grow into their own unaudited meta language with no formal spec, just a few usage examples.

This and struct tags (another stringy metalanguage) are the bits I’m not keen on in Go.

> I feel like they’ve used this hack to sneak changes into the language which technically don’t break their Go 1 guarantee.

The go 1 guarantee only says that existing go programs will continue to compile correctly on new releases. It doesn't say that new programs will compile correctly on old releases.

I think Julia makes clear how nice a good macro system can be. From simple things like @btime to the domain specific languages added by libraries like jump, macros just make a language way better. The only hard part is that once you have a good macro system, you will get lots of new users try to use it who take shouldn't.

Yes, seems sort of non-orthogonal.