4 ms·

That's a valid point, but what you're saying is that the feature is only intended to help create log messages and the like, which raises the question of why add

by pron 5y ago

That's a valid point, but what you're saying is that the feature is only intended to help create log messages and the like, which raises the question of why add a feature with so little utility when it could have much greater utility? There's a missed opportunity here. But let me push on it a little more. I think that what you're seeing isn't so much a culture thing but a small ecosystem thing. Imagine that Rust takes off and in ten years there are 1M professional Rust programmers who use the language because that's the one chosen by their employer. You'll not have one JSON library (or whatever other format will be used then) but 50 and so on, and most programmers will not be experienced ones but relative novices (to programming in general). How likely would it be for them to generate JSON with format! ? So this feature provides a better user experience for the less safe path. A feature should be designed with the next 20 years in mind.

tialaramex 5y ago
This isn't a language feature? It's a macro. So in terms of weight pulled by a feature it is not competing with say, the add-and-assign operator +=, or even with the AddAssign operator overload trait (which is a langitem), but only with some library feature like euclidean remainder on integers, which I hope you will agree is unlikely to be more commonly used than format interpolation. I don't know why you think that serde_json isn't good enough and so 49 other JSON libraries will spring up, but I also don't know why you're sure a programmer will decide they ought to write format!("\"{json_string}\"") but you're confident they would never write format!("\"{}\"", json_string). People determined to shoot themselves in the foot are going to do it, we provide much better, simpler, clearer ways to do what they wanted to do, but in general purposes languages it will always be possible for them to point the gun at their feet, dismiss the warning "CAUTION! Do not shoot yourself in the foot", click the safety and pull the trigger. Finally, Rust doesn't have to design all its features with 20 years of unknowable future implausibly considered in advance, because it has Editions. If you're correct and we regret providing format!() the Rust 2040 edition needn't provide this, and old code still works.
- littlestymaar 5y ago
  > This isn't a language feature? It's a macro. In this current form yes, but f-strings is a language feature, and with this announcement, there's a lot of people hoping for f-string to arrive too.
- pron 5y ago
  > I don't know why you think that serde_json isn't good enough and so 49 other JSON libraries will spring up Because I have some decades of experience. > I also don't know why you're sure a programmer will decide they ought to write format!("\"{json_string}\"") but you're confident they would never write format!("\"{}\"", json_string). That's not my argument. I am not saying string formatting will make injection vulnerabilities more likely, but that it's a missed opportunity to make them less likely. You add a new feature because it's more convenient and attractive, and so you expect people to use it. If you know that feature touches on what's known to be one of the most dangerous aspects of programming, you might as well make it more convenient and safer, so that you attract programmers away from the less safe options and toward the safer ones.
  - tialaramex 5y ago
    > Because I have some decades of experience. Is this decades of experience with Rust (from 2015) or decades of experience with JSON (from 2001) ? Or just decades of experience making implausible predictions? Here's how you make a JSON string in serde_rust here in 2022: let s = Value::String(myString); Here's how you propose programmers will erroneously try to make a JSON string in 2042 abusing the format macro: let s = format!("\"{myString}\""); Here's how I think programmers will successfully make JSON strings in 2042 using serde_json which is obviously the right tool for the job: let s = Value::String(myString);
    - pron 5y ago
      Other typed languages, including those far more popular than Rust, have had libraries like serde — which are obviously the right tool for the job — for many years, and yet if 0.1% of their programmers make a mistake, that's enough to make it one of the most common and dangerous vulnerabilities. We know some programmers make that mistake because that's what security research shows, which is why the language and type system should reduce its chances. Are you saying that you're not worried about that 0.1% because you can be certain even one programmer in a thousand won't make such mistakes, or because you don't expect Rust to be popular enough for that number to matter?
littlestymaar 5y ago
> That's a valid point, but what you're saying is that the feature is only intended to help create log messages and the like, Yes exactly. > which raises the question of why add a feature with so little utility It's indeed not the most important feature ever, but after running a quick `rg "format!" | wc -l` in my Rust directories (for both work and hobby projects), it found 2797 occurrences, which isn't nothing. > when it could have much greater utility? There's a missed opportunity here. I bet most people in the Rust team are simply not aware of the recent Java developments on that front. Hopefully having an openjdk developer sharing insight and documentation on that topic on public forums can foster cross-pollination on that topic :).
avgcorrection 5y ago
Now that it has been demonstrated that your original argument has no legs to stand on you retreat to some hypothetical what-if involving popularity and two extra decades. So what if someone manages to argue against that? Will you just add 100+ million users and 50 years? Of course culture matters. It isn’t just a side-effect of popularity. Would Scala have the same culture as Java if it became simiarily popular? I doubt it. Rust has a culture—and it comes from a wider culture of the same ilk—where such messy shortcuts are not taken; instead “fancy language features” (much to some people’s chagrin…) like compile-time evaluation are used to make safer user interfaces for programmers. And that makes for less catastrophically buggy software.
- pron 5y ago
  But here both Scala and Java have opted for a similar compile-time evaluation strategy that makes use of the type system to reduce injection vulnerabilities, whereas Rust has opted for the untyped (or "stringly-typed") messy shortcut of "people shouldn't do that."
  - avgcorrection 5y ago
    Fair. Let’s see how it plays out.

