Rust 2018: an early preview | Hacker News Reader

Rust 2018: an early preview

internals.rust-lang.org

179 pointssteveklabnik70 comments

Rust is getting too complicated and noisy.

It's not that it's difficult to use, but there's just too much stuff shoved into the drawer, and I really just need some silverware.

my two cents. All the rust I've written is just rewrites of things I originally wrote in other languages. I'm a little disappointed to realize that I'm glad I don't have to write Rust for a living.

I also think the 6-week release cycle is WAY too fast for a language with the low-level ambitions of rust. Granted, it's not like stuff is being broken every six weeks, they're doing a wonderful job with backwards compat in mind, but just the sheer volume of language delta is a lot for the average programmer, I think. Maybe I'm just a below average Rust hacker and maybe I'm just not "getting it"

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.

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

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.

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.

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.

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.

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

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

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

Yeah I can't see myself ever writing "crate struct Foo" or "crate use foo". :/

There’s no plans to remove pub(crate), so you can still use it if you like.

Plain `pub` was concise and local and simple. :<

You can do that too! pub isn’t going away.

I think I saw something about a lint for bare `pub` that isn't visible to the user. I think one of the intents is to make it easier to audit for what is publicly exposed and what isn't.

Found it: https://github.com/rust-lang/rust/issues/45521

Yeah, that's gonna be seriously annoying. :/

Plain `pub` actually isn't quite local, and that's part of the confusion that `crate` is intended to address.

There's also the confusion of looking at a `pub` declaration and not knowing whether or not it's visible to the parent module or visible to the world- at which point maybe you don't want a purely local visibility mechanism.

Nah it's extremely local, that's why everybody is mad at it

I never really thought about it before when seeing the proposals but when looking at the guide's sample code, I wonder if this decision is something we'll end up regretting. As it reads, it sounds like you are declaring something is a crate akin to `mod` which I can see being confusing for new users.

I don't see it as a problem yet, `mod` still means submodule, and `crate` still means top level. The fact one is defining a new grouping structure and the other is defining visibility is slightly unfortunate, but probably not a huge deal.

Reflecting on it months later, I’m more open to the rest of those changes (I was never against any of them, but I had reservations), but I’m still a bit baffled that bare `crate` as a visibility modifier, instead of `pub(crate)`, was approved. The rest has rationale, but that just doesn’t have compelling rationale (apart saying “this lets us forget about `pub(…)` syntax completely” counts), and met with quite a bit of resistance as well.

I may still end up writing it if it goes out in that form; I’m not sure. Certainly removing the need for `extern crate` reduces the probability of confusion for developers old and new after the dust settles.

I think you also need to consider consistency with the fact that `crate` can be used to start paths local to the crate in Rust 2018.

(I'm not bothered by these changes personally, but I'm not really bothered by the status quo either.)

Please don’t make Rust harder to read and code. I am almost done with the long tutorial/documentation and it’s already a lot. The genetics syntax with the ownership and the strut/impl/trait is already a lot to eat. For me if you have to break the past version of the language for the better it’s great. Just build an as simple and readable language as you can.

When you've written Rust a bit longer (over two years for me now), these changes address issues we face every day, making it now much easier to reason about your code. Before the introduction of `impl Trait`, splitting a large function using Futures to smaller ones either required you to have a ridiculously long type signature or take a performance hit with dynamic approach using a `Box`.

The introduction of NLL will make beginner's life easier, so will the changes to the lifetime variables and if writing async code, you should be counting days to get the async/await and pinning to the stable rust.

I'd like to know what changes here you think will make it harder to read and code Rust?

I for one dislike the new dyn addition.

Then again, I have other horses to worry about.

I for two.

From where I am now and so not far in the world of Rust, I am struggling to learn all the new paradigms and ways of doing things with a special syntax. Maybe the syntax is easier for others or it will get better for me after a while but when I see the new dyn it’s hard for me to place it in an already crowded things to know.

The other thing is how past and future features/syntax are supported, like for the new modules systems. I will prefer to break things when it makes sense with new features well thought out rather than support different ways of doing something and have as many ways of writing it. At the end of the day with a full team it’s as many way we have to read and so to understand. And even thought your team has the same guideline it’s the same problem when we start to read open source projects all with different ways of doing things. I won’t want to have a language that don’t break things and features stack themselves across the years but rather a language that refine itself over time with only one way of doing things. We can see how it turned for C++ where the language is so big that you have different ways of writing it and like how Google has its own guidelines and others too. On the other end look how Swift look now.

