Hacker News Reader

> Not only did Google not write Fucshia in Go, they explicitly made it a forbidden language

It's more correct to say that they attempted to write part of Fuchsia in Go, but the results performed so badly that they decided it would need to be rewritten in another language.

Just as Microsoft once made a good faith effort to rewrite Windows in C# (Longhorn) before that effort had to be abandoned.

Longhorn failed due to sabotage from Windows team due to the usual WinDev vs DevDiv politics, hence why since Vista all Longhorn ideas have been redone in COM, and COM followed by WinRT (COM + IInspectable + TLB replaced with .NET metadata).

Midori had no issues powering Asian Bing servers during its life in production.

The late build of Longhorn that leaked back in the day performed so poorly that it took forever just to boot on the computers of the era.

I have no doubt the usual Microsoft politics of the era applied as well.

> Not only did Google not write Fucshia in Go, they explicitly made it a forbidden language (listing a litany of reasons to exclude it and any other GC language -- the same reasons that apply to most "low-level" code), they set a goal to migrate any parts imported in. Maybe not the best example.

It helps when the Go guy on the team is no longer there to argue for it.

> Which programming language would one write "COM" in? ....

VB 6, Delphi, .NET, C++ Builder, C++/CX, C++ with MFC/ATL/WRL, whatever language speaks the COM ABI.

Yeah, maybe you were doing it wrong.

> The "Linux bubble" comment is especially weird. I spend my day in macOS, with most of my day being in XCode slinging Swift and GoLand spinning Go. Somehow I can evaluate the world without trying to mangle it to fit whatever my current primary skills are.

Good for you then, happy future.

"Yeah, maybe you were doing it wrong."

I think you misread my comment which was pointing out that COM is an interfacing standard, and has little to nothing to do with language choices or this conversation. Pointing out that there are multiple languages that can build to it isn't a counterpoint, but actually is the reason I made my comment. It's like saying you "developed the program in JSON over HTTP" in a conversation about programming languages.

Though regardless of that, Microsoft uses C++ for the overwhelming majority of a Windows install (this is trivial to verify). This is meaningless, having nothing to do with the root comment, but somehow this conversation was pulled there.

Windows programs can be written in just about anything. No one ever contested that. "Low-level" code, however, is seldom done in the GC languages. Seldom doesn't mean never, as stated over and over again, and Googling for random fringe counterexamples aren't counterpoints.

I don't really follow what you two are arguing about - I think it's pretty clear you can in theory write systems-level programs in most of those languages. However if the focus is on Operating Systems, there have been a few formally verified OS's written in Ada/Spark that are worth looking at (if I correctly read these posts as saying that's not possible).

It's kind of all over the place.

The initial point is simply that Go or C# or Java in their normal form aren't "system programming" suitable (which generally means low-level kernels and system services and projects having similar needs. Notepad on Windows isn't system programming), and it's unrealistic for Go to be ranked highly on such a list, much less before Rust which is purpose built for this task.

Could someone use them for system programming? Sure they could. It would be the wrong tool but people makes loads of bad decisions.

The point about Linux and other operating system choices wasn't a rule, it was an observation that the rhetoric often plied on developer boards -- usually where developers want everything to be a nail to their skillset hammer -- has little correlation with the world. Nowhere did I exclude Ada or any other compiled, non-GCd (which Ada never uses when used for anything of any criticality) languages. Anything can make just as good of native code.