11 ms·

These are welcome improvements, but I worry that they will continue increasing complexity to the point that we have another C++ on our hands. There's a balance

These are welcome improvements, but I worry that they will continue increasing complexity to the point that we have another C++ on our hands. There's a balance between new features and improvements, and simplicity and stability. I hope the Rust team finds that balance.

xiphias 8y ago
Even if Rust becomes almost as complex than C++ (which may be necessary to be able to move all low level code base from C/C++ to Rust), the world becomes a safer place by not having so many memory corruption bugs while being CPU/memory friendly. I really appreciate the fast pace the Rust team has and hope for this transition to start ASAP (though features are still missing for big code bases, like distributed compilation).
- adrianN 8y ago
  Yeah well, that assumes that everybody will start using Rust no matter how complex the language becomes.
  - pjmlp 8y ago
    There is another way, which is how all surviving systems programming languages got their job. A major OS vendor states "if you want to target my OS here is the language".
    - badsectoracula 8y ago
      And a C compiler writer would reply "hold my beer" :-P. (talking as someone who was working on a C-to-C# transpiler for PSMobile to port my C game engine to it before Sony axed it :-P)
      - pjmlp 8y ago
        Most likely using a C compiler writen in C++. :)
pjmlp 8y ago
People complain that C++ is complex, which it is. Yet all other major mainstream language also are, with an history of 20 years of versions, huge libraries and quite a few breaking changes between them. Picking up Python as an example since it is deemed simple, there is quite a stuff there to learn in 167 pages of language reference, 1942 pages of library reference, major community libraries, keep track of the breaking changes between all versions or when were specific features introduced.
- sametmax 8y ago
  Yes, it's more about the the shape of the progress curve. In python you get productive in 3 days, then you nicely climb up to expertise for the next 10 years. There is not huge road block. Decorators, generators and metaclasses are hairy but won't prevent you from coding anything or undertsanding a program that use them so you can smooth in.
- pietroglyph 8y ago
  I think Go is a reasonable counter example to your assertion that mainstream languages have to be complex and constantly changing in a breaking way.
  - pjmlp 8y ago
    Go is an example of language designers ignoring modern practices, with lots of boilerplate in the libraries to workaround those deficiencies, a broken dependency management system, thus shifting the complexity to the language users and library writers.
    - cbolton 8y ago
      pietroglyph's point still stands. Well I guess Go is the obvious example to sort-of-refute your assertion, since the designers emphasize simplicity so much. It's almost a defining feature of the Go approach, just as the borrow checker could be considered a defining feature of the Rust approach. Of course, the designers of Go made compromises that shift some complexity to the language users and library writers. It seems that many find the result useful. I'm very glad that both approaches are now realized each in a popular language, but like OP I hope Rust won't go too far on the path of increasing complexity, as to me it would then lose its appeal. By the way, it's probably a bit early to say that Go's dependency management system is broken, and anyway it has little to do with the language's complexity.
sametmax 8y ago
It's still young. Give it time to stabilize. Then, just like c++, a sane subtset of features will emerge, best practices will be promoted, and tuto will adapt. rust is so damn good and the team behind it has delivered so much we hold them to impossible expectations.
- pricetag 8y ago
  Out of curiosity, have you used it to build anything for yourself or at work?
