8 ms·

Because for most software 'good enough' is the best outcome. Users don't care if you wrote it in Rust (unless the target audience is developers). All they care

Because for most software 'good enough' is the best outcome. Users don't care if you wrote it in Rust (unless the target audience is developers). All they care about is if it solves their actual problem: a real world, pain-in-the-neck problem. If you take 20% longer to write it in Rust, that's short term cost for long term gain, but users don't think that way. Everyone from the users, sales, marketing, product and even engineering departments want the product out the door yesterday, so the pressure is always on. Users don't care if you need 30% fewer CI servers. The CEO doesn't care if one additional dev has to spend his time making sure asan, ubsan, etc are running properly. This is cost factored into pricing. Coverage metrics are used as proxy metrics for quality. Meanwhile the devs are wrangling the complexity of the software itself, which requires mental resources. Any additional complexity introduced by Rust slows down development and frustrates the team and stakeholders. And the bugs are still there. So many bugs from devs who were sloppy or couldn't tame the complexity that +-20% due to Rust doesn't matter. The QA team still needs to exist and test the product thoroughly. The issues still come back and require fixing, regardless of language used or frequency of bad bugs. In the end, this software process produces acceptable, good enough software that gets fixed, patched, updated, etc Users see improvements and progress. Operating efficiency becomes important only after the product is out and stable, with paying customers and product-market fit, but by then, why boil the ocean with a rewrite? Sometimes leadership can be sold on a new and improved v2 (now in Rust), and sometimes they see it as a distraction from the current target (if it ain't broke, don't fix it, add more features instead). That's why I think we need languages that make it less mentally taxing for developers to write product software (because the logistics are already complicated), while features like the borrow checker, though cool, increase the mental overhead.

