Store SQL scripts as embedded resources rather than string constants. When SQL scripts are stored as individual ".sql" files, both version control and syntax highlighting is better.

This works with most editors and doesn't require fancy multi-language syntax highlighting support. When debugging complex scripts that involve many joins or CTEs having good highlighting can prevent a lot of headaches.

Imagine you are shipping a library. Say, one that tells you about timezones.

You want your users to just be able to import that library and use it. The fact that you need a bunch of zone info files should be invisible to them.

Maybe those users are in a sandboxed environment that doesn't allow opening files, or you're in webassembly where files don't exist.

It's much simpler to just bake that data into the library.

I’d prefer a library that uses the IANA tzdb directly - so I can download the latest tzdb files for my application and OS without needing to wait for the maintainer of that library to ship an update.

You missed the point. This is not about timezones, but about the need that sometimes happen to embed files into a library.

Parent just chose timezones as an example.

They used time zones to illustrate a point. Of course it’s generally best to use that file instead for that specific use case. Now imagine some data that isn’t shipped with Linux by default. That’s the point they were trying to make.

Convenience. It's easier and more foolproof to give someone one file than it is to give them a directory.

Yes! I can't count how many people have tried to use my software (https://github.com/mickael-kerjean/filestash), flushing some entire directories with docker volume and creating support tickets and emails as things got broken.

The landscape of tools supposed to solve that problem isn't great. Things are changing way too fast with projects being archived or deprecated with mention to migrate to another solution which after another year is deprecated again. Because of those issue, I've went with go generate which isn't ideal but is at least stable. That proposal would be a game changer and hopefully it will become a reality as Brad is quite a prominent figure in the Golang world.

Sorry... what do you mean by "flushing" (thanks)

BTW. Fantastic software, filestash - really really good.

My guess: deleting.

Thanks, first I thought... it cannot be, because when you delete the container, the named volumes are still there; but I guess that they might have deleted contents using the app itself, without realizing they were sharing the directory...

`docker system prune rm -af` ftw

Thanks, will this also remove the files in named volumes? I hope it won't! (Will not try :-D)

I personally find it more elegant to distribute a single .exe file which contains all the html/js/css inside it, to customers.

Instead of having a "messy" folder on their computer.

Sometimes I write tiny services with a web interface that I can just distribute through scp'ing the binary. In this case I can embed the favicon and other tiny files directly into the binary without making the deployment more complicated.

You might not have a filesystem.

Consider the reverse question: it's simpler to just ship files in the binary unless you need one of the specific advantages of loose-leaf files (like the user being able to modify them, other processes like Nginx reading them).

If you don't need one of the features of having "moving parts" on the filesystem, then why would you want a dependency on the local filesystem?

I maintain an open source project written in golang that's test runner with an html reporting plugin.

I can use this feature to bundle the report template, css, js, images file with the plugin to make download installation and use of the plugin much easier.

Performance. No additional I/O at startup and guaranteed to be in memory.

I don't know what platform you had in mind, but this isn't generally true for Linux. No part of a Linux executable is in memory except the page containing the main entry point, initially. You'd have to pre-fault the sections of interest and protect them with mlock to make sure they stay in memory. If you don't their cached pages may be dropped, which is essentially the same thing as swapping.

In short, these embedded assets are no more likely to be in memory than any other file-backed data. If you want to guarantee they are in memory, it is up to you to make that happen.

Even then, it avoids open, path traversal, read read read, close.

More important is avoiding having to answer the question "where are my assets".

Aren’t executable files loaded into memory page-by-page, on demand? There’s no guarantee that their contents are in memory.

Correct, it’s addressable in process memory space, but not guaranteed to be paged into memory until accessed.