hobofan 8y ago
That's exactly what the Rust edition system is intended to prevent! One of the intentions of it is to allow for removal of previously ill-designed language features in future editions.
danieldk 8y ago
but I worry that they will continue increasing complexity to the point that we have another C++ on our hands I am currently teaching a course where Rust is the main language and this is already a problem. Some recent changes have made Rust more difficult to understand. E.g. impl in argument positions have are really opaque. For example, it is quite easy to explain and understand the difference between fn foo<T>(t: &T) where T: SomeTrait and fn foo(t: &SomeTrait) because the type parameters are explicit in the static binding case. On the other hand, fn foo(t: &impl SomeTrait) is really opaque. I know that it is an ergonomic win and provides consistency between impl in argument and return positions, but it makes Rust more difficult to understand for new language user. Other magical/difficult to understand semantics: automatic derefs in pattern matching, deref coercion, different drop orders for structs/local variables, impl coherency rules, the distinction between copy/move types, etc. Don't get me wrong, Rust is my all-time favorite language. But I agree that increased complexity is the most dangerous pitfall for Rust. I fear the day higher-kinded types are added and the catogory-theory fest will be added in addition to the existing complexity.
- chrismorgan 8y ago
  Note that in Rust 2018, trait object syntax moves to using `dyn` (see https://rust-lang-nursery.github.io/edition-guide/2018/transitioning/traits/dyn-trait.html https://rust-lang-nursery.github.io/edition-guide/2018/trans...), so that your second code block will actually be: fn foo(t: &dyn SomeTrait) &dyn SomeTrait and &impl SomeTrait are then more directly comparable. “&impl SomeTrait” should be read as “a reference to a type implementing SomeTrait”. It’s different from the angle-bracketed generic syntax you may be used to, but I think it’s generally superior. I certainly find it much easier to write and read than the generic syntax or generic-syntax-with-where-clause versions. Well, I say generally superior—but its potential downfall is the turbofish issue, that impl in argument place is not just sugar for the generic syntax. And thus that for now impl in argument place is arguably unsuitable for library code and only suitable for application code. We’ll see how that pans out. You mention higher-kinded types: there is actually a plan now for a feature equivalent to HKT, generic associated types (associated type constructors), https://github.com/rust-lang/rfcs/pull/1598 https://github.com/rust-lang/rfcs/pull/1598, and I’m glad; note when I say that that I was one of the few that campaigned before Rust 1.0 for explicitly not touching HKT for a few years purely for marketing reasons—they’re scary and will put people off Rust. But certainly I have encountered a couple of situations where generic associated types would substantially improve ergonomics in my HTTP and web work, and this is a proper Rust-flavoured take on the concepts behind HKT. I believe it will be good to have. I am still a bit anxious about the volume of change happening, just as you, others, and graydon just now on the forum post.
coldtea 8y ago
>These are welcome improvements, but I worry that they will continue increasing complexity to the point that we have another C++ on our hands. C++ got that why by accretion of features. Rust, on the other hard, removes non ergonomic syntax, or changes convoluted features to easier to grasp ones. Even when it adds a second mechanism (e.g. async/await over futures) that's still a huge win, and nothing like the mess C++ is in.
- pjmlp 8y ago
  Just wait until Rust gets like 25% as big as C++, then lets see what gets removed. C++ has been removing features as well, to the extent they don't cause major breaks.
  - deleted 8y ago
    [deleted]
- sanxiyn 8y ago
  Rust has not removed any syntax, non-ergonomic or otherwise, since 1.0. That's what stability means.
EugeneOZ 8y ago
I hope we will not get another one Ruby because of all this whining about complexity. Rust is not as difficult as you think, just try.
jacksmith21006 8y ago
Good point and it is a tough balance. Really like Rust but also like Go. One things about Go is that it is really simple.
- nixpulvis 8y ago
  Go is weird to me... tries to be low level, but has a GC. I can see it being a good option for someone coming from Java wanting to target more native code, but I'm not personally impressed. Plus `interface {}` ;)
nixpulvis 8y ago
some things, like the module system rework, I'd argue are actually making rust less complex. Although you still do need to relearn something.

xiphias 8y ago

Even if Rust becomes almost as complex than C++ (which may be necessary to be able to move all low level code base from C/C++ to Rust), the world becomes a safer place by not having so many memory corruption bugs while being CPU/memory friendly. I really appreciate the fast pace the Rust team has and hope for this transition to start ASAP (though features are still missing for big code bases, like distributed compilation).

adrianN 8y ago
Yeah well, that assumes that everybody will start using Rust no matter how complex the language becomes.
- pjmlp 8y ago
  There is another way, which is how all surviving systems programming languages got their job. A major OS vendor states "if you want to target my OS here is the language".
  - badsectoracula 8y ago
    And a C compiler writer would reply "hold my beer" :-P. (talking as someone who was working on a C-to-C# transpiler for PSMobile to port my C game engine to it before Sony axed it :-P)
    - pjmlp 8y ago
      Most likely using a C compiler writen in C++. :)

pjmlp 8y ago

People complain that C++ is complex, which it is. Yet all other major mainstream language also are, with an history of 20 years of versions, huge libraries and quite a few breaking changes between them. Picking up Python as an example since it is deemed simple, there is quite a stuff there to learn in 167 pages of language reference, 1942 pages of library reference, major community libraries, keep track of the breaking changes between all versions or when were specific features introduced.

sametmax 8y ago
Yes, it's more about the the shape of the progress curve. In python you get productive in 3 days, then you nicely climb up to expertise for the next 10 years. There is not huge road block. Decorators, generators and metaclasses are hairy but won't prevent you from coding anything or undertsanding a program that use them so you can smooth in.
pietroglyph 8y ago
I think Go is a reasonable counter example to your assertion that mainstream languages have to be complex and constantly changing in a breaking way.
- pjmlp 8y ago
  Go is an example of language designers ignoring modern practices, with lots of boilerplate in the libraries to workaround those deficiencies, a broken dependency management system, thus shifting the complexity to the language users and library writers.
  - cbolton 8y ago
    pietroglyph's point still stands. Well I guess Go is the obvious example to sort-of-refute your assertion, since the designers emphasize simplicity so much. It's almost a defining feature of the Go approach, just as the borrow checker could be considered a defining feature of the Rust approach. Of course, the designers of Go made compromises that shift some complexity to the language users and library writers. It seems that many find the result useful. I'm very glad that both approaches are now realized each in a popular language, but like OP I hope Rust won't go too far on the path of increasing complexity, as to me it would then lose its appeal. By the way, it's probably a bit early to say that Go's dependency management system is broken, and anyway it has little to do with the language's complexity.

sametmax 8y ago

It's still young. Give it time to stabilize. Then, just like c++, a sane subtset of features will emerge, best practices will be promoted, and tuto will adapt. rust is so damn good and the team behind it has delivered so much we hold them to impossible expectations.

pricetag 8y ago
Out of curiosity, have you used it to build anything for yourself or at work?

hobofan 8y ago

That's exactly what the Rust edition system is intended to prevent! One of the intentions of it is to allow for removal of previously ill-designed language features in future editions.

danieldk 8y ago

but I worry that they will continue increasing complexity to the point that we have another C++ on our hands I am currently teaching a course where Rust is the main language and this is already a problem. Some recent changes have made Rust more difficult to understand. E.g. impl in argument positions have are really opaque. For example, it is quite easy to explain and understand the difference between fn foo<T>(t: &T) where T: SomeTrait and fn foo(t: &SomeTrait) because the type parameters are explicit in the static binding case. On the other hand, fn foo(t: &impl SomeTrait) is really opaque. I know that it is an ergonomic win and provides consistency between impl in argument and return positions, but it makes Rust more difficult to understand for new language user. Other magical/difficult to understand semantics: automatic derefs in pattern matching, deref coercion, different drop orders for structs/local variables, impl coherency rules, the distinction between copy/move types, etc. Don't get me wrong, Rust is my all-time favorite language. But I agree that increased complexity is the most dangerous pitfall for Rust. I fear the day higher-kinded types are added and the catogory-theory fest will be added in addition to the existing complexity.

chrismorgan 8y ago
Note that in Rust 2018, trait object syntax moves to using `dyn` (see https://rust-lang-nursery.github.io/edition-guide/2018/transitioning/traits/dyn-trait.html https://rust-lang-nursery.github.io/edition-guide/2018/trans...), so that your second code block will actually be: fn foo(t: &dyn SomeTrait) &dyn SomeTrait and &impl SomeTrait are then more directly comparable. “&impl SomeTrait” should be read as “a reference to a type implementing SomeTrait”. It’s different from the angle-bracketed generic syntax you may be used to, but I think it’s generally superior. I certainly find it much easier to write and read than the generic syntax or generic-syntax-with-where-clause versions. Well, I say generally superior—but its potential downfall is the turbofish issue, that impl in argument place is not just sugar for the generic syntax. And thus that for now impl in argument place is arguably unsuitable for library code and only suitable for application code. We’ll see how that pans out. You mention higher-kinded types: there is actually a plan now for a feature equivalent to HKT, generic associated types (associated type constructors), https://github.com/rust-lang/rfcs/pull/1598 https://github.com/rust-lang/rfcs/pull/1598, and I’m glad; note when I say that that I was one of the few that campaigned before Rust 1.0 for explicitly not touching HKT for a few years purely for marketing reasons—they’re scary and will put people off Rust. But certainly I have encountered a couple of situations where generic associated types would substantially improve ergonomics in my HTTP and web work, and this is a proper Rust-flavoured take on the concepts behind HKT. I believe it will be good to have. I am still a bit anxious about the volume of change happening, just as you, others, and graydon just now on the forum post.

coldtea 8y ago

>These are welcome improvements, but I worry that they will continue increasing complexity to the point that we have another C++ on our hands. C++ got that why by accretion of features. Rust, on the other hard, removes non ergonomic syntax, or changes convoluted features to easier to grasp ones. Even when it adds a second mechanism (e.g. async/await over futures) that's still a huge win, and nothing like the mess C++ is in.

pjmlp 8y ago
Just wait until Rust gets like 25% as big as C++, then lets see what gets removed. C++ has been removing features as well, to the extent they don't cause major breaks.
- deleted 8y ago
  [deleted]
sanxiyn 8y ago
Rust has not removed any syntax, non-ergonomic or otherwise, since 1.0. That's what stability means.

EugeneOZ 8y ago

I hope we will not get another one Ruby because of all this whining about complexity. Rust is not as difficult as you think, just try.

jacksmith21006 8y ago

Good point and it is a tough balance. Really like Rust but also like Go. One things about Go is that it is really simple.

nixpulvis 8y ago
Go is weird to me... tries to be low level, but has a GC. I can see it being a good option for someone coming from Java wanting to target more native code, but I'm not personally impressed. Plus `interface {}` ;)

nixpulvis 8y ago

some things, like the module system rework, I'd argue are actually making rust less complex. Although you still do need to relearn something.