Right now my feelings are not to add new features but to refine the language and the syntax. But I can be all wrong. I mean I have just starting to learn Rust. A syntax with some ideas from ReasonML for instance will maybe make it better.

On a side note I hope this comment comes not too raw I see many down votes. I am just expressing my point of view as a beginner. Right now I know many of my coworkers will be turn down with what I said in my first comment. And they will turn to Go instead. Which I am sure can be fine technically but I really want to see Rust succeeds and have even more Rustaceans!

FWIW, I would consider a good chunk of Rust 2018 to be refinements on the language and the syntax. The amount of thought that has gone into those changes is enormous. I mean, if you just look at the new things in Rust 2018[1], then basically every single one of those is a refinement or clarification on an existing idea. The major exceptions are async/await, SIMD and maybe impl Trait. SIMD isn't a language change though; just an incredibly large std::arch library module. :-) impl Trait has fairly limited scope in my view. I think its primary advantage at this point is to make it easier to write compositional code when dealing with futures.

It is hard to say "no" to some new language features because many of them are very very strongly motivated by incredibly compelling use cases. async/await is the big one. Rust's direction is nothing if not pragmatic, and async/await is kind of the obvious direction to head in if we want people to be able to write asynchronous code happily.

[1] - https://rust-lang-nursery.github.io/edition-guide/2018/statu...

`impl Trait` syntax has been used casually in conversation on irc://irc.mozilla.org/#rust since long before Rust 1.0, and some at least of us had hoped to have it before Rust 1.0. It took a while, but we finally got it, so now we’re fairly happy. (I think the turbofish issue hadn’t occurred to those of us that casually wrote it before, but once it was being implemented it became obvious.)

I know. I was there. ;-) What I meant was that `impl Trait` hasn't existed yet on Rust stable, and it gives folks legitimately new powers, so it seems like it was on the line between it being a refinement and it being a legitimately new language feature. But this is splitting hairs; the classification doesn't matter much.

I'll be really curious to see how the async/await stuff plays out. I'm still a bit unclear as to why it needs to be a language feature and not something in STD or an external crate. I'm sure if I read the RFCs/Issues I'd understand better, but it's been a while. Regardless, most of the changes so far are welcome in my eyes :)

The PR to add it just landed in nightly, incidentally!

But yeah, if you care, reading the RFC should explain that. It's been a while since I read it, but we had a procedural macro based version, but ended up with real language support for a reason.

Stupid question on `Box<Foo>` vs. `Box<dyn Foo>`: does this syntax apply to any other places where a trait is used as a type parameter?

E.g.

    //do we write the type of MyBox like 'MyBox<dyn Debug>'?
    struct MyBox<T : ?Sized>{
        inner: Box<T>
    }

Yes. The unsized trait object type is being renamed from `Trait` to `dyn Trait`.

I recently found out about volt. I was so glad i found this language, which has everything i want, basically an improved c.

Then I learned it was garbage collected. I felt disappointed.

Using JavaScript to remove certain lines from the code examples in the book is such a weird choice.

It’s primarily so that tests can still be run, while presenting only the info you want to show to those who read the docs.

You should filter those lines before they hit .html files.

There's a button to toggle whether these lines are shown or hidden. Implementing this button's behavior using JavaScript seems perfectly reasonable to me.

Yes, you want to be able to show people that it needs additional context to work, and what that context is.

I appreciate this. There are too many times that example code omits things and as someone new you get confused as to what the boiler plate is you should use.

So that the 0.01% of people who turn off Javascript have a nicer experience?

Actually turning it off makes quite a pleasant experience not being easily tracked, getting tons of adds and JS minified libraries bigger than Quake.

I take it you don't perform such exotic activities within the browser as upvoting or collapsing subthreads on HN?

You don't need JavaScript for voting.

It also kills more than half of the actual functionality.

If you just want the text, you can use Links.

No I want Internet without the JavaScript fluff.

Websites that deserve it and I bother to use them, or lack alternatives, do get white listed.

Reply on news.ycombinator.com