Hacker News Reader

Comment by pietroglyph | Hacker News Reader

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.

View on HN

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.

Note that in Rust 2018, trait object syntax moves to using `dyn` (see 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, 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.

Quick question: was there a time when Rust was closer to the syntax format of Haskell/Ocaml?

e.g.

  Type declaration
  Function declaration

No. Rust has always had C-family syntax. You can look at the first public commit with the code at https://github.com/rust-lang/rust/tree/d6b7c96c3eb29b9244ece... ; src/test/run-pass shows lots of examples of the syntax.

I still haven't used it enough to have a real opinion, but I think `dyn` is the one thing in all this I feel is a bad change. Otherwise the module system is going to be much nicer, `impl Trait` has been a thing needed since day 1, and some new forms of elision are nice. I'll be curious to see if I like the `match` changes though.

Incidentally, the match changes work in stable today.

The audience for the edition isn’t just those who follow Rust closely, but for those who don’t. And even for those who do, we want to take a look at some of the things that make writing Rust feel differently in the last few months. Turns out the match stuff was good enough to stabilize a bit earlier, even though it was designed with all of these other features.

Yea fair point, just haven't been writing enough rust over the last few months :(

There remains a small part of me that enjoyed the explicitness of fighting the compiler to understand what type I was actually dealing with (forced learning).

Have you read https://terrytao.wordpress.com/career-advice/theres-more-to-... before? I find it extremely interesting. Sounds like you may be on the "rigorous" stage. This kind of feature helps the pre and post stages, at the expense of that one.

I hadn't. It's a great peice though. The rust programmer who adds and removes `&` and `ref` blindly is in phase 1, the part I'm claiming to like is more or less phase 2, where some real thought goes into it, "here I have a &Option, so here it must be &Some(...)" and so on. Phase three is practical, much like how I might tell someone in casual conversation that something took orders of magnitude more time, without worrying too much about what magnitude I'm really talking about. This can give you the head space to tackle "real problems". As rust matures (and its users with it) I can understand the desire for these conveniences. I do feel the language loses some of its educational prowess. I'm always arguing in favor of more Racket like ideas, but the whole family of languages thing helps in this regard, but makes for quickly divergent communities. </ramble>

It's just your opinion. For me second example (&impl SomeTrait) is more readable.

I didn’t say it is less readable. I said it is more opaque. After all, there is still a type parameter implicitly. It is also inconsistent, because you still need type parameters on types or in cases where the type trait is defined on the impl block.

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.

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.

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.

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.

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.

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.

Just wait a couple of years and lets see how relevant Go will still be as 1.x without adding more features, outside stuff like Kubernetes and Docker.

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.

>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.

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.

Rust has not removed any syntax, non-ergonomic or otherwise, since 1.0. That's what stability means.

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.

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

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).

Yeah well, that assumes that everybody will start using Rust no matter how complex the language becomes.

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".

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)

Most likely using a C compiler writen in C++. :)

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.

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 {}` ;)

Reply on news.ycombinator.com