I really like this idea but can anyone please summarize what it does for me. To me it feels very fascinating (bare metal golang in general) but I am not sure I truly understand its usecase and I would love to know more.
pjmlp 118 days ago [-]
The use cases is not writing unsafe C in first place, and proving the point Go is usable in such scenarios, regardless of naysayers.
The creators of USB Armory also created TamaGo, instead of using Rust, exactly for the same reasons, to prove a point.
It's also a good way to learn about UEFI for people most familiar with go.
qhwudbebd 118 days ago [-]
Quite apart from that, an EFI shell that's less awful than the standard UEFI one is an interesting project in its own right...
bradfitz 118 days ago [-]
I've been idly following this stuff on & off for years, but I never saw proving a point "instead of using Rust" as one of the motivations of the project. Was that ever stated anywhere?
pjmlp 118 days ago [-]
Yes,
> Languages like Rust have already proven they role in bare metal world, Go on the other hand
needs to … and it really can!
That's a shame, I was hoping it would be so I could boot thousands of kernels in parallel at once
flanked-evergl 112 days ago [-]
No amount of proven points will give Go null safety, though.
pjmlp 112 days ago [-]
Yet the whole Docker, Kubernetes, CNCF ecosystem is powered by Go, doesn't seem to have been hindered by lack of null safety.
Same applies to GCP, AWS and Azure, powered mostly by Java, C# and C++.
People should stop being so obsessed with one specific language feature, when there is so much C and C++ code being produced every day.
mrsmrtss 112 days ago [-]
And Linux kernel is written in C etc, so by this logic you don't even need memory safety. There is no good excuse for designing a language in modern times (this century) with every object nullable by default. C# at least mostly has solved this design mistake later by introducing nullable reference types (https://learn.microsoft.com/en-us/dotnet/csharp/nullable-ref...). Then again, Go designers insisted that generics were also unnecessary, until they changed their mind.
pjmlp 112 days ago [-]
On the contrary, because there we have 40 years of security exploits to prove otherwise, and Linux kernel has plenty of CVEs.
C# solution doesn't work, most projects never adopted it, because it is a mess to use with third party libraries that never bothered to add the required annotations, hence why it is still a warning and optional to this day.
mrsmrtss 112 days ago [-]
I’m not sure which .NET libraries you are referring to, but all the ones we use have nullable reference types enabled. If you configure warnings as errors (as you should), then it works exceptionally well. Even if you were to use a library where nullable reference types are not enabled, you only need to check for null once during the library call, rather than everywhere in your codebase.
neonsunset 112 days ago [-]
What? NRTs are used everywhere with WarningAsErrors:nullable also gaining popularity. Whatever environment you are dealing with C# in, if it’s the opposite I suggest getting away from that ASAP.
behindsight 111 days ago [-]
sidenote: just a heads up that I tried emailing you recently to let you know that you might want to contact the HN mods to find out why all your comments get set to dead/hidden automatically.
Your account might have triggered some flag sometime back and relies on users vouching for your comments so they can become visible again.
I saw the email, and thanks. This is okay - I did not exercise (nor anyone should) good impulse control when dealing with bad faith arguments, which inevitably led to an account ban. Either way, Merry Christas!
schmuckonwheels 113 days ago [-]
If one can't write safe C code, then maybe stick to web development and leave the bootloaders and UEFI stuff to people who can.
Training wheels are merely a race to the bottom for barely-literate programmers.
monocasa 113 days ago [-]
The number of memory safety CVEs written in C by people who ostensibly 'didn't need training wheels' point strongly to the antithesis of your argument.
And I say that as someone who's been a kernel engineer for 20 years.
pjmlp 112 days ago [-]
Nah, people ignore on purpose that C creators are the first to acknowledge C's flaws, hence why Alef, Limbo and Go were created by them, and Plan 9/Inferno as improvements on UNIX.
Too many focus on where the journey started instead of where it ended.
throwaway894345 112 days ago [-]
There are only people who think they can write safe C code and those who know they can’t.
pjmlp 112 days ago [-]
Including the language authors, let that sink in.
throwaway894345 112 days ago [-]
Yeah, it’s very much like the meme showing the bell curve with the novice and the wizard/expert both saying “I can’t write safe C code” and the guy in the middle bragging that he can.
tomcam 118 days ago [-]
When you turn on a computer, it transfers code to software required to get the machine up and running reliably--the boot process. That used start in a chip called the BIOS. It's a 40-year old holdover from the early days of the IBM PC. UEFI is a more complex and feature-rich protocol. Due to its default memory management Go hasn't been considered the first choice for such purposes but this proof of concept uses Go for the very low level code needed for UEFI.
reactordev 113 days ago [-]
“Due to its garbage collection” you mean. There’s nothing stopping you from writing go for bare metal, only your pride.
tomcam 108 days ago [-]
Was trying to be concise. Also, stop accusing me of having any pride. I'm married and a father!
pjmlp 112 days ago [-]
GC has never been an impediment for Xerox PARC.
techgnosis 118 days ago [-]
There aren't that many UEFI shells and the ones that exist are certainly not modern. Anything new is helpful, especially if its written in a popular language like Go.
typical182 113 days ago [-]
There’s some more context in a proposal from the folks behind this project to upstream the needed Go runtime hooks into Go proper.
From what I can tell, the core Go team seems generally favorable to it, so seems like a decent chance it will happen.
> Go applications built with GOOS=none would run on bare metal, without any underlying OS. All required support is provided by the Go runtime and external driver packages, also written in Go.
And:
> These hooks act as a "Rosetta Stone" for integration of a freestanding Go runtime within an arbitrary environment, whether bare metal or OS supported.
clktmr 113 days ago [-]
This would also benefit the Embedded Go project, which uses similar modifications to the runtime.
I'm confused, is it bare metal or is it an EFI application? (bare metal used to mean that something can run without services, like those that UEFI provides)
danudey 112 days ago [-]
I think what it means is:
1. It's an EFI application
2. It doesn't require any external runtimes, any setup, etc. (i.e. your UEFI system can boot straight into it without anything in between).
At least, that seems to be the case.
pizlonator 112 days ago [-]
The TamaGo project (which this uses for running on bare metal) looks super impressive! Kudos to the authors for getting this working.
Why is so HW focused ? I use refind and it seems to be HW independent.
danudey 112 days ago [-]
That's the list of hardware they've explicitly tested on. Always bear in mind that, for any given standard, no matter how straightforward, there are going to be dozens of vendors who screw it up for no real reason other than incompetence or malice.
The older a piece of software is, the more workarounds it will have accrued for various hardware bugs or vendor misdeeds, so it's reasonable for the project to disclaim that it's only been tested on a small number of physical hardware devices even if, in theory, it should work out of the box on all of them.
seanw444 113 days ago [-]
As much as I appreciate Go, putting it on bare metal makes me cringe a little.
gethly 112 days ago [-]
If that makes you cringe, I cannot even begin to imagine what this https://tinygo.org will do to you.
reactordev 113 days ago [-]
Why? You can’t just leave that dangling like a meat stick.
pjmlp 112 days ago [-]
Why? Xerox PARC used to do this.
As did all machines that booted into a Lisp or BASIC REPL.
Eduard 112 days ago [-]
missed chance to name it Goo-Boot
jumbledoor 113 days ago [-]
[dead]
Rendered at 12:04:56 GMT+0000 (UTC) with Wasmer Edge.
The creators of USB Armory also created TamaGo, instead of using Rust, exactly for the same reasons, to prove a point.
https://github.com/usbarmory/tamago
https://reversec.com/usb-armory/
Because in IT, seeing is believing.
> Languages like Rust have already proven they role in bare metal world, Go on the other hand needs to … and it really can!
From https://fiif.fi/wp-content/uploads/sites/9/2021/06/TamaGo.pd...
Same applies to GCP, AWS and Azure, powered mostly by Java, C# and C++.
People should stop being so obsessed with one specific language feature, when there is so much C and C++ code being produced every day.
C# solution doesn't work, most projects never adopted it, because it is a mess to use with third party libraries that never bothered to add the required annotations, hence why it is still a warning and optional to this day.
Your account might have triggered some flag sometime back and relies on users vouching for your comments so they can become visible again.
Training wheels are merely a race to the bottom for barely-literate programmers.
And I say that as someone who's been a kernel engineer for 20 years.
Too many focus on where the journey started instead of where it ended.
From what I can tell, the core Go team seems generally favorable to it, so seems like a decent chance it will happen.
From:
#73608 proposal: all: add bare metal support
https://github.com/golang/go/issues/73608
> Go applications built with GOOS=none would run on bare metal, without any underlying OS. All required support is provided by the Go runtime and external driver packages, also written in Go.
And:
> These hooks act as a "Rosetta Stone" for integration of a freestanding Go runtime within an arbitrary environment, whether bare metal or OS supported.
https://embeddedgo.github.io/
1. It's an EFI application
2. It doesn't require any external runtimes, any setup, etc. (i.e. your UEFI system can boot straight into it without anything in between).
At least, that seems to be the case.
I wonder what GC changes had to be made, if any.
I wonder if it supports multiprocessing.
> Sprout: UEFI Bootloader in Rust
The bare metal list is quiet thin.
Why is so HW focused ? I use refind and it seems to be HW independent.
The older a piece of software is, the more workarounds it will have accrued for various hardware bugs or vendor misdeeds, so it's reasonable for the project to disclaim that it's only been tested on a small number of physical hardware devices even if, in theory, it should work out of the box on all of them.
As did all machines that booted into a Lisp or BASIC REPL.