4 ms·
I worked on a distributed filesystem which had its administration tools written in Java. The system itself was written mostly in C, and in some weird Haskell /
by crabbone 4y ago
I worked on a distributed filesystem which had its administration tools written in Java. The system itself was written mostly in C, and in some weird Haskell / C++ generated templates that compiled to C source.
I've known about a bunch of "sister" storage projects which were written in a similar combo: typically the product itself would be C (or eventually, D, more recently -- Rust), but a language like Java would be inconceivable for a system like that.
Few things that these projects had in common:
* Home-made concurrency (i.e. they didn't use pthreads, instead they used some green threads designed specifically for this project).
* Home-made allocator. Again, similar to the threads, the default allocator options available to system programming aren't good for mission-critical software.
* Home-made logging. Due to high volume, speed and storage requirement it's typically a very involved system that is far more sophisticated than any Java built-in or 3rd party logging library.
* Home-made collections / containers. The reasons to have this is very similar to the reason to have custom allocators -- improved ability to deal with memory-related errors.
* Home-made drivers and IP stack, or at least partial re-implementation of IP and higher-level protocols. Again, because of memory-related concerns.
* Virtually no 3rd-party libraries. For close to 2M lines of C code for the core part of the system, we had like... some compression algorithm library as a dependency... and that was it, iirc.
I mean, these kinds of products need to rebuild something rather minimal like C almost from the ground up... just the mere thought of using Java in this kind of environment would've been laughed out of the room.
I know that databases, like relational databases are often written in Java, but in my experience, those are mostly used by Java applications and rarely leave the boundaries of the Java ecosystem. People coming from storage background rather than pure Java background wouldn't think about Java databases more than as toy projects really.