JustAGeek wrote: ↑
Thu Jun 21, 2018 9:21 am
I have absolutely no idea why I'm biting on this. I'll use it as an excuse to exercise my brain. So while I'll write as though I'm speaking to you, I'm really more interested in just writing down my thoughts. I also stopped reading all the comments when I realized that it would be a REALLY REALLY long read. So I'm about 1/4 down on the second page as it stands now.
I've been many things in life. I have been coding far more than long enough to actually have earned a living in COBOL before it was obsolete. I spent many long hours programming in languages where GOTO statements were the only real option. I've been a senior developer on one of the fastest web browsers ever made for years. I've been a programming language designer, an operating system developer, an old school demo coder and for a very large part a codec developer for one of the companies that more or less dominated the patent pool on a lot of H.26X standards.
I am also currently coding almost entirely in C# for many reasons... though not really the ones mentioned. And remember, I've spent much of my life counting cycles.
I'm also glad that no one is debating firmware/kernel level languages like C and C++. I'm completely over those languages and have absolutely no possible reason to recommend either for anything since Rust came around... except maybe that C's ABI is very simplistic and can be trivial to implement.
I absolutely love the Microsoft stranglehold on C#. They have a good team working together to make a good product. There are days where I want to offer pull requests to them, but then I realize, filing an issue is more effective.
Let's just say again, you're both right and both wrong. There's no value to choosing one language/platform vs. the other if you're proficient in one or the other already. Unless you're padding your CV/resume it's best to simply program in whatever you like the most. They both have incredible merits.
If you compared either language to C or C++, I'd be totally different. Consider for instance modern meltdown/spector related CPU bugs. All the C/C++ code out there had to be recompiled and systems had to have scheduled downtown and there were reboots and verification testing and then additional patches to fix performance on those patches, etc...
Then there's relocatable memory. I despise any code where memory is allocated by pointer rather than by reference. Referenced memory can be paged, compressed, relocated, etc... this means that the system MMU can have much shorter tables to traverse when performing memory reads and writes since it is possible to use unaligned memory as well as to defragment and garbage collect on idle cycles. The kernel could run a process that did nothing more than to decrease the complexity of the GDT and LDT while idle. That said, we can do that to a limited extent, but because of "C purists", defragmentation on application and kernel level is impossible.
I'm heading to lunch now. Thanks for the opportunity to rant for a while.