shifu VS TinyGo

To create the Shifu Plugin for ChatGPT, I utilized an open-source infrastructure called Shifu: https://github.com/Edgenesis/shifu. Shifu is a Kubernetes-native industrial edge that allows complete IoT interoperability by virtualizing devices into Kubernetes pods. This adaptability and flexibility made it possible for seamless integration with ChatGPT, providing AI access to and control over the physical world. This approach can be applied to a wide range of IoT devices, further expanding AI-human interaction possibilities.

It's heart breaking to see talents especially former colleagues losing their jobs. But it is also a big warning sign telling people to select open-source software for their infrastructure. With that being said, our startup Edgenesis is building an open-source IoT framework, shifu

I don't know if you have any specific problem you wish to address to, but I've been paying attention to this project: https://github.com/Edgenesis/shifu, it is a Kubernetes-native IoT development framework. If you wish to use k8s to "easily scale and manage large numbers of IoT devices, automate deployments, and ensure high availability", maybe you can take a look at this.

I've been working on a k8s native IoT development framework as well: https://github.com/edgenesis/shifu

Should metaverse be completely virtual? Should it be simply a utopia created according to our needs? But what about the real world? Are we all just gonna discard it and escape to the virtual metaverse? That sounds both impractical and disastrous. I would much prefer a physical metaverse instead.

Wait... What the hell is a physical metaverse? In my opinion, it is a place where we can easily alter things around us to serve our needs. But how can we get there? Here's my answer -- IoT. If we can orchestrate various IoT devices with ease, then we are off to a good start. Smart home is a tangible example, it can be viewed as the prototype of a physical metaverse. Here comes the PROBLEM: how can we orchestrate all these heterogeneous IoT devices with ease? Here I proudly introduce you Shifu, a framework to build your own physical metaverse.

The idea of Shifu is quite simple: Shifu creates digtal twins for IoT devices in the form of Kubernetes pods. This way, we can quickly integrate heterogeneous IoT devices into the cluster, and expose their capabilities as APIs. It means Shifu will make building IoT APPs as simple as building web APPs.

Through a "device integration-- data acquisition-- app development-- decision distribution" feedback loop, Shifu enables developers to build their own physical metaverse. What's even better, Shifu is more than just a crazy idea. Shifu has been successfully deployed in various fully automated labs/factories and received exciting results.

Talk is cheap, it's time to show you the code. Please pay us a visit at https://github.com/Edgenesis/shifu, and join the revolution of building your own physical metaverse!!!

BTW, don't forget to give us a star! It means A LOT to us: ) Thx!

Check out our Github page at https://github.com/Edgenesis/shifu for more information and to see how Shifu can help your business with IoT development.

If you're a developer working with MQTT, I highly recommend giving Shifu a try. To get started, head over to it's Github page at https://github.com/Edgenesis/shifu and take a look at the documentation and code examples. It's a game changer and will save you a lot of time and effort.

Shifu is a Kubernetes native, production-grade, protocol & vendor agnostic IoT development framework. You can develope your application while managing your devices, spare the need for maintaining an additional O&M infrastructure. Check https://github.com/Edgenesis/shifu for more details!

Before you dig deep into https://shifu.run for our great product, buzzword-wise it for sure has the following features that can replace what you enjoy in Google IoT Core as easily and fast as turning a switch:

Reading through the documentation, you will understand why this plugin is called "tiny," i.e., the SDK uses the TinyGo compiler instead of the official Go compiler. You can read more about why this is the case on the SDK\'s overview page, but the TLDR version is that the Go compiler can only produce Wasm binaries that run in the browser.

Not only you can fit Go into a kernel, there is at least two products that do so.

TamaGo, used to write the firmware used in USB armory.

https://www.withsecure.com/en/solutions/innovative-security-...

TinyGo, which even has official Arduino and ARM support, and is sponsored by Google

https://tinygo.org/

Ah but that isn't proper Go! Well neither is the C code that is allowed to be used in typical kernel code, almost nothing from ISO C standard library is available, and usually plenty of compiler specific language extensions are used instead.

Reminds me of https://tinygo.org/ - a project that brings Golang to embedded devices, browser (wasm) contexts. Do you converge or diverge from that project?

You should also consider TinyGo. It can compile Go for the Pico, and is starting to get good device support.

Thankfully some folks completly ignored whatever the rest of the world thinks system programming is all about and created:

- TinyGo (https://tinygo.org/), which is acknowledged by people in the industry[0][1]

- TamaGo unikernel on USB Armory secure key (https://www.withsecure.com/de/solutions/innovative-security-...)

And then there is the question if writing compilers, assemblers, linkers is systems programming or not.

[0]-https://www.cnx-software.com/2019/08/28/tinygo-go-compiler-f...

[1]-https://twitter.com/ArmSoftwareDev/status/131680481331796787...

Have you seen TinyGo? In the case of embedded system I would probably still chose C over Rust if the system didn't support dynamic memory allocation, and most embedded systems do not.

>I really hate how for microcontrollers the only two choices are either C++ or Micropython

There's TinyGo as well. https://tinygo.org/

Gist link fixed, thanks. Compared to TinyGo, Go with GOOS=wasip1 will probably generate larger artifacts (at least, for now). This is because it bundles the entire Go runtime. The benefit is that it fully supports goroutine scheduling and non-blocking I/O. TinyGo (I believe) still uses a custom asyncify pass and does not support non-blocking I/O nor basic WASI networking (e.g. https://github.com/tinygo-org/tinygo/pull/2748 never landed, but GOOS=wasip1 supports it).