undefined | Better HN

0 pointspjmlp3y ago0 comments

Back in my days, systems programming evolved writing compilers, linkers, os drivers and kernels.

Given that the whole Go toolchain is bootstraped, it fulfills that role quite alright.

Maybe we need drivers and such to strenght the argument, well given the role of gVisor and Android GPU debugger, that seems a case for systems programming.

Maybe still not good enough, then I refer to the F-Secure TamaGo unkernel being shipped as firmware for the USB Armory security keys, or the TinyGo runtime which even ARM refers to on their IoT page.

0 comments

throwaway17_173y ago

I’ve seen comments from you several times that echo this point. But it always seems to end conversations, which I find disheartening, because I’d really like to see others at least discuss your point, even if they never adopt a similar view. Your premise seems to be that most devs are overlooking the applicability of ‘managed’ languages in the area of ‘systems programming.’ I think your listing of systems programming topics above is a fairly representative sample and I never see much push back, or any concrete examples, for why a managed language is not capable of being used in the general case.

I agree that examples of drivers, and possibly kernels (outside of Oberon), that utilize managed languages may be needed to really start the conversation, but there really should be a conversation. So, off hand, can you think of any books, technical reports, papers, videos, whatever on this general topic that can point me deeper? At my core as a developer, I am concerned first and foremost with performance (along many metrics, not just wall-clock speed), but outside of hard or soft real-time systems (and soft may have more leeway than is commonly claimed) I really think there are some big wins possible in multiple areas by switching the default definition of ‘systems programming language’.

PS. Sorry for going super OT and for dragging up an almost day old comment.

pjmlpOP3y ago

It is hard to have such conversations, because they tend to be more ideologic than technical.

Most of the systems that we had in such directions, like Xerox PARC and ETHZ endevours, Inferno, Microsoft research, usually failed not because of technical issues (which they had), but because management decided to spend money elsewhere.

As proven by stuff like Android, JavaScript JIT and similar projects, it isn't a MVP product, rather something that you really need to be willing to spend years putting money into to prove a point, and the large majority isn't into it.

Regarding information, the now abandoned Android Things replaced the original Brillo project, whereas Brillo was Android without Java everything C++, Android Things became a subset of Android, where for security reasons drivers would have to be written in Java.

https://developer.android.com/reference/com/google/android/t...

Since Project Treble, Android allows for writing Treble drivers in Java,

https://source.android.com/devices/architecture/hidl

Apple's continuous push for Swift (they even made the point at WWDC 2022 that Objective-C is done and thank him for all the fish) is another example, so anything coming from them. Yes, Swift does count as managed language, as RC is a GC algorithm.

chakkepolja3y ago

I indeed agree that Go can be used for many systems and adjacent purposes, and is used for many DB engines and network stack stuff pretty well.

But it's relatively more abstract and gives less control than C++/zig/rust. I was just comparing and contrasting the marketing.

Go was once marketed as systems language even if the authors intended it more for systems adjacent stuff. Now everyone advertises their language can write web services it seems. I mean why is it out of fashion to just admit a language is mainly intended for low level stuff?

j / k navigate · click thread line to collapse