4 ms·

Rust still means too much ceremony; there is a line where specifying more details makes the whole thing more difficult to understand and maintain; and that's st

Rust still means too much ceremony; there is a line where specifying more details makes the whole thing more difficult to understand and maintain; and that's still besides taking more time to write in the first place. Not everyone is into checking all the boxes, all the time; for good reasons; otherwise we'd all be coding Ada by now. Trying to shame others into adopting that mindset can only cause more division.

bschwindHN 9y ago
What's your alternative when writing parsers which need to handle untrusted input? This isn't a general "use Rust everywhere" article, it's focusing on these kinds of parsers and how we can do better against very real issues.
- pjmlp 9y ago
  Make use of parser generators like JetBrains MPS or ANTLR. The generated parsers should take the use case of untrusted input into account. Even if they don't do it currently, it should be easier to extend a generator that will take into account while using the same grammar specification.
- andreasgonewild 9y ago
  But that has nothing to do with Rust; this post and others is more or less claiming between the lines that the only thing that can save us from buggy software is the Rust way, which is bullshit. It didn't work for Java, or Erlang or Haskell; and it won't work for Rust; simply because the solution is experience, not more rules.
pjmlp 9y ago
Ada compilers targeting enterprise and military customers with deep pockets, alongside the industry's adoption of UNIX, where Ada compilers where something extra to buy instead of available for free C compiler[0] required for any UNIX related systems programming, did not help making the language more widespread. [0] Until they started selling the SDK as developer's edition addon
naasking 9y ago
> Not everyone is into checking all the boxes, all the time; for good reasons; Pray tell, what are these reasons? > otherwise we'd all be coding Ada by now That's not why we're not all writing Ada now.
- IshKebab 9y ago
  > what are these reasons? Because it takes longer, is more complicated and more difficult to design. You can't tell me that writing Rust is as easy as writing Go for example. I'm not saying Rust's heavy typing and borrow checker don't have advantages. Of course they do. But I do think too many people pretend it is always an obvious choice to take them. In many situations a simpler, less 'perfect' language like Go, Python, or even C++ is better. For example I don't think anyone is going to be writing AAA games in Rust any time soon, and not just because of language momentum.
  - naasking 9y ago
    > Because it takes longer, is more complicated and more difficult to design. So you mean it requires properly solving the hard problems implied by your application and your desired solution, instead of ignoring them and permitting latent safety and security violations. > You can't tell me that writing Rust is as easy as writing Go for example. GC will always be easier than lifetime checking. But that's not what you claimed: you said people have good reasons for not wanting to check all the (safety) boxes. Go also requires you to check all of its safety boxes too, so it isn't an example of what you claimed. Only languages like C and C++ which permit violating type safety are easy are examples of being justified in not wanting to check the safety boxes. And you have unsafe Rust for when you really need it. > In many situations a simpler, less 'perfect' language like Go, Python, or even C++ is better. C++ is not simpler. It's hilarious that some people think "familiar" somehow means "simpler".
    - riwsky 9y ago
      you present a good argument for ticking all the safety boxes, but the original comment you're citing doesn't specify safety; you're refuting an argument they didn't make. To count Go as an example, one could count "zero-cost abstractions" or "no runtime" as a box that Go doesn't check.
Peaker 9y ago
performance and safety are just 2 checkboxes. They're trying to establish that having both of those requires Rust's approach - and I think they're making a convincing argument.
burntsushi 9y ago
No, I don't think so. I maintain a popular command line tool that needs to be extremely fast, and Rust was an excellent choice for that. It's made it so much easier to maintain than equivalent C tools, and has made it easier for me to reach feature parity by nearly effortlessly depending on the work that so many others have done in the ecosystem. It's not bug free mind you, but that class of bugs doesn't include things like buffer overruns, double frees or memory leaks (note: Rust does not guarantee absence of memory leaks, but RAII pretty much makes sure it doesn't happen in practice).
- andreasgonewild 9y ago
  I would argue that writing it in C++ would have gotten you there faster, assuming a decent level of experience with the language. There's no ecosystem in the world that beats seamless integration with C and no language that even comes close to being as pragmatic.
  - burntsushi 9y ago
    > no language that even comes close to being as pragmatic. That's what I'm disagreeing with. I find Rust to be extremely pragmatic. There are other competing tools written in C++, and from where I'm standing, their maintenance story is quite a bit harder. Conversely, my tool works seamlessly on Windows, Mac and Linux.
    - andreasgonewild 9y ago
      If multi-platform is your biggest problem, I can see how that helps. I don't really care that much myself as long as my code compiles on the unixes. I sadly agree that static linking is a pain in the behind in C/C++ land. Still, the language I'm using interacts with the way I'm thinking; if that part isn't working out, all the features in the world isn't going to help.
      - burntsushi 9y ago
        Indeed. Windows support was critical, and I have a ton of users there as a result of it being so easy to distribute a Rust application to them. Microsoft even picked it up and is now shipping it in VS Code. :-) > Still, the language I'm using interacts with the way I'm thinking; if that part isn't working out, all the features in the world isn't going to help. Sure, and there was a lot of friction between me and Rust in the beginning. But my experience---and a lot others' experience as far as I'm aware---is that the friction settles down quite a bit. But yeah, experiences can vary there!
dochtman 9y ago
I disagree with your "too much ceremony" premise in general, but in particular I don't think it holds true for nom parsers. Here are two examples I've been working on: https://github.com/djc/askama/blob/master/askama_derive/src/parser.rs https://github.com/djc/askama/blob/master/askama_derive/src/... https://github.com/djc/tokio-imap/blob/master/src/parser.rs https://github.com/djc/tokio-imap/blob/master/src/parser.rs If you look at the parsing logic that makes up most of those files, I don't think you can reasonably argue there is a lot of ceremony going on.
- andreasgonewild 9y ago
  But I can, and I do; that's still too much noise for me. I'm sure the code is fine by Rust standards, but to me it looks like Perl with control issues. I don't need any help from my programming language with micromanaging the code I write or the way I write it. I'll ask when I want assistance, and until then I prefer if they stay the hell out of my way. I won't claim to write bug-free software; the only way to write bug-free software is to not write it at all; spending half my energy on sweet talking a psychotic compiler around every single detail is a perfect recipe for missing the bigger picture and ending up solving the wrong problems.

bschwindHN 9y ago

What's your alternative when writing parsers which need to handle untrusted input? This isn't a general "use Rust everywhere" article, it's focusing on these kinds of parsers and how we can do better against very real issues.

pjmlp 9y ago
Make use of parser generators like JetBrains MPS or ANTLR. The generated parsers should take the use case of untrusted input into account. Even if they don't do it currently, it should be easier to extend a generator that will take into account while using the same grammar specification.
andreasgonewild 9y ago
But that has nothing to do with Rust; this post and others is more or less claiming between the lines that the only thing that can save us from buggy software is the Rust way, which is bullshit. It didn't work for Java, or Erlang or Haskell; and it won't work for Rust; simply because the solution is experience, not more rules.

pjmlp 9y ago

Ada compilers targeting enterprise and military customers with deep pockets, alongside the industry's adoption of UNIX, where Ada compilers where something extra to buy instead of available for free C compiler[0] required for any UNIX related systems programming, did not help making the language more widespread. [0] Until they started selling the SDK as developer's edition addon

naasking 9y ago

> Not everyone is into checking all the boxes, all the time; for good reasons; Pray tell, what are these reasons? > otherwise we'd all be coding Ada by now That's not why we're not all writing Ada now.

IshKebab 9y ago
> what are these reasons? Because it takes longer, is more complicated and more difficult to design. You can't tell me that writing Rust is as easy as writing Go for example. I'm not saying Rust's heavy typing and borrow checker don't have advantages. Of course they do. But I do think too many people pretend it is always an obvious choice to take them. In many situations a simpler, less 'perfect' language like Go, Python, or even C++ is better. For example I don't think anyone is going to be writing AAA games in Rust any time soon, and not just because of language momentum.
- naasking 9y ago
  > Because it takes longer, is more complicated and more difficult to design. So you mean it requires properly solving the hard problems implied by your application and your desired solution, instead of ignoring them and permitting latent safety and security violations. > You can't tell me that writing Rust is as easy as writing Go for example. GC will always be easier than lifetime checking. But that's not what you claimed: you said people have good reasons for not wanting to check all the (safety) boxes. Go also requires you to check all of its safety boxes too, so it isn't an example of what you claimed. Only languages like C and C++ which permit violating type safety are easy are examples of being justified in not wanting to check the safety boxes. And you have unsafe Rust for when you really need it. > In many situations a simpler, less 'perfect' language like Go, Python, or even C++ is better. C++ is not simpler. It's hilarious that some people think "familiar" somehow means "simpler".
  - riwsky 9y ago
    you present a good argument for ticking all the safety boxes, but the original comment you're citing doesn't specify safety; you're refuting an argument they didn't make. To count Go as an example, one could count "zero-cost abstractions" or "no runtime" as a box that Go doesn't check.

Peaker 9y ago

performance and safety are just 2 checkboxes. They're trying to establish that having both of those requires Rust's approach - and I think they're making a convincing argument.

burntsushi 9y ago

No, I don't think so. I maintain a popular command line tool that needs to be extremely fast, and Rust was an excellent choice for that. It's made it so much easier to maintain than equivalent C tools, and has made it easier for me to reach feature parity by nearly effortlessly depending on the work that so many others have done in the ecosystem. It's not bug free mind you, but that class of bugs doesn't include things like buffer overruns, double frees or memory leaks (note: Rust does not guarantee absence of memory leaks, but RAII pretty much makes sure it doesn't happen in practice).

andreasgonewild 9y ago
I would argue that writing it in C++ would have gotten you there faster, assuming a decent level of experience with the language. There's no ecosystem in the world that beats seamless integration with C and no language that even comes close to being as pragmatic.
- burntsushi 9y ago
  > no language that even comes close to being as pragmatic. That's what I'm disagreeing with. I find Rust to be extremely pragmatic. There are other competing tools written in C++, and from where I'm standing, their maintenance story is quite a bit harder. Conversely, my tool works seamlessly on Windows, Mac and Linux.
  - andreasgonewild 9y ago
    If multi-platform is your biggest problem, I can see how that helps. I don't really care that much myself as long as my code compiles on the unixes. I sadly agree that static linking is a pain in the behind in C/C++ land. Still, the language I'm using interacts with the way I'm thinking; if that part isn't working out, all the features in the world isn't going to help.
    - burntsushi 9y ago
      Indeed. Windows support was critical, and I have a ton of users there as a result of it being so easy to distribute a Rust application to them. Microsoft even picked it up and is now shipping it in VS Code. :-) > Still, the language I'm using interacts with the way I'm thinking; if that part isn't working out, all the features in the world isn't going to help. Sure, and there was a lot of friction between me and Rust in the beginning. But my experience---and a lot others' experience as far as I'm aware---is that the friction settles down quite a bit. But yeah, experiences can vary there!

dochtman 9y ago

I disagree with your "too much ceremony" premise in general, but in particular I don't think it holds true for nom parsers. Here are two examples I've been working on: https://github.com/djc/askama/blob/master/askama_derive/src/parser.rs https://github.com/djc/askama/blob/master/askama_derive/src/... https://github.com/djc/tokio-imap/blob/master/src/parser.rs https://github.com/djc/tokio-imap/blob/master/src/parser.rs If you look at the parsing logic that makes up most of those files, I don't think you can reasonably argue there is a lot of ceremony going on.

andreasgonewild 9y ago
But I can, and I do; that's still too much noise for me. I'm sure the code is fine by Rust standards, but to me it looks like Perl with control issues. I don't need any help from my programming language with micromanaging the code I write or the way I write it. I'll ask when I want assistance, and until then I prefer if they stay the hell out of my way. I won't claim to write bug-free software; the only way to write bug-free software is to not write it at all; spending half my energy on sweet talking a psychotic compiler around every single detail is a perfect recipe for missing the bigger picture and ending up solving the wrong problems.