Try https://marketplace.visualstudio.com/items?itemName=tinygo.vscode-tinygo

The error message here is correct: machine is not a package in the Go standard library.

From what I understand, the machine package may be associated with the TinyGo project. It's a bit disappointing that they've coopted a standard-library path (see #32819) instead of using a domain-prefixed import path like those used for other third-party packages, but that's an issue to raise with the TinyGo maintainers, not something we should address in the mainline go command.

(CC @aykevl)

@bcmills thanks for CCing me! Yes, this definitely is a TinyGo issue which doesn't belong in the Go project itself.

It's a bit disappointing that they've coopted a standard-library path (see #32819) instead of using a domain-prefixed import path like those used for other third-party packages,

It seemed like a good idea at the time but now not so much. However, changing the import path is going to be difficult so it has to be done only when the benefits are significant. That said, for TinyGo the machine package is just as important as the runtime package: the runtime package depends on it.

Yesterday I looked into using tinygo.org/x/machine instead so that the Go toolchain can deal with it, but then I ran into the fact that I can't redirect it to the actual location (github.com/tinygo-org/tinygo/src/machine). I could use tinygo.org/x/tinygo/src/machine instead but that seems ugly to me, especially for a package that is often needed. This issue of vanity import paths of a subdirectory has been raised before (#34055, #33562) but so far without solution.

I know this is somewhat off topic for this issue but any ideas here would be appreciated.

@aykevl, the Go standard library currently vendors in a few external libraries (such as golang.org/x/sys/cpu) for internal use. Would it make sense to similarly move the TinyGo libraries out to a separate repo and vendor them back in?

(Unfortunately, at the moment the Go vendoring approach does not allow user code to import the same vendored packages, so today that approach would result in some code duplication that might be too costly in an embedded context; see #30241 for more detail and some alternatives under consideration.)

@bcmills technically yes but I would really like to keep all the code in a single repository. Otherwise adding support for a new chip (which happens much more often than adding a new architecture) would require changing multiple repositories. Therefore I'm hoping #34055 will get accepted which would provide a way to transition away from these paths.