-
Notifications
You must be signed in to change notification settings - Fork 911
Wishlist
Some wishlist items, from "critical in most applications" to "nice to have". In no particular order.
There is already support for goroutines, but they cannot run at the same time at the moment.
It is possible, but not really on the roadmap. Multithreading is very hard to get right: both the runtime and packages like sync need to be aware of it. They currently are not.
Here are roughly the required steps:
- Implement channels
- Implement blocking I/O with a different goroutines taking over when the current one is blocked
- Implement safe interrupt handling on MCUs: this is like a really primitive form of threads (think Unix signals) that can be temporarily disabled for atomic behavior
- Implement goroutines with a real separate stack - they currently share the same stack using some compiler magic (there should be a compiler flag to choose this)
- Try running multiple goroutines at the same time in different threads - of course this should also be an option to not increase code size when not needed
In any case, the fact that some programs can run goroutines in parallel should not increase code size in single-threaded builds.
With a compiler based on LLVM in place, it should be possible to build a REPL with JIT compilation. This at least requires support for separate compilation as packages can be imported dynamically: no whole-program assumptions may be made.
Depending on the implementation, such a REPL may even be able to work on a microcontroller, with some limitations.
Very important, but a lot of work. Especially a GC for WebAssembly will be difficult as WebAssembly doesn't expose the raw stack.
Also consider adding a //go:nogc pragma that ensures at compile time that a given function does no heap allocation (for example, in interrupt handlers or in the main loop of a program).
It would be useful to be able to log when certain undesirable things happen or cannot be optimized away, including the exact source location. For example in the following cases:
- Heap allocation
- Missed bounds check elimination
- Recursion (unbounded stack growth)
- Calling function pointers that cannot be resolved at compile time (unknown stack growth)
Rust has a strong community for the embedded and WebAssembly worlds - exactly where TinyGo also works really well. It would be nice to glue them together, so Go code can import Rust crates as packages and Rust can import Go packages as if they were crates.