3 ms·

I'm a fairly seasoned C programmer. I actually started with C++ back in the last century, but when I had the chance to do plain C I quickly saw it's benefits o

by krupan 8y ago

I'm a fairly seasoned C programmer. I actually started with C++ back in the last century, but when I had the chance to do plain C I quickly saw it's benefits over C++ (at least back then). I have long pined for a better language that could be used for embedded systems programming. In my current job I am now using C++14/17 (not my choice). I'm starting to like auto, but not much else. The "smart" pointers and "move" are hard for me to reason about still. I'd have an easier time reasoning about raw pointers and references, mainly because that's all I had in my early C++ days and C days (of course). I think things like asan and ubsan are far more helpful even with plain C than features like smart pointers. I've tried Rust. The author of TFA linked to another article explaining that rust tricks you because it looks like languages you have used before, but it's really not like them. That made me feel better about my experience. I found it to be very frustrating. I'll have to try it again with a different mindset. I haven't tried go, but I don't feel like it's a viable embedded programming language because of it's garbage collector. At least not for tightly contrained embedded systems. I'm honestly not sure rust is going to work for those types of systems either. Sometimes you just have to poke bits into memory and I'm not sure how a super safe language will deal with that better than C.

pcwalton 8y ago
> I think things like asan and ubsan are far more helpful even with plain C than features like smart pointers. I agree. Smart pointers are not effective safety features. They mostly add new ways to get use-after-free. (shared_ptr helps a bit by automatically bumping reference counts, but shared_ptr is often discouraged in modern C++, and there are lots of ways to get around this, such as "shared_ptr&".) > I'm honestly not sure rust is going to work for those types of systems either. Sometimes you just have to poke bits into memory and I'm not sure how a super safe language will deal with that better than C. Read the "Writing an OS in Rust" series. Even in the kernel, you can have a relatively small trusted computing base and then most of the rest of the code can be safe.
bebna 8y ago
I'm probably the exact opposite, I'm more a Jack of all trades, master of none. I jump from language or framework to another without any remorse, just trying to do the best given time, resources and project needs. I did work with c (text template engine lib / x11 gui app / personal kernel module / dpdk userspace networking / arduino & pi baremetal stuff / ...), C++ (mostly some qt stuff for my old blackberry Q10), Java (I'm probably one of the few who liked Swing...), Go (backend servers), Python 2/3 (Some webdev, mostly admin scripts), PHP 4-7 (web/cli...), js (basic stuff and jQuery, trying to get into dart and flutter next...) When I try to see my self in the shoes of a primary C dev, I wouldn't see Go as a concurrent to C, but more as a less annoying scripting language. Every time when I switch from a "typed" to an "untyped" language, I do need a longer time to "feel at home" again. Therefore I think Go could be good language for a C dev for small tasks on the site, like creating small cli tools for the buildchain or generally inhouse, things like that what one normally tends to look at python for. Go makes it easy to create a good cli interface, easy to document the format of a config file and writing a test. Deployment is also easy thanks to that is just a static blob that comes with everything that it needs. So no worrying about if the right interpreter is installed on that dev server, just copy it over with scp and it works.

by krupan 8y ago

pcwalton 8y ago

> I think things like asan and ubsan are far more helpful even with plain C than features like smart pointers. I agree. Smart pointers are not effective safety features. They mostly add new ways to get use-after-free. (shared_ptr helps a bit by automatically bumping reference counts, but shared_ptr is often discouraged in modern C++, and there are lots of ways to get around this, such as "shared_ptr&".) > I'm honestly not sure rust is going to work for those types of systems either. Sometimes you just have to poke bits into memory and I'm not sure how a super safe language will deal with that better than C. Read the "Writing an OS in Rust" series. Even in the kernel, you can have a relatively small trusted computing base and then most of the rest of the code can be safe.

bebna 8y ago

I'm probably the exact opposite, I'm more a Jack of all trades, master of none. I jump from language or framework to another without any remorse, just trying to do the best given time, resources and project needs. I did work with c (text template engine lib / x11 gui app / personal kernel module / dpdk userspace networking / arduino & pi baremetal stuff / ...), C++ (mostly some qt stuff for my old blackberry Q10), Java (I'm probably one of the few who liked Swing...), Go (backend servers), Python 2/3 (Some webdev, mostly admin scripts), PHP 4-7 (web/cli...), js (basic stuff and jQuery, trying to get into dart and flutter next...) When I try to see my self in the shoes of a primary C dev, I wouldn't see Go as a concurrent to C, but more as a less annoying scripting language. Every time when I switch from a "typed" to an "untyped" language, I do need a longer time to "feel at home" again. Therefore I think Go could be good language for a C dev for small tasks on the site, like creating small cli tools for the buildchain or generally inhouse, things like that what one normally tends to look at python for. Go makes it easy to create a good cli interface, easy to document the format of a config file and writing a test. Deployment is also easy thanks to that is just a static blob that comes with everything that it needs. So no worrying about if the right interpreter is installed on that dev server, just copy it over with scp and it works.