-
Notifications
You must be signed in to change notification settings - Fork 13
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
Propose Go as programming language for installer #39
Comments
Or choose Rust as the programming language for implementing the installer. 😎 |
There's a rust version of this repo over here - https://github.com/knawd/deployer
@0xE282B0 not looking to duplicate work or add unnecessary confusion to the eco-system so once the go installer lands would you be interested in the items above as a PR (maybe not 4 as it's very experimental) as they are build/helm related and we can go forward with this installer? |
Hi @No9, We are currently working on some architectural changes. The bash-based v0.2.0 installer was bundled with the binaries it installed (pretty much like knawd), which in our case resulted in a huge installer image that became increasingly complex. Originally, KWasm was intended to be a lab where you could try all kinds of wasm runtimes on Kubernetes, but it turned out that in most use cases only one or two runtimes are needed. In v0.3.0 we focused on container shims based on the runwasi project and removed Your requirements seem to fit well:
It looks like you're more used to the RedHat container stack, I'd love to see you bring your knowledge to this project! We have a Slack channel in the CNCF Slack where we can discuss the details: |
As the installation procedures for our software project continue to evolve and become more complex, it has become apparent that our current shell script installer is no longer sufficient. Maintaining the existing installer has become increasingly challenging, and it lacks the robustness required for a seamless installation experience.
Proposal:
In light of these challenges, I propose that we migrate our installer to the Go programming language. This transition to Go would offer several advantages:
Enhanced Robustness: Go is known for its robust error handling and built-in concurrency support. This would result in a more reliable installer, reducing the risk of installation failures and errors.
Ease of Maintenance: Go code tends to be clean, readable, and easy to maintain. With the growing complexity of our installation procedures, this change would make it simpler to adapt and update our installer as needed.
Cross-Platform Compatibility: Go can cross-compile for various platforms, ensuring that our installer can seamlessly run on a wide range of operating systems, thereby expanding our software's reach.
Short Compile Time: Go's short compilation times enable quick iteration and development, making it easier to implement changes and improvements to the installer.
Static Binaries: Go produces statically linked binaries, which can be run in containers without relying on the host operating system. This provides a more consistent and container-friendly installation experience.
Scope of Work:
Benefits:
Additional Considerations:
This proposal aligns with @phyrog suggestion to utilize Go for our installer, taking advantage of its strengths to address the evolving needs of our software installation process.
Please feel free to provide feedback and suggestions on this proposal. Your input will be valuable in shaping the future direction of our installer.
The text was updated successfully, but these errors were encountered: