<html><head></head><body><div>On Thu, 2015-08-06 at 09:19 -0400, leam hall wrote:</div><blockquote type="cite"><div>The main issue I'm trying to overcome with coding is getting work done at work. I've done stuff with a few languages but keep getting pulled back to shell or manual because that's what work supports. With Ruby, I can say "It's on the machines, so I can use it". Go would be a harder sell unless I can find a job at a Docker shop or some place that is producing system tools. Given my current coding skills, I see that as unlikely in the short term. <br><br></div><div>Some of the skills I'm learning now should translate; writing tests, making the code handle errors and exceptions. Some are only useful to OO languages. <br><br></div><div>Still, having fun rates high. <br></div></blockquote><div><br></div><div>The great thing about native-code compilers is that they do not have to be installed on the target system. Only the shared libraries, executable binaries, and runtime data is required.</div><div><br></div><div>That's the great thing about C. I can ship a statically-linked ELF to a remote server to rescue it, even if it only has a read-only FS, so long as SSH lets me in. I've done this before to create a tiny ELF program that calls the reboot() system call when the /sbin and /usr directories was unavailable. Solution? Compile statically linked ELF file (against MUSL, yields a < 30KB binary; without a C library and calling the system call directly gives a binary < 15KB), sftp it to /run, /tmp, or /dev (the first available one that is read-write to UID 0), and run it.</div><div><br></div><div>It could just be that I've used the language for so long that I'm comfortable rapidly writing code in it, but my productivity in C and C++ is quite acceptable to me. It is possible to easily do just about anything with it. C and C++ code modules are freely available to handle ASN.1, BSON, JSON, XML, Thrift, and other data interchange formats/systems, and the code (if well-written) is fast *and* portable. I prefer to use formats that I don't have to pull in huge libraries for, so I avoid XML and Thrift when at all possible. Binary formats, IMHO, are better, but there are lightweight JSON libraries in C.</div><div><br></div><div>Another thing that helped me out: I used to think of C and C++ as two separate things, but really they go together quite well. A C++ module can expose a C API/ABI and you can use the best tool for the job. (C++ as of C++11 is no longer a strict superset of C, meaning that there are times when it is better to use one over the other.) Plus you can interop with Cocoa, NEXTstep and GNUstep simply by writing glue between C/C++ and the framework, which expects to use ObjC/ObjC++.</div><div><br></div><div>Lastly, modern C++ gives you <i>nearly</i> all the power of dynamic runtime languages like Python, but with predictable on-disk and in-memory footprints and no runtime interpretation or JIT. Fewer moving components and all that.</div></body></html>