It seems like the philosophy prefers knowing ahead of time what's wrong over discovering it incidentally, and probably accidentally, after the fact.
That said, it’s not that simple. There are threshold effects (more than X amount of time = your company is dead) and intangibles (how do you feel while programming).
But anyone making a blanket statement without considering these things is participating in a dumb internet argument.
I have the assumption that once I am fluent in rust, more and more of the first code I write will be accepted by the borrow checker. The analogy is to C, where I don't really have to think consciously about, for example, assigning and dereferencing pointers. When I was a beginner C programmer (many years ago), I would write code and have it SIGSEGV immediately during test. Now that just doesn't happen unless I'm getting WAY too clever.
I discovered a bug that could potentially be triggered in the codebase where I work, but never has. It's about 5 years old.
You don't actually always need technically correct - sometimes you want practically correct, where "practically" covers a huge spectrum.
I'll disagree with this one. Refactoring old and rarely-touched code is bliss when working under a strong type system, at least relative to dynamic or weakly-typed languages. The key to the timely resolution of technical debt is to allow things to be updated in piecemeal rather than in one enormous burst; this requires solid abstraction boundaries and encapsulation, both of which are provided by types (in addition to other features of a language, such as a module system). The fact that Rust so heavily discourages global state is another point in its favor.
We can agree that there are contexts where correctness is less important than velocity, e.g. prototyping, though languages that front-load correctness at the expense of velocity are going to produce less technical debt in the first place, because the debts can be paid off before they accrue interest.
Because if say, 75% of your time is spent debugging in an "regular" language then you really aren't saving much time by reducing the amount of code you must write.
If we could reduce programming to typing in mostly correct code then software development will be much faster, even if the code we type is 50% longer.
Of course everyone wants the best of both worlds: everything now, zero bugs. Fast, cheap, right: pick two applies despite everyone wanting all three.
I thought we were discussing the trade-offs of typing a little more to guarantee correctness, or at least eliminate a class of software errors.
You're doing that Appeal to the Extremes Fallacy:
https://www.logicallyfallacious.com/tools/lp/Bo/LogicalFalla...
I'm not falling into appeal to extreme, even though I did point out an extreme.
That software's users will use the product is the number one metric. They'll use it so long as it achieves their goal with the reliability or security they tolerate. That often means it can be kind of flaky in terms of reliability. The security can be arbitrarily bad so long as they don't know it. Sometimes they'll still use the product if they know security is bad because they need it.
That's the baseline. From there, developers have to decide what's most beneficial among investments in more features, enhancements of existing features, new products/activities, or enhancing quality/reliability/security. They usually choose against that last set. So, doing the other things with the minimum quality that's acceptable makes the most economic and social sense.
How is this confusing?
If it takes you 2 weeks with language X to write a sloppily written app, that works 99% of the time but has some errors -- and 2 months with Rust to write a version of the same app that has no errors, what you'd you prefer?
Ever heard of "time to market"? What good it would be if you get it 100% right, and your competitor has their app already out, and captured all your potential customers?
And even if time to market is not involved, would you really care for some occasional errors, if you get the majority of the functionality you want working just fine?
If you build pacemakers and airplanes, the answer is yes.
If you build regular websites, apps, and scripts, the answer might very well be no.
That's the case, just the numbers (2 weeks, 100% etc) are made up.
But this is a classic race to the bottom, and regulation is coming. The days when you could write an app that takes a person's information and stores it negligently are drawing to a close. Given sufficient liability penalties, the economic question will shift away from "what if we're late" to "what if it's broken", and that's when you'll start seeing a shift away from languages like C/C++ (and probably also languages like Python and JavaScript) towards languages/platforms/tooling that provide strong, indemnifying guarantees.
Like BS regulations in cheese, wine making etc, has eliminated small regional producers (once dominant) in favor of large conglomerates -- at least France is somewhat holding up.
- Exempt smaller organizations. Maybe the classic example is the ACA in the US; if you're under a certain number of employees you don't need to provide health care. Obvious pitfalls, but still an option.
- Provide subsidies. This isn't exactly going to let a 10 person shop compete with someone like Airbus, but it does let you do things like hire staff and purchase tools to comply with regulations.
And separate from all that, it would be cool if we started enforcing antitrust legislation in the US again.
It’s a large, multi-variable problem. This is why it’s great that we have so many languages!
A constant stream of bugs have driven customers away before too, so if you're waiting in the wings with a bug-free/verified version of your competitor's program, you have a real shot at stealing their customers. First mover advantage is important, but so is quality if marketed properly.
I admit personally I'm inclined to agree with coldtea. But one example where I think the stability/quality of the software really did play an important role is WhatsApp. I remember when there were a bunch of competing services, but WhatsApp was the only reliable one. As far as I can tell there was nothing else that WhatsApp did better, and yet they 'won' (at least in Holland/Europe).
The interesting part is, WhatsApp is built using a dynamically-typed language whose guiding principle is to "let it crash." Your code will have bugs so plan accordingly.
Microsoft had a features-first mindset, which led to a Swiss-cheese-manifold of bugs and security flaws.
The result was that you couldn't install anything without risking a virus.
Businesses went with browser based solutions to avoid that risk.
if it takes 2x or 3x to get to the next iteration then what’s the point... (again, assuming we aren’t talking pacemakers etc)
just my feeling, but these low level languages that try to have it both ways (working in the bit/byte realms, but also super high correctness) aren’t suitable for the realm of high iteration.... instead some high level language amenable to rapid iteration but still have high reliability should instead be built on top of something like rust but not necessarily _in_ it...
[edit] forgot to mention parent post
I have heard more than once that if we could spend a few hours less developing at the cost of having the product need to reboot every day or so, it was worth it. Of course it was no safety critical code, but in the end the only discriminant is money.