Interesting. They didn't have to admit that in the book/docs, they could act like it was "by design"/"a feature, not a bug", etc. and just jump straight to the workaround ("solution") they present. I've worked with languages/technologies in the past that do that. To me, the level of sincerity is a big plus.
I'm perfectly aware Rust is still pretty young but from what I've seen so far, I have high hopes for the future and am not going to sign it off just for being honest about its shortcomings.
Not trying to persuade you, or saying you're not right to do that. Just my point of view on this topic.
At that time I was exploring, searching for the good language for a big project for my company. We needed a good choice with high reliability because it would be put in production with customers who pay a lot of money, so the sincerity was appreciated but wasn't an option :-D
Then I guess it's good that you didn't go through with it. If for nothing else, using a new tech without enough experience is usually not a good idea for a "big project" :)
FYI: That specific error has been fixed since 1.41.0.
Because compilers are not perfect, they must trade-off between over-restricting and under-restricting. Rust biases towards the former, so sometimes the compiler rejects something safe. On the flip side, the compiler (almost) always rejects anything unsafe. That's what makes it safer and more stable than many languages. If you know what you are doing, Rust gives you two escape hatches: unsafe and macro.
Rust is pretty much the state-of-the-art of incorporating linear logic into memory and resource management. There are many (so many!) things in theory which we have not implemented in reality. That theoretical perspective makes the design coherent and reveals flaws in implementation as what they are. In my experience, the degree to which the Rust community devotes itself to logical soundness is second only to the academic communities working on Haskell and proof assistants. I'd really recommend you to take a second look if you are after stability, unless you are using the likes of Ada/SPARK.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I also have read all the documentation before writing a single line of code... and I avoided forever writing anything when I came to this passage:
Honestly, twenty chapters of documentation telling me that Rust is awesome and avoid common problems, but at the end you cannot do the right thing?
So yes, I loved the language, but no, I won't use it :-(
Interesting. They didn't have to admit that in the book/docs, they could act like it was "by design"/"a feature, not a bug", etc. and just jump straight to the workaround ("solution") they present. I've worked with languages/technologies in the past that do that. To me, the level of sincerity is a big plus.
I'm perfectly aware Rust is still pretty young but from what I've seen so far, I have high hopes for the future and am not going to sign it off just for being honest about its shortcomings.
Not trying to persuade you, or saying you're not right to do that. Just my point of view on this topic.
At that time I was exploring, searching for the good language for a big project for my company. We needed a good choice with high reliability because it would be put in production with customers who pay a lot of money, so the sincerity was appreciated but wasn't an option :-D
Then I guess it's good that you didn't go through with it. If for nothing else, using a new tech without enough experience is usually not a good idea for a "big project" :)
FYI: That specific error has been fixed since 1.41.0.
Because compilers are not perfect, they must trade-off between over-restricting and under-restricting. Rust biases towards the former, so sometimes the compiler rejects something safe. On the flip side, the compiler (almost) always rejects anything unsafe. That's what makes it safer and more stable than many languages. If you know what you are doing, Rust gives you two escape hatches:
unsafeand macro.Rust is pretty much the state-of-the-art of incorporating linear logic into memory and resource management. There are many (so many!) things in theory which we have not implemented in reality. That theoretical perspective makes the design coherent and reveals flaws in implementation as what they are. In my experience, the degree to which the Rust community devotes itself to logical soundness is second only to the academic communities working on Haskell and proof assistants. I'd really recommend you to take a second look if you are after stability, unless you are using the likes of Ada/SPARK.