4 ms·
+1 this is so nice. I actually think this is a bit too much magic: > import _ "embed" > //go:embed hello.txt > var s string > print(s) But the embed.FS ex
by dvirsky 6y ago
+1 this is so nice.
I actually think this is a bit too much magic:
> import _ "embed"
> //go:embed hello.txt
> var s string
> print(s)
But the embed.FS example looks much nicer, I'm glad we can have both.
- xyzzy_plugh 6y agoIt's a balancing act. It's the least amount of magic necessary, IMO. I think it's a great solution over all!
- TheDong 6y agoI 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.
- mseepgood 6y agoUm, macros are a huge amount of magic. You basically give language design in the hands of users.
- TheDong 6y agoThe 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.
- dvirsky 6y agoThe language relies heavily on comments from way way back.
- nikolay 6y agoYeah, it's magic, but not black magic; it's a civilized way of doing things like these.
- dvirsky 6y ago> they get no error, just a totally broken program. Actually now - the import protects from that.
- nikolay 6y agoActually, 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.
- grey-area 6y agoI 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.
- oscardssmith 6y agoI 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.
- remus 6y ago> 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.
- vram22 6y agoYes, seems sort of non-orthogonal.