There are many aspects of this proposal that I really like, and a few that
I think need to be reconsidered.
In general I like that it:
1. Does not try to handle errors *above *where the errors occurred,
which is the pattern when using both *defer* and *recover(). *I
personally find
What platform are you building under - in particular, is it Windows?
On Thursday, 29 June 2023 at 13:11:07 UTC+1 王富民awaw wrote:
> My builds have been very slow recently and I want to know why is `go
> build` so slow for me.
> Is it due to reading disks or something else?
>
> What is the
My builds have been very slow recently and I want to know why is `go build`
so slow for me.
Is it due to reading disks or something else?
What is the recommended way of profiling/debugging `go build`?
I know that the `-x` flag prints detailed information of `go build` but it
doesn't tell where
FS is an abstraction, a common interface for file systems.
It allows me to provide access to an archive (zip, tar) or database or
network (S3, HTTP ...) backed file system.
Thus exporting FS as a FUSE filesystem allows all those FS implementations
to be accessed as a real file system,
I can see a use - exporting an embedded FS (read only) from a binary,
especially for testing stuff.
On Thursday, 29 June 2023 at 08:00:18 UTC+1 Roland Müller wrote:
> Hello,
> I am struggling to understand the purpose of extension.
> FS is an interface to access file systems from go code. Is
Hello,
I am struggling to understand the purpose of extension.
FS is an interface to access file systems from go code. Is your new
extension acting as a handler and allows to expose any Go FS to be mounted
and acessed at operating system level?
