3 ms·
Does this finally allow reading string literals from files and include them into the binaries? I've seen a Go project that was heavily using https://pkg.go.dev
by andix 10mo ago
Does this finally allow reading string literals from files and include them into the binaries?
I've seen a Go project that was heavily using https://pkg.go.dev/embed https://pkg.go.dev/embed for loading some template files, and got a bit jealous. Back in the days of .NET Framework it was common to compile file contents into resource files, but it was always quite cumbersome.
- deleted 10mo ago[deleted]
- floucky 10mo agoCan't you already do that with embedded resources?
- andix 10mo agoYes, you can. But it's a bit cumbersome. The API to read them is not really intuitive, they are only accessible as a Stream, so they need to be either read every time into a string (new allocation, slow), or you need a helper that reads them once and keeps them in memory. I think there are also a lot of gotchas around naming and listing them. In modern code I don't see them that often anymore.
- orphea 10mo agoI see your point and I don't necessarily disagree but better API for embedded resources is just a couple of simple extension methods away. I wouldn't even bother adding an external package for it.
- eterm 10mo agoC# / .NET has always had that abililty. <EmbeddedResource Include="/path/to/file.txt" /> Then you can read that file from the assembly with: assembly.GetManifestResourceStream I'm not sure what's awkward about that, but it's nothing new. Discoverability for this is in visual studio, if you go to file properties there's a drop-down where you choose between Content, EmbeddedResource, Ignore, etc. That determines what happens in compile, whether it is copied to output directory, compiled into the binary, etc.
- andix 10mo agoThe Stream is awkward. It needs to be processed either once at startup or lazy on access, or every time it's used (allocations!). Also discovering multiple files is awkward.