4 ms·
I think you’re blissfully unaware of just how many developers are still being trained in C/C++ this day. I agree with you that in the long run, Rust has everyth
by stingraycharles 5y ago
I think you’re blissfully unaware of just how many developers are still being trained in C/C++ this day. I agree with you that in the long run, Rust has everything going for it to replace C++, but these types of things happen in a span of several decades, not years.
- FpUser 5y agoI think Rust has the potential to coexist with C++. As for replacement - here is my shallow outlook (I only care about how new tech affects my own business). The safety offered by Rust is not a thing to ignore. However modern C++ and the tooling has made enough progress in the area. It is extremely rare for me to allocate explicitly and in the couple cases where I do I always write deallocator first. It is ingrained in my nature along with some other related habits. Invalid memory access is also less likely with modern constructs. Along with memory sanitizers and practical experience with my own products I feel that Rust memory safety at this point does not offer much from my practical point of view. I value very much time spent on compiling / building. From few experiments I made Rust is not any faster in this department. Rather the opposite. As for C++ being a monster impossible to comprehend in its entirety. Agree and do not give a flying fuck. I am not there to explore language to its utmost depths. It is just a tool for me and nothing more. I do not get hung up on tools. As long as the tool lets me do my job with the reasonable ease (and subset of modern C++ definitely does) the rest does not matter. I do not feel inferior for not willing to spend the rest of my life trying to become Alexandrescu.
- qalmakka 5y agoI write C++ for a living and I admit I do like to push it to its limits (SFINAE, constexpr/type traits shenanigans, the more the merrier), but it must be acknowledged that it tends to become too much akin to magic the more you push the envelope. Stuff like having 10 kinds of initialization and name resolution being incredibly complex and convoluted is a bit more confusing than what should be considered acceptable in a programming language. Still I love the utter madness that there's behind C++, and the fact you can basically do everything you set yourself to, no matter how crazy and weird it is, as long as you accept to put up with the madness. You can emulate a good 90% of what Rust does with traits if you really want to.
- FpUser 5y ago>"I write C++ for a living and I admit I do like to push it to its limits (SFINAE, constexpr/type traits shenanigans, the more the merrier)," I suspect maybe because you love programming as a process. I write C++ (other languages as well) for living but I am my own company, so my primary concern is to deliver more while spending less. The language on it's own means zilch to me as long as it adequate.
- qalmakka 5y agoWell, by pushing C++ you can enforce a lot of constraints at compile time, just like you do with Rust. For instance, by extensively using concepts or SFINAE (enable_if and friends) you can make type safe code that works well and (almost) never breaks. I rarely if ever need to fix runtime issues with my C++ (or Rust), because it almost always works at the first attempt. That's due to all the "fighting against the compiler" you need to do beforehand in order to get the code to compile in the first place, but it's generally worth the effort IMHO.
- deleted 5y ago[deleted]
- makapuf 5y agoSure, but the difficulty is being able to understand and modify other people code which can be all over the place.
- FpUser 5y agoI/my company personally did not ever encounter this particular issue so not a problem in my world. I understand it is still valid concern but I'd let the actual victims worry about it.
- worik 5y agoYou sound like you work in a wonderful environment. "where I do I always write deallocator first" that sounds like good practise. But software development is driven by marketers. Having the time to properly add in the features required for safety is important. From a marketing perspective it is a waste of money. When a change needs to be made, some feature that once lived under the hood and needs to be "surfaced", using some pointer into a structure in an unsafe manner will take five minutes, properly assembling the structures, rearranging the code etcetera takes two days - those days come off the profit of the company (from the marketing perspective) As a computer programmer it is fabulous to have the resources to do it safely. It is not the conditions that a lot of us (most of us?) work in. User visible features. All that matters. Memory safety? What is that!
- pjmlp 5y agoTime will come for the software version of health inspections and construction work safety visits, and then business will have to care. One example, https://iclg.com/practice-areas/cybersecurity-laws-and-regulations/usa https://iclg.com/practice-areas/cybersecurity-laws-and-regul...
- FpUser 5y ago>"You sound like you work in a wonderful environment." For the last 20+ years I sit in the basement of my house where I design and build my products. Some for my company. Some for clients. Every once in a while I would get out and meet with perspective clients / subcontractors or for some meeting with existing ones. But it gets increasingly more rare and everything is done using Zoom/Skype/Remote Deployments/Couriers. The only reason I get out is mostly for fun - meeting friends, cycling, swimming etc.
- zozbot234 5y ago> From few experiments I made Rust is not any faster in this department. Rather the opposite. Rust uses more generics in its idiomatic code than C++. If you're careful to split out your generic type impls to avoid excess code monomorphization, compile times can be manageable. Macro use brings similar concerns, but it's probably rarer unless you're relying on popular crates that need it such as serde.