5 ms·

A few of my own: Declaring/initializing a medium sized array of structs, is simply too verbose if you have meaningful structure names. What is a few lines in C

A few of my own: Declaring/initializing a medium sized array of structs, is simply too verbose if you have meaningful structure names. What is a few lines in C explodes into pages in rust. Type inference on declarations but, not function parameters, WAT! The scoped constructor syntax is designed to miss the concept of RAII. Array's by themselves are nearly useless, might have just made Vec<> the default array type. Variables end up being &mut even when its not necessary because the compiler forces the attribute to be carried along in a number of cases when its not rightfully needed. As I've complained about before, many of the 3rd party cargo libraries need additional traits before they can be mixed with threads/mutexes unless your willing to use unsafe. Then there are all the bad style choices, starting with the javascript like nested calling (aka obj1.call().call2().call3().call4().call5();) chains spread over whole pages of code. Mismatch braces (yah I know this one is everywhere in C/javascript/java too, doesn't make it right). Trait declarations that are scattered everywhere rather than being centralized like a C++ class.

estebank 6y ago
> Type inference on declarations but, not function parameters, WAT! This is a hard restriction in place on purpose. The compiler could perform inference for the input and output types as part of the language but that means that the actual low level signature of your function could change by changing either the implementation or the callers. This is a compromise we must have to avoid surprises in real programs that have public APIs. On the flip side the compiler doesn't have this restriction for inferring the return type. If you write a function signature `fn foo() -> _` with a body that can resolve to an unambiguous type, the compiler will give you a structured suggestion for the correct type. This way you get the benefit of inference when developing and the benefit of type safety and unambiguous documentation of your code at the cost of mild inconvenience. > Array's by themselves are nearly useless, might have just made Vec<> the default array type. I'm not sure what the actionable recommendation is here. Is it to have made [] the syntax for Vec? If so, that would have made Vec special from the language's point of view, when it doesn't need to. Today you can reimplement all of Vec in your own Rust code, but you can't for arrays, because the compiler and language need specific memory layout information about them. > Mismatch braces Could you expand? I'm intrigued what you mean by this. > Trait declarations that are scattered everywhere rather than being centralized like a C++ class. This enables very flexible design and composition of behavior. It feels very weird when coming from an OOP background, but I've come to prefer it after a while.
qppo 6y ago
I'm confused about this list of complaints What is verbose about declaring arrays of structs? Arrays are fundamentally different than vectors, the same is true in Rust as in C++. Types are only inferred for variable declaration, that works for closures too. You can't have an inferred type in a struct declaration either. It doesn't make sense for a function declaration imho, and having worked in languages that do it - I hate it. Horrible practice to drop type args from functions. I think method chaining is really helpful, particularly the builder pattern. It's also supremely useful for abstracted logic or patterns like iterator combinatory, something that you don't find as cleanly in other systems languages. Not sure what you mean about traits being scattered? They're interfaces like a pure virtual base class - implementing them is very similar to implementing a base class in C++. Except you can use generic arguments for implementations which makes for some really expressive mechanisms for abstraction.

estebank 6y ago

> Type inference on declarations but, not function parameters, WAT! This is a hard restriction in place on purpose. The compiler could perform inference for the input and output types as part of the language but that means that the actual low level signature of your function could change by changing either the implementation or the callers. This is a compromise we must have to avoid surprises in real programs that have public APIs. On the flip side the compiler doesn't have this restriction for inferring the return type. If you write a function signature `fn foo() -> _` with a body that can resolve to an unambiguous type, the compiler will give you a structured suggestion for the correct type. This way you get the benefit of inference when developing and the benefit of type safety and unambiguous documentation of your code at the cost of mild inconvenience. > Array's by themselves are nearly useless, might have just made Vec<> the default array type. I'm not sure what the actionable recommendation is here. Is it to have made [] the syntax for Vec? If so, that would have made Vec special from the language's point of view, when it doesn't need to. Today you can reimplement all of Vec in your own Rust code, but you can't for arrays, because the compiler and language need specific memory layout information about them. > Mismatch braces Could you expand? I'm intrigued what you mean by this. > Trait declarations that are scattered everywhere rather than being centralized like a C++ class. This enables very flexible design and composition of behavior. It feels very weird when coming from an OOP background, but I've come to prefer it after a while.

qppo 6y ago

I'm confused about this list of complaints What is verbose about declaring arrays of structs? Arrays are fundamentally different than vectors, the same is true in Rust as in C++. Types are only inferred for variable declaration, that works for closures too. You can't have an inferred type in a struct declaration either. It doesn't make sense for a function declaration imho, and having worked in languages that do it - I hate it. Horrible practice to drop type args from functions. I think method chaining is really helpful, particularly the builder pattern. It's also supremely useful for abstracted logic or patterns like iterator combinatory, something that you don't find as cleanly in other systems languages. Not sure what you mean about traits being scattered? They're interfaces like a pure virtual base class - implementing them is very similar to implementing a base class in C++. Except you can use generic arguments for implementations which makes for some really expressive mechanisms for abstraction.