3 ms·
A pretty big part of the reason we didn't switch earlier is that most people—certainly most non-technical leaders, but also a lot of engineers—don't value corre
by tikhonj 2mo ago
A pretty big part of the reason we didn't switch earlier is that most people—certainly most non-technical leaders, but also a lot of engineers—don't value correctness or security enough. We didn't have good alternatives until recently because we did not, collectively, invest in developing these alternatives.
One surprising thing is that, in the grand scheme of things, developing an alternative like Rust is not that expensive. It takes something like a small team a few years. Maybe a person-decade of effort to get to a viable point? Maybe two, whatever. The industry as a whole throws away orders of magnitude more engineering-years than that on vanity projects and internal dysfunction every year.
Of course, even once we have an alternative, the switching costs are high. And the barriers are far more social, organizational and political than they are technical. But even so, moving to alternatives incrementally has been viable for decades. And hey, if we include moves to garbage collected languages, we have been moving quite a bit... but we could have been moving more. It was only a matter of will and, upstream of that, cultural change.
So really, the problem isn't that people complain too much, it's that they don't complain enough :)
- MichaelZuo 2mo agoThe real curious thing is serious C/C++ folks seem like one of the least likely groups imaginable, to want to undergo humiliating and embarrassing blunders… Yet they seemingly don’t mind that it practically guarantees them to make blunders over and over again.
- gtowey 2mo agoWe call them blunders mostly because the solutions are so well known. In contrast, the last company I worked for did everything in typescript and the amount of problems caused by code that blocked the main event loop was staggering. And at that, our best JavaScript people generally just threw up their arms saying there wasn't a good way to fix it. Between the two, I prefer a language that lets me fix problems.
- fennecbutt 2mo ago"our best java script people" I've used node.js for more than a decade now, I was there for the start of "now everyone is truly full stack"...but yes the majority of developers I've worked with have had no idea about how js etc works on the inside, no knowledge of event loop or what causes the few memory leaks possible in js. But then again I only know because I love that shit and started out in c/embedded, c# etc. And on my own weak side I fucken suuuuck at frontend related stuff (not the design stuff at all, just...fuck you css).
- IshKebab 2mo agoPre-Rust "serious C++ folks" used it because it was the best option if you wanted essentially zero performance overhead no heavy runtime and GC spikes. They didn't like the lack of memory safety but it was seen as an unfortunate but necessary trade-off. These days most of the sensible people have moved from C++ to Rust and so the "serious C++ folks" are an entirely different distribution of people who are much more inclined to think memory safety isn't a big deal and you just have to not make mistakes.
- myko 2mo agoor Swift! I know it isn't super popular outside of Apple ecosystems but I migrated a C 200k LOC personal project to Swift over the last ~4 years and it's gone really well.
- rustfreeforme 2mo ago[dead]
- deterministic 2mo ago> These days most of the sensible people have moved from C++ to Rust Wrong. There are more than 16 million C++ developers worldwide.
- deterministic 2mo agoShow me a programming language that doesn't result in developers "making blunders over and over again" when developing the kind of very large software C/C++ is used for.
- scrame 2mo ago> The industry as a whole throws away orders of magnitude more engineering-years than that on vanity projects The industry as a whole throws away orders of magnitude more engineering-years _daily_ in meetings discussing if scrum standups are effective.
- gtowey 2mo ago> And the barriers are far more social, organizational and political than they are technical. At the core it's even more of an economic barrier which isn't even unique to capitalism. I recall an article talking about why the Romans didn't invent steam engines and things like railroads considering people were aware that steam could be used to do work. The answer was largely that slave labor was so cheap that nobody really cared about finding more efficiency. It didn't solve any problem they had at the time. The analogy transfers to the tech industry today, economics tend to drive most decisions. While I love technology and think research and innovation is important for its own sake -- particularly because we might not know what we're missing out on unless we explore -- but those controlling the purse strings have other priorities. Others might point out that the economic cost of the bugs and failure cases in programming languages without memory safety might actually be greater than the cost of developing alternatives or accepting less performance in exchange for correctness. They're probably right! But unless you can measure it and present it on a spreadsheet to the management class, they won't acknowledge or understand it. It's really difficult to measure "incidents you didn't have". In any case it still might be cheaper to work on the next big startup idea, hype it & sell equity -- that strategy has produced trillion-dollar valuations recently. However correctly or incorrectly that may be, the benefit to an elite few is very real.
- deterministic 2mo ago> ... don't value correctness or security enough Wrong. It is the market that doesn't value correctness or security enough. We have the tools (formal verification) to create bug free software (see seL4 and CompCert for example). However customers are not willing to pay for the extra cost needed.