It's also a good way to learn about UEFI for people most familiar with go.

Quite apart from that, an EFI shell that's less awful than the standard UEFI one is an interesting project in its own right...

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?

Yes,

> 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...

That's a shame, I was hoping it would be so I could boot thousands of kernels in parallel at once

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.

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.

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.

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.

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.

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.

They are aware.. https://news.ycombinator.com/item?id=44026655

ah thank you for the context

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!

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.

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.

There are only people who think they can write safe C code and those who know they can’t.

Including the language authors, let that sink in.

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.