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).
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.
> 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!
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.
https://github.com/djc/askama/blob/master/askama_derive/src/...
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.
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.
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.
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".
And Go has a runtime. The fact that it has green threads and runs a GC makes for a heavier runtime than C or Rust.
I'm not sure I get your argument about Go' boxes. The original post was clearly talking about the "extra" work a developer has to do to "satisfy" the compiler and run their code. It's a common complaint from those coming from less safe languages. I don't see how I could interpret the meaning as you suggested and still make sense of the post.
Sure I can! I've been writing Go and Rust daily for years. Both come pretty easy to me. But that's because I've been using both for quite a long time now. Do I sometimes stumble and wonder, "How do I represent my data in the cleanest way in Rust?" Sure! But the same happens in Go too.
Rust was definitely harder to learn, and it took me longer to reach proficiency. With Go, I can't recall much of a learning period. It was pretty much off to the races on day 1. With Rust, there were some growing pains for a few weeks before things clicked.
However, I don't actually disagree with your larger point! I am only one person, and what I find easy or hard might be completely different for another person. For example, I had written quite a bit of Haskell and C before coming to Rust, which turned out to be pretty good preparation. Not everyone has that background, which might make the learning experience worse (or better) than mine.
[0] Until they started selling the SDK as developer's edition addon
They're trying to establish that having both of those requires Rust's approach - and I think they're making a convincing argument.