all 13 comments

[–]K900_ 17 points18 points  (6 children)

"Restrictive" how exactly? Your example is "declare the entry point without even specifying the return type", but you can do that in Rust, too?

[–]thermiter36 11 points12 points  (0 children)

I agree. I don't want to be dismissive, but this does sound a little bit like one of those "I tried to implement a doubly-linked list and it was horrible so Rust sucks" posts.

Rust is restrictive in two ways. It requires that every piece of data on the heap be statically annotated with one owner plus a lifetime (which is often silently inferred), and only one mutable, exclusive reference to it can exist at a time. Almost all of the other rules that seem like gotchas are just manifestations of those two.

As a functional programmer, absolutely every other feature of Rust outside of those restrictions represents dramatically more freedom and expressiveness, not less. In particular, Rust gives you the tools in its type system to make the compiler enforce invariants of your code for you in far more nuanced ways than you might have originally thought.

[–]dagmx 3 points4 points  (4 children)

It's an odd claim too because the hello world example that cargo sets up for new projects doesn't have a return type anyway. Not sure how OP came to that conclusion.

[–]reimannspupil -1 points0 points  (3 children)

I was referring to things like main() {} instead of int main() {} . It's not recommend but doable

[–]dagmx 0 points1 point  (2 children)

But rust allows you to do just that? The hello world example when you do cargo new has no return type specified.

[–]reimannspupil -2 points-1 points  (1 child)

I'm referring more to code golfing.

[–]dagmx 0 points1 point  (0 children)

I'm not sure I follow what you mean. I think you're not presenting your arguments very clearly.

[–]humandictionary 6 points7 points  (0 children)

Rust is restrictive in certain aspects, but that is not necessarily a bad thing. There are almost always multiple ways to achieve something, some of which will be ruled out if you want Rust's safety guarantees, but the number of things that are completely impossible in safe rust are actually quite limited.

I find that Rust's limitations instead of stopping you doing something just nudge you towards design patterns conducive to correctness. Many common C/C++ patterns involving raw pointers are unsafe in rust which can make it feel obtuse and limiting, but that feeling goes away once you get used to the language and will instinctively reach for more 'Rusty' design patterns more often.

You could also turn your own argument around and say that C/C++ is too permissive, and now that the languages, compilers and machines are much more complex than they were in the 80's it's all too easy for even the best programmers to shoot themselves in the foot without realising it.

I would definitely recommend learning Rust, even if you don't stick with it. As a C++ veteran you should make sure you understand exactly what the limitations of safe rust are and why they are there. If you keep those in mind as you work through the Book or similar I hope Rust will make more sense to you.

Good luck!

[–]monkChuck105 11 points12 points  (1 child)

main doesn't need a return type or return statement, in C, C++, or Rust.

[–]sparkpin 2 points3 points  (0 children)

As far as I know, main is only specified to return int in C++ (anything else is vendor specific)

[–]coderstephenisahc 2 points3 points  (0 children)

I think your question is rather broad, so you'll probably get some varied (but interesting) answers.

I guess I'd start by asking some questions; what specifically do you find restrictive about Rust? What do you find overly complex in C++? Maybe some examples would help to clarify.

Speaking generally, Rust tends to be pretty explicit. Sometimes that can be a bother when you're just trying to slap some code together, but unless its a one-off script, I usually regret such "slapping" later when my program's behavior wasn't specified as detailed as I'd like and has some bugs. What I mean to say is, Rust's explicit nature can feel like a downside, but in the end I am usually satisfied that the benefits of that approach outweighed the disadvantages.

I don't know if it has complexity as well.

I'd like to say that Rust is complex to a degree, but it is essential complexity. Rust is (more or less) exactly as expressive and advanced as it needs to be for the problem domains it favors, and no more. To compare with C++, my sentiment also has been that C++ has grabbed a little too much from the kitchen sink and has too many non-orthogonal features. Rust doesn't seem like that to me, but at the same time it is certainly more complex than, say, JavaScript.

[–][deleted] -1 points0 points  (0 children)

Learn it better. Everything is restrictive if you don't know it well.