Embed this noticeSexy Moon (moon@shitposter.club)'s status on Saturday, 04-Nov-2023 18:17:55 JST
Sexy MoonI was just thinking about that "rant" post about people that say C is close to hardware, it feels like a red herring, people say that but the reason is just that it doesn't abstract direct hardware access from you and it has a ton of momentum. To the level that people write formally-verified operating systems in C instead of something like Ada. It is what it is.
You can manipulate raw pointers in memory with Java via JNA but the reality is people don't even write operating system cores in C++ let alone a language that requires an entire VM. Nobody gonna write a device driver in Java. Nobody gonna write an OS in Java (toy versions of both exist as proof it is technically possible.)
I am sure there are multiple production C++ kernels out there but every time I look it's a core written in C and assembler and then a bunch of libs in C++.
@Moon can't escape the fact that the core of an os is a bunch of special context switching assembly instructions. Maybe c++ can do that with some std::intrinsics?
@Moon In fairness to our prospective kernel author, Ada is a large and complicated language which has exactly one (1) viable implementation in the present so if SHTF, he really doesn't have options. Compared to C which has multiple viable implementations and which can be maintained indefinitely by a single person.
@Moon Formally verifying an OS is a massive undertaking, that's why (usually) people don't verify the the system as a whole but certain functional properties of parts of the OS. This would make a functional language the best candidate for OS dev, however you lose a lot of versatility with a strict type system and at the end of the day it's more pragmatic to hackjob the OS in some language that implements easy to use concepts for OS dev and afterwards extract the relevant properties required to prove. People are currently doing that with Linux right now (gl :blobcatgiggle2:) https://arxiv.org/abs/1809.00626
@mario you can do that through a high level library that lets you read and write absolute memory addresses. It would be torture to use this to write a "device driver" but you could write a userland tool to directly access a peripheral or something if you were a masochist.
@Moon I'm still very confus how one would go about the JVM in order to actually do something meaningful OS work (i.e. IO) with the Java pointers. Like you'd either need to expose the peripheral register address into the VM or need to escape it :think_nyan: C(++) is very nice for OS dev because of the simple syntax for low-level stuff as well as the little overhead it needs (if you're using a more minimal libc)
@mario It is absolutely not normal and is actively discouraged from using JNA Pointers to directly access absolute memory addresses though, typically you use JNA to allocate a raw block of memory and then manipulate it through the Pointer class. Another funny thing about that person's rant is that Java's native interface requires C ABI on the platform to link to anything.
@Moon Maybe it's because I never had to seriously work with it, but the little pet projects I did using it suffered from their approach to abstraction. Pretty sure that's just my bias, but thinking about OOP design patterns gives me shivers. I'd rather just write a function that generates certain instances of a type instead of having a factory object i.e.