by pron 5y ago

tialaramex 5y ago

This isn't a language feature? It's a macro. So in terms of weight pulled by a feature it is not competing with say, the add-and-assign operator +=, or even with the AddAssign operator overload trait (which is a langitem), but only with some library feature like euclidean remainder on integers, which I hope you will agree is unlikely to be more commonly used than format interpolation. I don't know why you think that serde_json isn't good enough and so 49 other JSON libraries will spring up, but I also don't know why you're sure a programmer will decide they ought to write format!("\"{json_string}\"") but you're confident they would never write format!("\"{}\"", json_string). People determined to shoot themselves in the foot are going to do it, we provide much better, simpler, clearer ways to do what they wanted to do, but in general purposes languages it will always be possible for them to point the gun at their feet, dismiss the warning "CAUTION! Do not shoot yourself in the foot", click the safety and pull the trigger. Finally, Rust doesn't have to design all its features with 20 years of unknowable future implausibly considered in advance, because it has Editions. If you're correct and we regret providing format!() the Rust 2040 edition needn't provide this, and old code still works.

littlestymaar 5y ago
> This isn't a language feature? It's a macro. In this current form yes, but f-strings is a language feature, and with this announcement, there's a lot of people hoping for f-string to arrive too.
pron 5y ago
> I don't know why you think that serde_json isn't good enough and so 49 other JSON libraries will spring up Because I have some decades of experience. > I also don't know why you're sure a programmer will decide they ought to write format!("\"{json_string}\"") but you're confident they would never write format!("\"{}\"", json_string). That's not my argument. I am not saying string formatting will make injection vulnerabilities more likely, but that it's a missed opportunity to make them less likely. You add a new feature because it's more convenient and attractive, and so you expect people to use it. If you know that feature touches on what's known to be one of the most dangerous aspects of programming, you might as well make it more convenient and safer, so that you attract programmers away from the less safe options and toward the safer ones.
- tialaramex 5y ago
  > Because I have some decades of experience. Is this decades of experience with Rust (from 2015) or decades of experience with JSON (from 2001) ? Or just decades of experience making implausible predictions? Here's how you make a JSON string in serde_rust here in 2022: let s = Value::String(myString); Here's how you propose programmers will erroneously try to make a JSON string in 2042 abusing the format macro: let s = format!("\"{myString}\""); Here's how I think programmers will successfully make JSON strings in 2042 using serde_json which is obviously the right tool for the job: let s = Value::String(myString);
  - pron 5y ago
    Other typed languages, including those far more popular than Rust, have had libraries like serde — which are obviously the right tool for the job — for many years, and yet if 0.1% of their programmers make a mistake, that's enough to make it one of the most common and dangerous vulnerabilities. We know some programmers make that mistake because that's what security research shows, which is why the language and type system should reduce its chances. Are you saying that you're not worried about that 0.1% because you can be certain even one programmer in a thousand won't make such mistakes, or because you don't expect Rust to be popular enough for that number to matter?

littlestymaar 5y ago

> That's a valid point, but what you're saying is that the feature is only intended to help create log messages and the like, Yes exactly. > which raises the question of why add a feature with so little utility It's indeed not the most important feature ever, but after running a quick `rg "format!" | wc -l` in my Rust directories (for both work and hobby projects), it found 2797 occurrences, which isn't nothing. > when it could have much greater utility? There's a missed opportunity here. I bet most people in the Rust team are simply not aware of the recent Java developments on that front. Hopefully having an openjdk developer sharing insight and documentation on that topic on public forums can foster cross-pollination on that topic :).

avgcorrection 5y ago

Now that it has been demonstrated that your original argument has no legs to stand on you retreat to some hypothetical what-if involving popularity and two extra decades. So what if someone manages to argue against that? Will you just add 100+ million users and 50 years? Of course culture matters. It isn’t just a side-effect of popularity. Would Scala have the same culture as Java if it became simiarily popular? I doubt it. Rust has a culture—and it comes from a wider culture of the same ilk—where such messy shortcuts are not taken; instead “fancy language features” (much to some people’s chagrin…) like compile-time evaluation are used to make safer user interfaces for programmers. And that makes for less catastrophically buggy software.

pron 5y ago
But here both Scala and Java have opted for a similar compile-time evaluation strategy that makes use of the type system to reduce injection vulnerabilities, whereas Rust has opted for the untyped (or "stringly-typed") messy shortcut of "people shouldn't do that."
- avgcorrection 5y ago
  Fair. Let’s see how it plays out.