-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: Go 2: Make official embedded subset of Go specification #29147
Comments
I don't think that's a realistic goal. The Go specification and the standard library rely heavily on garbage collection. Moreover, concurrency is fundamental to the Go programming model. (Threading is not essential, but concurrency is. Concurrency is not parallelism.) On the other hand, it would be fine to optimize an embedded implementation to reduce the size of the runtime when garbage collection and/or concurrency are not needed. (Note that you can already use |
You are right. By concurrency I meant some sort of nondeterministic task interleaving, but there could be deterministic task interleaving that helps manage memory heap at compile time for example. |
I wish Go would have an embedded specification (like the C standard defines both freestanding and hosted specs). However, concurrency is an integral part of Go, and parallelism is intrinsic in almost every embedded application. Go would fare much better here than C, because it has native concurrency. Without it, embedded Go would offer little more than just a safer version of C. Complex numbers are trivial to implement if you have floating point, but many small CPUs do not have floating point. Floating point, not merely complex numbers, need to be absent from embedded Go. In the absence of a a garbage collector, embedded Go needs some equivalent of |
It's quite difficult to define a version of Go that does not support garbage collection, as some operations in the language implicitly allocate memory. For example, converting a value to an interface type may or may not allocate memory. It's hard to see how a program could reliably release that memory allocation without being intimately aware of how the specific Go implementation works, including the details of escape analysis done by the compiler. |
By default, disallow such code (compile with For embedded programming it's perfectly adequate (and expected) to depend on the specific implementation and understand how it works. It's no different than C, where you use very specific compilers and C libraries. In embedded programming all abstractions are leaky, but they are still useful. |
I think that it would be very frustrating to write Go code that did not permit implicit conversions to interface types. The majority of existing Go code could not be compiled in such an environment. You couldn't even call |
A solution miight be to use automatic reference counting (ARC) in stead of a garbage collector. Sure, it has some problems in itself such for cyclycal garbage, but for OSX and Objective-C, this has proven to be a very workable solution that needs far less run-time support than a fully blown GC. |
There isn't enough concrete here for the proposal process. The first step would probably be for the TinyGo and emgo stakeholders to get together and try to agree on what this "subset" would be. If you agree then you could define it yourself without any permission from us at all. We don't have the active involvement in using Go for (or expertise in) embedded environments to participate meaningfully. AppEngine effectively defined a subset of Go (no unsafe) informally, and that seemed OK. |
Note also that Go without garbage collection is essentially a new language, not really a subset. |
It has been created a language with a similar syntax than Go although without runtime and GC, but with easy interoperation with C and C++ (FFI in Go is pretty unfriendly). |
A little late for this issue but for the record I don't think microcontroller compatibility and garbage collection are mutually exclusive. For instance, on an embedded system a mode could exist in which the GC would only be called manually, so it could be done as applicable in a constrained environment. This does not change the language, only some runtime particulars for specific platforms. It probably needs a new issue and a different proposed approach, but I think there is a pretty strong case that TinyGo's goals can be met without radical changes to the Go language. Indeed, TinyGo has already started to implement a basic GC. I think the issue is more than it's a heck of a lot of work to rewrite significant chunks of the runtime and optimize them for size and simplicity (instead of performance and functionality as they are now). On a microcontroller, the GC doesn't need to be fast, it needs to be small, and it needs to workable without assuming multiple threads are available. |
I just came across this issue, I didn't know about it before. As the original/main TinyGo developer, my opinion is that if you were to define a subset of the Go language you might as well write a completely new language. You either are compatible with the existing Go ecosystem or you aren't - there's not much in between. Either existing packages compile with your new compiler or they don't. And I'm committed to make the TinyGo compiler compatible with the existing ecosystem as much as is reasonably possible. To comment on a few specific issues:
All in all, TinyGo managed to get If you want to know what problems we're really hitting in TinyGo, here is a slightly outdated list: https://github.com/tinygo-org/tinygo/wiki/Go-pain-points |
TinyGo's inclusion of |
This is proposal to consider unifying efforts of TinyGo https://github.com/aykevl/tinygo and emgo https://github.com/ziutek/emgo projects. It would be desired to have official, standarized, subset of Go features that may by used to write compilers (or even add an option to official Go compiler itself) that are targeted for embedded devices and also that are better suited for WebAssembly use case.
Desired features would be:
The text was updated successfully, but these errors were encountered: