4 ms·
Linux? Almost beyond any doubt at all. Git? The official tools probably will be, but that doesn't really matter one way or the other. "Git" is more a data m
by jlgreco 13y ago
Linux? Almost beyond any doubt at all.
Git? The official tools probably will be, but that doesn't really matter one way or the other. "Git" is more a data model and a frame of mind than it is a piece of software, and you can already choose to use jGit to work on that data model, within that frame of mind.
- zanny 13y agoI've never investigated it, and a google search turns up questionable results, but would Linux be compatible with kernel modules compiled to .so's that have C ABIs? IE, C++ with extern "C". D and Rust have a similar export scheme available I think. I'd get a lot more involved in the kernel proper if I wasn't stuck in 1999 =\ (I think the kernel allows C99). I use classes and templates too much in C++ to go back.
- steveklabnik 13y agoWhile you can extern C, Linux will never move to C++: http://article.gmane.org/gmane.comp.version-control.git/57918 http://article.gmane.org/gmane.comp.version-control.git/5791... As someone who contributed a bit to a kernel in D, it's... interesting. Rust could be used to write a kernel as well, but I'd recommend anyone to wait for 1.0 before doing so...
- zanny 13y agoGood to know if I ever need to implement a brand new device driver. Otherwise I'm stuck in C anyway since everything is written in C. Principally, that is the reason even though I'd love to fix the internal breakage of the linux desktop (pulseaudio issues, gstreamer, mesa, wayland, etc) all of them are written in C and I drank Bjarnes kool-aid and can't go for an entire source file in C without desperately wanting a C++ feature of some kind. The abstractions are just such huge productivity gains writing everything imperatively drives me nuts (at that, a lot of my code is imperative, but only when it is right for the job - if I have a great description of a collection of data and functionality, classes are correct; if I need to treat functions as data and avoid state functional is correct; etc - trying to lock myself into one methodology after writing in all 3 makes me feel heavily restricted, it is one of the reasons I love python).