| General > General Technical Chat |
| How many people code in C these days, and if so, why? |
| << < (89/99) > >> |
| radioactive:
--- Quote from: IDEngineer on May 17, 2020, 11:56:07 pm ---C with a small smattering of C++, --- End quote --- So, basically C with a small smattering of CS philosophy attached to it. |
| Fredderic:
--- Quote from: Wolfgang on May 17, 2020, 04:08:43 pm ---If you are allowed to use just *one* language in a large, real world problem ranging from GUI to math to drivers and control, data storage, multiplatform ... --- End quote --- One that gets far too little mention… D (dlang.org)… Older than most of the new crop (no Google or Mozilla pushing it so little less known), but it's been put to use in a number of large projects… Though it was built around a modern GC, there's ongoing (and already comprehensive) work to make that optional; and most of the standard library comes in at least both allocating and non-allocating forms. If the runtime it drags along is too much for you, the -betterC option pares it back to, pretty much as the name suggests. In general it has a huge emphasis on code safety even with (as opposed to, IMHO, C/C++'s tendency to pit features against each other) templating, introspection, compile time evaluation, contracts, and most of the other fancy modern dohickeys, wrapped up in a systems level language following the C/C++ train. Most recently that I've heard, they've been adding borrower checking to let it drop many of it's runtime checks, and better support alternative allocators like reference counting. It also strives to bind to other languages, notably being able to invoke C/C++ libraries (with caveats mostly around C++ memory management). The developers are fanatics, even without backing from those huge companies, it's continued to move forward and pick up steam, and it's been fairly solid except for a split early on when they decided to redo the standard library. And to answer the challenge more directly; D is being used for GUI (it has it's own, plus bindings several others), web back-end (vibe.d), math (right in the basic language, array/scalar math has SIMD in mind, and others quite readily), drivers (there's an ongoing project to reimplement the Linux kernel in D, starting with the drivers — to bring in D's safety guarantee's, and putting D's system-level claims to the test in the process), control (something in the locomotive industry), data storage (at least one significant product), and multiplatform too (Windows, Linux, Mac, ARM). On a more personal note, and to swing the pendulum to the other extreme, while it's still a little heavy-handed for my favourite 8-bitters, it's move into AVR ųC (generally in betterC mode) looks to be coming along nicely, and on the desktop, I've often found it easier to throw together D code for some quick tasks, than a comparable bash or Python script (runs a heck of a lot quicker, too). |
| radioactive:
--- Quote from: Fredderic on May 18, 2020, 01:46:21 am --- --- Quote from: Wolfgang on May 17, 2020, 04:08:43 pm ---If you are allowed to use just *one* language in a large, real world problem ranging from GUI to math to drivers and control, data storage, multiplatform ... --- End quote --- One that gets far too little mention… D (dlang.org)… --- End quote --- I really keep meaning to take a closer look at D. Really does look interesting and worth investigating further (haven't seen a reference to it in some time). Thanks for bringing that up. |
| SiliconWizard:
D is an interesting beast - I've looked at it almost since the beginning - almost 20 years ago. A lot of interesting ideas, including modules. Much closer to a decent "upgrade" of C than C++ ever was IMHO. I've unfortunately always stayed away in practice. Not enough people using it, not enough tools supporting it on various targets. These days, GCC includes a D compiler. I tried, but was not able to successfully build a D cross-compiler for ARM (cortex-M), or RISC-V targets, for instance. Still a significant way to go IMO. If any of you manages to get a working D compiler for embedded targets though, please chime in. |
| Fredderic:
--- Quote from: SiliconWizard on May 18, 2020, 02:37:03 pm ---I've unfortunately always stayed away in practice. Not enough people using it, not enough tools supporting it on various targets. These days, GCC includes a D compiler. I tried, but was not able to successfully build a D cross-compiler for ARM (cortex-M), or RISC-V targets, for instance. Still a significant way to go IMO. If any of you manages to get a working D compiler for embedded targets though, please chime in. --- End quote --- That seems to be a common statement. It also seems like most people who've switched to D, haven't regretted it, but there are indeed comparatively few, and it's a bit of an uphill battle to get there — many of them, started by doing bits of tooling around their main project in D, and once they had a good handle on it, and a successful track record, started to bring that through into the main project. On the upside, if you use the comparable features in C++, D will probably feel like a breath of fresh air. Also of some amusement, watching a "Cpp Chat" episode last night from late last year, one of the guys on the panel mentioned C++'s "if constexpr" was in fact their answer to D's "static if". Thought that was interesting timing that I'd come across that right after posting about D here. That sense they've been chasing D's tail a bit so as not to be left behind… I will say also, since getting to know D, I try to bring a lot more templating and constexpr into my ųC code, and though I have some success, compared to D it's always a fight to get it to work. By the same token, Rust seems to have redoubled D's efforts towards memory safety. It's always been one of their main goals, with @safe being a thing since forever, and the reason they went with a GC — solves a lot of memory-reuse issues right off the bat. But their work on the borrower checker does seem to be on the heals of Rust potentially swooping in and usurping one of their main goals. In turn, Rust's system brings flashbacks of doing GTK+ GUI in C, which what seems like weird for this day and age, considering D's push towards cleaner code… All up, it's a bit like watching a very, very, slow motion 3-way competitive dining event. And it's great! As for D on ARM, LDC seems to be the more reliable compiler there. I haven't done much in that regard myself, or tried cross-compiling D at all for that matter, but LDC's what worked for compiling D code on the Raspberry Pi I have running my home automation, and I've run across other people saying much the same in my searches on the topic prior… It also seems to be the compiler used in the slow push towards smaller AVR's I've been watching… Though I don't really hold out much hope it'll get there in a practical way… As much as I hate to say it, smaller systems just plain aren't on their radar, as much as they need it. It looks at this point, like that'll be a spot where Rust will make itself home, as gruesome and ungainly as it is. Whatever way it plays out, I think the single biggest thing against C/C++, is memory safety. That's an ongoing battle these days, and the main flag being carried by the newer languages. If anything finally kills off C/C++, I think that'll be it. |
| Navigation |
| Message Index |
| Next page |
| Previous page |