vore 4y ago
You hit the nail on the head with long term vs short term gain, but I think there is an additional factor to consider: software generally isn’t frozen at v1. You should also consider if using Rust reduces the toil of incremental changes to your software after its gold release.
- optymizer 4y ago
  I'm mentioning v2 towards the end (I did make a few edits so apologies if it was missing for you)
  - vore 4y ago
    It’s always hard to convince management of the business value of a v2 rewrite, especially if v1 works “well enough” from the outside :( Sometimes it’s easier to just front load the cost to avoid significant churn later.
briantkelley 4y ago
> Users don't care if you wrote it in Rust Totally agree! But they do care if Word corrupts a document that’s been open for 10 days (a bug that a principal engineer spent many, many weeks hunting down). > If you take 20% longer to write it in Rust, that's short term cost for long term gain, but users don't think that way. There are many steps between writing code and delivering a product to users. Sure, I can commit some C++ in less wall time than Rust (though I’m not actually sure that’s true!). But when we have to delay a major release by 2 weeks because there’s a heap corruption bug in the flagship feature, everyone loses. > the pressure is always on Sigh, yeah. It’s difficult for organizations to act in their own best interests. If a codebase primarily has architecture debt and little implementation quality debt, it’s much easier to keep taking the shortcuts to ship now. But with implementation quality debt, UB is lurking behind every corner and can cause the project to go off the rails at any time. This is why I would like to see more research about the value of Rust with respect to the predominant cost of engineering in extremely large systems: maintenance. > Users don't care if you need 30% fewer CI servers Sure, but DevOps does. When we have to drop jobs due to capacity constraints but mark the commit as stable anyway, it’s just a matter of time until a major regression sneaks in. > The CEO doesn't care if one additional dev has to spend his time making sure asan, ubsan, etc are running properly Haha, yeah, in practice it‘s always one dev maintaining the asan, ubsan, etc. loops! But, it’s up to engineers writing code to make sure it’s exercised by those systems, so in reality the loops are highly under utilized and eventually hard-to-find UB bug slips in. > Meanwhile the devs are wrangling the complexity of the software itself, which requires mental resources. Yes. And encoding ownership and lifetimes into the type system is a huge reduction in the mental tax when working through code that hasn’t been touched in years, or wiring up some feature to an interface another team just landed that’s not documented at all. Not having to reverse engineer the code to discern ownership and concurrency patterns is a huge time saver. > Any additional complexity introduced by Rust slows down development and frustrates the team I agree artificial complexity due to limitations of Rust’s soundness checks are frustrating, but a cost I’m willing to pay given the long term maintenance benefits. But the cost of system design complexity has to be paid at some point, and I’d rather pay as much as possible at compile time vs. discovering problems at run time. > And the bugs are still there. Certainly. But essentially eliminating classes of UB bugs that are hard to repro saves all the engineering teams time. > Operating efficiency becomes important only after the product is out and stable, with paying customers and product-market fit Yes. Total cost of ownership is what I want to see more research in. And I think this is the source of our deferring perspectives. My original comment wanted more research on TCO, but I don’t think that’s particularly applicable before product-market fit. > but by then, why boil the ocean with a rewrite? Who said anything about a rewrite? Use Rust for new development. And, as the system grows, components will be rewritten (whether due to new business needs or to improve maintainability). Don’t keep playing with fire when it’s no longer necessary! > Sometimes leadership can be sold on a new and improved v2 Perhaps I’m jaded, but my motto is “Rewrites always fail.” > we need languages that make it less mentally taxing for developers to write product software For extremely large systems whose codebases have been written over decades, we need languages that make it less mentally taxing for developers to maintain product software. The complexity of maintaining these systems is why FAANG employs tens of thousands of engineers who seem to move slower than an aircraft carrier. The difficulty in reasoning about system behavior greatly impedes progress.
kajaktum 4y ago
> That's why I think we need languages that make it less mentally taxing for developers to write product software (because the logistics are already complicated), while features like the borrow checker, though cool, increase the mental overhead. But all Rust do is expose those issues? For example, do you consider a type checker a burden or a help? Is being able to check at compile time that “hey, why are you trying to pass a nullable to a string? This don’t make sense” helpful? I cant count on how many times have saved my time debugging issues. I agree that Rust is not for everyone. Not everyone will like types even if it good for them. I would argue that a language that can accept dev/random as source to be very popular especially because you can get started very easily even if that means you will spend the rest of your life debugging it.
- optymizer 4y ago
  It's not whether it's a burden or help, those words have connotations associated with them. The type system is objectively overhead, because it forces you to think about the types in your program, so it consumes mental bandwidth. You and I might decide the cost is well worth it, but you cannot ignore that there is a cost. In the real world, many companies didn't always want to incur that cost in the beginning, so they built their products using scripting languages, Python/PHP/Ruby, etc and only much later added types via annotations or features of the language. Even C++ recognizes that there is a sizable overhead and introduced auto types. Your /dev/random example makes no sense because it would not generate a working program, so it would not be popular. There is no 'good for you'. Is the type system good for you if it slows down your velocity? Are dynamic types good for you if you get an exception deep in the code one hour before launch because someone was adding a string to a number? There are only trade-offs. You either make the right trade-off (even by luck) given some set of goals and limitations, or you don't and pay the price one way or the other.
  - kajaktum 4y ago
    >The type system is objectively overhead, because it forces you to think about the types in your program, so it consumes mental bandwidth. I don't understand this point. Types is an overhead yes, but its an overhead that you _have_ to deal with. Would typing without knowing what letters would come up be a lesser burden? Seeing the code that I just wrote seems to be an overhead too. Types is simply there to tell you what you wrote. Much like when I realized I mistyped `j` instead of `k`, I would also realize that I am trying to append an `Object` to a `number`. > Your /dev/random example makes no sense because it would not generate a working program, so it would not be popular. My point is that a language that will literally, and I mean literally, accept any and all source code and execute them is probably going to be popular. Just imagine a language designed with this goal in mind; to make the set of possible program in the language be the entire space of possible sequences of texts. For example, ``` 00000what????; function hello() { world } ``` This seems meaningless. But with that mantra in mind we can simply define that any line that is undecipherable be a declaration to an unused string. Why not? So the first line is is simply something like `let _ = "00000what????";` And the second one is simply a function that returns the string `world`. Why? Oh because its so inconvenient to put quotations to declare a string isn't it? I think you'd agree that this language is horrible. It might be faster to get to a prototype but I personally can't imagine maintaining a codebase written in this language. Have you considered that this is exactly what JS is like (in spirit)? It defines so many things that would otherwise not be defined in other languages. For example, what does this even mean? Without looking at the spec, tell me what it does? ``` function hello() { 1.0 + "hello" } console.log(hello()) ``` Does this program even makes sense? Does this program makes any more sense than something like ``` "helloworld"(); ``` Not even JS would compile this, but why not? Why not simply throw an exception here? Something like "function not found"? Since this clearly works ``` const a = { "hello": ()=>{console.log("world")} } a["hello"]() ``` The set of possible program is JS is much, much larger than any other languages. There's so many little tricks that the language provide that makes it so powerful and so much worse.
claytongulick 4y ago
I agree with your point completely. I also use a lot of these points when I explain why I use NodeJS and avoid typescript for most of my projects. The thing is though, it really depends on the project. Most of my projects are web UI heavy with simple commodity CRUD RESTful APIs sprinkled with business logic. Time to market tends to be the biggest constraint (I live in startup world), so "good enough" performance and a loose type system are perfect for that. If I was writing SCADA controllers for a nuclear power plant, my choice of technology would be much different. The sorts of "rah rah" debates we have on HN about languages frequently don't take the specific project characteristics into account. Like with everything, it boils down to intelligently selecting the right tool for the job.

vore 4y ago

You hit the nail on the head with long term vs short term gain, but I think there is an additional factor to consider: software generally isn’t frozen at v1. You should also consider if using Rust reduces the toil of incremental changes to your software after its gold release.

optymizer 4y ago
I'm mentioning v2 towards the end (I did make a few edits so apologies if it was missing for you)
- vore 4y ago
  It’s always hard to convince management of the business value of a v2 rewrite, especially if v1 works “well enough” from the outside :( Sometimes it’s easier to just front load the cost to avoid significant churn later.

briantkelley 4y ago

> Users don't care if you wrote it in Rust Totally agree! But they do care if Word corrupts a document that’s been open for 10 days (a bug that a principal engineer spent many, many weeks hunting down). > If you take 20% longer to write it in Rust, that's short term cost for long term gain, but users don't think that way. There are many steps between writing code and delivering a product to users. Sure, I can commit some C++ in less wall time than Rust (though I’m not actually sure that’s true!). But when we have to delay a major release by 2 weeks because there’s a heap corruption bug in the flagship feature, everyone loses. > the pressure is always on Sigh, yeah. It’s difficult for organizations to act in their own best interests. If a codebase primarily has architecture debt and little implementation quality debt, it’s much easier to keep taking the shortcuts to ship now. But with implementation quality debt, UB is lurking behind every corner and can cause the project to go off the rails at any time. This is why I would like to see more research about the value of Rust with respect to the predominant cost of engineering in extremely large systems: maintenance. > Users don't care if you need 30% fewer CI servers Sure, but DevOps does. When we have to drop jobs due to capacity constraints but mark the commit as stable anyway, it’s just a matter of time until a major regression sneaks in. > The CEO doesn't care if one additional dev has to spend his time making sure asan, ubsan, etc are running properly Haha, yeah, in practice it‘s always one dev maintaining the asan, ubsan, etc. loops! But, it’s up to engineers writing code to make sure it’s exercised by those systems, so in reality the loops are highly under utilized and eventually hard-to-find UB bug slips in. > Meanwhile the devs are wrangling the complexity of the software itself, which requires mental resources. Yes. And encoding ownership and lifetimes into the type system is a huge reduction in the mental tax when working through code that hasn’t been touched in years, or wiring up some feature to an interface another team just landed that’s not documented at all. Not having to reverse engineer the code to discern ownership and concurrency patterns is a huge time saver. > Any additional complexity introduced by Rust slows down development and frustrates the team I agree artificial complexity due to limitations of Rust’s soundness checks are frustrating, but a cost I’m willing to pay given the long term maintenance benefits. But the cost of system design complexity has to be paid at some point, and I’d rather pay as much as possible at compile time vs. discovering problems at run time. > And the bugs are still there. Certainly. But essentially eliminating classes of UB bugs that are hard to repro saves all the engineering teams time. > Operating efficiency becomes important only after the product is out and stable, with paying customers and product-market fit Yes. Total cost of ownership is what I want to see more research in. And I think this is the source of our deferring perspectives. My original comment wanted more research on TCO, but I don’t think that’s particularly applicable before product-market fit. > but by then, why boil the ocean with a rewrite? Who said anything about a rewrite? Use Rust for new development. And, as the system grows, components will be rewritten (whether due to new business needs or to improve maintainability). Don’t keep playing with fire when it’s no longer necessary! > Sometimes leadership can be sold on a new and improved v2 Perhaps I’m jaded, but my motto is “Rewrites always fail.” > we need languages that make it less mentally taxing for developers to write product software For extremely large systems whose codebases have been written over decades, we need languages that make it less mentally taxing for developers to maintain product software. The complexity of maintaining these systems is why FAANG employs tens of thousands of engineers who seem to move slower than an aircraft carrier. The difficulty in reasoning about system behavior greatly impedes progress.

kajaktum 4y ago

> That's why I think we need languages that make it less mentally taxing for developers to write product software (because the logistics are already complicated), while features like the borrow checker, though cool, increase the mental overhead. But all Rust do is expose those issues? For example, do you consider a type checker a burden or a help? Is being able to check at compile time that “hey, why are you trying to pass a nullable to a string? This don’t make sense” helpful? I cant count on how many times have saved my time debugging issues. I agree that Rust is not for everyone. Not everyone will like types even if it good for them. I would argue that a language that can accept dev/random as source to be very popular especially because you can get started very easily even if that means you will spend the rest of your life debugging it.

optymizer 4y ago
It's not whether it's a burden or help, those words have connotations associated with them. The type system is objectively overhead, because it forces you to think about the types in your program, so it consumes mental bandwidth. You and I might decide the cost is well worth it, but you cannot ignore that there is a cost. In the real world, many companies didn't always want to incur that cost in the beginning, so they built their products using scripting languages, Python/PHP/Ruby, etc and only much later added types via annotations or features of the language. Even C++ recognizes that there is a sizable overhead and introduced auto types. Your /dev/random example makes no sense because it would not generate a working program, so it would not be popular. There is no 'good for you'. Is the type system good for you if it slows down your velocity? Are dynamic types good for you if you get an exception deep in the code one hour before launch because someone was adding a string to a number? There are only trade-offs. You either make the right trade-off (even by luck) given some set of goals and limitations, or you don't and pay the price one way or the other.
- kajaktum 4y ago
  >The type system is objectively overhead, because it forces you to think about the types in your program, so it consumes mental bandwidth. I don't understand this point. Types is an overhead yes, but its an overhead that you _have_ to deal with. Would typing without knowing what letters would come up be a lesser burden? Seeing the code that I just wrote seems to be an overhead too. Types is simply there to tell you what you wrote. Much like when I realized I mistyped `j` instead of `k`, I would also realize that I am trying to append an `Object` to a `number`. > Your /dev/random example makes no sense because it would not generate a working program, so it would not be popular. My point is that a language that will literally, and I mean literally, accept any and all source code and execute them is probably going to be popular. Just imagine a language designed with this goal in mind; to make the set of possible program in the language be the entire space of possible sequences of texts. For example, ``` 00000what????; function hello() { world } ``` This seems meaningless. But with that mantra in mind we can simply define that any line that is undecipherable be a declaration to an unused string. Why not? So the first line is is simply something like `let _ = "00000what????";` And the second one is simply a function that returns the string `world`. Why? Oh because its so inconvenient to put quotations to declare a string isn't it? I think you'd agree that this language is horrible. It might be faster to get to a prototype but I personally can't imagine maintaining a codebase written in this language. Have you considered that this is exactly what JS is like (in spirit)? It defines so many things that would otherwise not be defined in other languages. For example, what does this even mean? Without looking at the spec, tell me what it does? ``` function hello() { 1.0 + "hello" } console.log(hello()) ``` Does this program even makes sense? Does this program makes any more sense than something like ``` "helloworld"(); ``` Not even JS would compile this, but why not? Why not simply throw an exception here? Something like "function not found"? Since this clearly works ``` const a = { "hello": ()=>{console.log("world")} } a["hello"]() ``` The set of possible program is JS is much, much larger than any other languages. There's so many little tricks that the language provide that makes it so powerful and so much worse.

claytongulick 4y ago

I agree with your point completely. I also use a lot of these points when I explain why I use NodeJS and avoid typescript for most of my projects. The thing is though, it really depends on the project. Most of my projects are web UI heavy with simple commodity CRUD RESTful APIs sprinkled with business logic. Time to market tends to be the biggest constraint (I live in startup world), so "good enough" performance and a loose type system are perfect for that. If I was writing SCADA controllers for a nuclear power plant, my choice of technology would be much different. The sorts of "rah rah" debates we have on HN about languages frequently don't take the specific project characteristics into account. Like with everything, it boils down to intelligently selecting the right tool for the job.